Войти
RGDEngineФорум

Структура

Страницы: 1 2 39 10 Следующая »
#0
22:06, 20 июня 2003

Render – Класс, отвечающий за отрисовку всей геометрии. Данный класс чисто виртуальный. Конкретные реализации должны реаизовать минимум эти методы:

·Init – инициализация. Параметры - .ini файл, содержащий настройки.
·CreateVertexBuffer – создание буфера вершин. Параметры – формат вершины, размещение (видео память, оперативная итд), размер буфера.
·CreateIndexBuffer – создание буфера индексов. Параметры – формат, размещение, размер.
·DrawPrimitive – отрисовка. Параметры – буфер вершин, индексов, тип примитива, смещение, количество вершин, настройки.

Под настройками подразумевается структура (RenderState), хранящая в себе требуемые установки (освещение, текстуры, шейдеры итд). Честно говоря я не до конца представляю, как это будет выглядеть. Возможен такой вариант – RenderState имеет методы, позволяющие добавить определенное состояние (например, включить текстурирование). Реализация данного метода будет преобразовывать символические константы в команды API, которым производится отрисовка.

Это в паре слов, и то про один класс. Вот просто мысли вслух. Базовый набор классов:
Core
Scene
Render
Model

Ядро (Core). Отвечает за начальную инициализацию движка. Инициализация всех библиотек, необходимых для работы. Загрузка настроек из внешнего источника (например, .ini файл) и дальнейшее создание всех остальных объектов.
Сцена (Scene). Также получает описание себя из внешнего источника. Создает необходимые для данного уровня объекты (загружает модели итд).
Визуализатор (Render). Выше про него речь уже шла. С помощью него отрисовывается вся геометрия.
Модель (Model). Модель и модель. Особо про нее пока и не сказть ничего.

Что осталось за кадром:
Input
Sound
Gui
ResourceManager
Network

Буквально пару слов про них.
Input – Ввод. Следит за устройствами ввода и рассылает (или отвечает на запросы) действия.
Sound – Звук.
Gui – Интерфейс. Кнопочки, текст…
ResourceManager – Менеджер ресурсов. Отвечает за физическую загрузку ресурсов (музыка, модели, текстуры…).
Network – Сеть. Удаленное взаимодействие.

Итак, в паре слов я что-то нарисовал. Все это, конечно, глупости без объяснения взаимодействия всего этого (причем список далеко не полный). А вот этого пока нету…


#1
22:18, 20 июня 2003

Jihar
Ты предлагаешь, сделать класс Render чисто виртуальным??
Т.е. взвалить его реализацию на пользователя, т.е. вынудить пользователя работать напрямую с API??
IMHO это нехорошо.

#2
22:51, 20 июня 2003

Вот мое виденение структуры движка:
Host - главный модуль, организует работу остальных
Memory manager - выделение памяти, организация Mem pools
File manager - работа с файлами, включая пакетные
Resource manager - кеширование ресурсов
World - хранение данных мира
Renderer - визуализация данных мира
Physics+collision detections - без коментариев
GPU driver - интерфейс с GPU
VPU.dll (math lib) - векторные функции CPU (SSE, 3DNow!)
Sound driver - звуковое ядро
Debug - ASSERTs, Console, Logs, memory guarding

Код игры состоит из:
Game - основная игровая логика
Scripts - язык миссий
AI - искусственный разум

Jihar, интерфейсы gpuDriver'а сейчас подготовлю.

#3
22:56, 20 июня 2003

faTe
>Ты предлагаешь, сделать класс Render чисто виртуальным??
Да
>Т.е. взвалить его реализацию на пользователя, т.е. вынудить пользователя
>работать напрямую с API??
>IMHO это нехорошо.
Смысл чистой виртуальности:
class OGLRender : public Render
{
//.......
}
class D3DRender : public Render
{
//.......
}
class GLIDERender : public Render
{
//.......
}

#4
22:59, 20 июня 2003

Black Angel
Если не секрет, ты где, что и зачем вообще твой движок? Чисто свой или уже коммерческий?

>Jihar, интерфейсы gpuDriver'а сейчас подготовлю.
Жду :)

#5
23:39, 20 июня 2003

2Jihar
Некоторые коментарии к твоей реализации рендерера:
J>>Init – инициализация. Параметры - .ini файл, содержащий настройки.
Может не стоит давать драйверу работать с файлами (плохой тон, повышается
зависимость графики от самого движка), можно просто передавать структуру
инициализации. У меня все немного иначе. Необходимые параметры драйвер сам
спрашивает у хоста (они доступны из консоли и считываются из config-файла),
а если вдруг какой-либо параметр оказался неизвестен (запись в config'е
отсутствует), используется значение по умолчанию. Пример:
if (!lpEngine->GetRegisteredValue("ScreenWidth", &settings.Width))
settings.Width = GFXDRIVERDEFAULT_SCREENWIDTH;

>>CreateVertexBuffer – создание буфера вершин...
Сколько буфферов планируешь создавать? Уверен это заранее известное число.
Не проще ли создать их заранее, исключив тем самым CreateBuffers-функции.
Опять же у меня:
Я использую несколько буфферов Interface (текс), World (полигоны уровня, ландшафта),
Mesh (все модели в игре), Stencil Volume (для стенсильных теней).
Согласись, все модели на уровне имеют одинаковый FVF вершин, ровно как и полигоны
ландшафта. Можно еще создать ParticlesBuffer. Вообщем опять пример:
lpDriver->BeginFrame(ClearColor, ClearZ);
  lpDriver->BeginWorld(...);
    lpDriver->RenderWorldPoly(...);
  lpDriver->EndWorld();
  lpDriver->BeginModel(xform);
    lpDriver->BeginMesh(effector);
      lpDriver->RenderMesh(vertices, indices, num);
    lpDriver->EndMesh();
  lpDriver->EndModel();
lpDriver->EndFrame();
lpDriver->UpdateScreen();
Надеюсь суть понятна.

>>Если не секрет, ты где, что и зачем вообще твой движок? Чисто свой или уже >>коммерческий?
:) свой, но пока не готовый.

#6
0:12, 21 июня 2003

Сорри, Jihar, интерфейсы завтра подготовлю. Спать хочется.

#7
0:38, 21 июня 2003

Black Angel
lpDriver->BeginFrame(ClearColor, ClearZ);
lpDriver->BeginWorld(...);
lpDriver->RenderWorldPoly(...);
lpDriver->EndWorld();
lpDriver->BeginModel(xform);
lpDriver->BeginMesh(effector);
lpDriver->RenderMesh(vertices, indices, num);
lpDriver->EndMesh();
lpDriver->EndModel();
lpDriver->EndFrame();
lpDriver->UpdateScreen();

Тут уже начинает появляться запах Renderman Interface

#8
10:58, 21 июня 2003

Black Angel
>Может не стоит давать драйверу работать с файлами (плохой тон, повышается
Да, в этом ты прав. Даже не подумал про это :). В принципе, вариант с запросом настроек у хоста очень даже хороший.


>Сколько буфферов планируешь создавать? Уверен это заранее известное число.
>Не проще ли создать их заранее, исключив тем самым CreateBuffers-функции.
Ну не знаю. В любом случае, буферы ты будешь создавать. Будет ли создание буфера publuc или private, вот это уже вопрос. На раннем этапе ты, в любом случае, будешь сам, в ручную, создавать эти буфера. К завершающему этапу, конечно, уже можно говорить о заранее известном количестве буферов. Но если запретить динамическое создание, это конечно, может повлиять на динамичные вещи. Типа частиц. Для них ты создашь один буфер. Придется делать его большим, чтобы точно хватило. Вот две проблемы:
1) его, все-таки, не хватит. А ресурсы еще есть. Кто-то останется без взрыва. "Глючит игрушка"
2) его хватит. Но бОльшая часть буфера может спокойно простаивать, никогда не понадобившись. Те трата ресурсов впустую

>Mesh (все модели в игре), Stencil Volume (для стенсильных теней).
>Согласись, все модели на уровне имеют одинаковый FVF вершин, ровно как и
>полигоны ландшафта. Можно еще создать ParticlesBuffer. Вообщем опять пример:
Насчет FVF не согласен. Например, сейчас у меня для ландшафта текстурные координаты генерятся автоматически. Разные форматы вершин могут быть, лучше, имхо, на одинаковость не расчитывать.

>Надеюсь суть понятна.
Да, суть понятна. Идея через драйвера мне нравится. В принципе, достаточно определить нужные (даже не знаю, как сказать) "устройства". Определить их интерфейсы, написать драйвера. И определить методы доступа к драйверам. Мне нравится :)

#9
11:02, 21 июня 2003

_NetSurfer_
>Тут уже начинает появляться запах Renderman Interface
Ты хорошо знаешь этот запах? Те сможешь объяснить ,что да как. Хорошо там придумано или нет? Или просто ссылки на структуру их архитектуры? :)

Кстати, просьба ко всем! Если кто пользовал готовые движки, скажите, что вам показалось там удобным.

#10
11:34, 21 июня 2003

А у меня Render испроен просто.
Есть 2д массив. Первый индекс - Layer, второй Graphic Block в этом лайере.
Эмуляция обычного пайп лайна - По очереди вызывает
BeginLayer(i)
ExecuteBlocks(i)
EndLayer(i)

GUI например в свою очередь имеет функцию GenBlocks,GetBlocks
- Создает блоки на отрисовку.
VB,VI - классы.
Итого у меня оперделна одна функция CGraphicBlock(Instance)->SetCommand(DWORD Command,DWORD Parameters)
Которая делает SendMSG(MOD_GRAPHIC,MSG5(GraphicBlock->ToMSG5());

Такая стуктура не тока API независимая , но и машина независимая- может рисовать данные с другого компа.

#11
12:23, 21 июня 2003

2Jihar
Я к чему начал о буфферах, их создание в runtime дорого обходиться.
Необходимо заранее учесть сколько их понадобиться, обозвать каждый
и сделать интерфейс для работы с ними. Немного прокоментирую работу
буфферов:
void  RenderXXX(VERTEX* verts, uint32 num_verts, INDEX16* indices, uint32 num_indices)
{
    if (lpXXXBuffer->VertexCount+num_verts >= GFXDRIVERVERTEXBUFFERSIZE_XXX)
    {
        FlushXXXBuffer();
        ResetXXXBuffer();
    } else if (lpXXXBuffer->IndexCount+num_indices >= GFXDRIVERINDEXBUFFERSIZE_XXX)
    {
        FlushXXXBuffer();
        ResetXXXBuffer();
    }

    //Add new vertices
    ...
    //Add new indices
    ...
}

FlushXXXBuffer - очищает буффер при переполнении, посылает данные к GPU
(Вызывается также в EndXXX)
ResetXXXBuffer - сбрасывает счетчики вершин/индексов в 0 (Вызывается также в BeginXXX)

По поводу одинакового FVF. Jihar, у тебя на ландшафте есть вершины с разными форматами?
Думаю там все такие:
LANDVERTEX
{
    float x, y, z;
    float nx, ny, nz;
    dword color;
    float tu0, tv0;
    float tu1, tv1;
}

Да, кстати, ты был прав. Нужен интерфейс для создания буфферов для static geometry, которые
будут создаваться при загрузке уровня.

#12
12:24, 21 июня 2003

Моя основная работа в 1С состоит в том чтобы написать такую вот прослойку между движком и GAPI (Graphics API).
Я уже полгода работаю над неё, и почти закончил основные вещи.

--------------------------------------------------------------------------------------------------
Я назвал её HAL (Hardware Abstract Layer).  Содержит только интерфейсы.
--------------------------------------------------------------------------------------------------
1. Класс Contex. Создание окна и и т.д. Единый для всех GAPI. Может быть как основным а может быть как RenderTarget (например отрисовка в текстуры и т.д.)

2. Стейты (RenderState). Сюда входят стейты, которые в D3D можно поставить через SetRenderState. В том числе glBlend и т.д.

3. VertexArrayManager. Сюда входят VertexBuffer, IndexBuffer.
    - Можно работать по упрощенной схеме I_VertexArray (включает в себя VB и IB, позволяет загружать данные, обновлять и отрисовывать)
    - Можно работать с I_VertexBuffer, I_IndexBuffer напрямую через VAMan (I_VertexArrayManager). Бывает нужно чтобы например текстурные координаты были в Video, а позиции вершин в AGP (например скелетная анимация). Для этого нужно делать несколько VB и возможно несколько IB.
    - Можно работать как по FVF схеме, а можно через SetStreamSource (это мои понятия, не путать в D3D)

4. Текстурный менеджер, сюда входят I_Texture, создание загрузка из файла, задание параметров, способы фильтрации. Возможность создание динамических текстур, возможность отрисовки в текстуру. Установка генерации текстурных координат. Настройка текстурных стадий (TexCombiner который wat написал)

5. LightManager. Отвечает за освещение. Обрабатывает I_Light, и служит хранителем настроек для освещения.

6. ShaderManager. Отвечает за шейдеры, причём работает только с массивами текстовых строк. Умеет ставить, убирать параметры и т.д.

-------------------------------------------
Далее идёт более высокий слой:
Main Graphics Layer (MGL)
-------------------------------------------
1. Естесвенно RenderManager
2. MaterialManager
...........
И т.д.

Вобщем мне тоже интересны различные подходы и реализации. Я могу в этом участвовать в проекте.

#13
12:35, 21 июня 2003

Можно еще перечислю необходимые буффера?

WorldBuffer - полигоны уровня, основная их масса имеет один FVF. Требуется сортировка по
материалу и отбраковка в отдельный TransparentBuffer, который будет визуализироваться
в конце (Begin/EndPostProcessing).

MeshBuffer - все сетки юнитов и различных объектов, имеет также общий FVF вершин.
Сортировка не требуется, материал устанавливается в BeginMesh. Ситуация переполнения
почти невозможна, т.к. размер буффера подогнан под размер максимальной сетки модели,
поэтому ее можно не обрабатывать.

InterfaceBuffer - здесь храним все наши панельки и текст на экране, Все вершины
имеет один формат XYZRHW | DIFFUSE | TEX1. Почти все элементы имеют прозрачность,
поэтому Begin/EndInterface вызываем только после Begin/EndPostProcessing. Возможно
понадобиться сортировка по удаленности (если использовать некое подобие оконного
интерфейса).

StencilVolumeBuffer - теневые объемы, естественно все одинаковые, вызов также после
Begin/EndPostProcessing. (Хотя может в их связке Begin/RenderVolumes/End).

ParticlesBuffer - системы частиц (point sprites). Буффер обрабатывает переполнение,
сортировки нет.

FXBuffer - подобие системы частиц, но полигонами. Требуется обработка переполнения,
сортировка по удаленности. Вызов в связке Begin/EndPostProcessing. Этим будем
делать взрывы, вспышки и т.п.

Все эти буффера создаются как dynamic и writeonly, очистка по discard.

+Интерфейс для создания новых буфферов.
Коментарии, критика и дополнения приветствуются.

#14
13:27, 21 июня 2003

Интерфейс помоему лучше хранить в текстуре.
У меня текст рендериться в текстру, потом она уже рендериться на Layer GIU.
GIU чтука статичная, ей геомерия тока во вред.
Ну а если есть супер пупер динамический элемент - пусть идет в другой Layer

ЗАРАНЕЕ СОРИ ЗА КАПС- СИСТЕМА ЗАВИСЛА, НАДО ПЕРЕГРУЖАТЬ ЧТОБЫ ИСПРАВИТЬ. А ШИФТ ЖАТЬ УЖЕ НАДОЕЛО,

1. Класс Contex. Создание окна и и т.д. Единый для всех GAPI. Может быть как основным а может быть как RenderTarget (например отрисовка в текстуры и т.д.)
ВОТ ДО ЧЕГО НЕ ДОДУМАЛСЯ ДО ТОГО НЕ ДОДУМАЛСЯ. У МЕНЯ OFFSCREEN BUFFER ИДЕТ КАК ОТДЕЛЬНЫЙ ОБЬЕКТ.

2. Стейты (RenderState). Сюда входят стейты, которые в D3D можно поставить через SetRenderState. В том числе glBlend и т.д.
ИЗВИНИ НЕ ПОНЯЛ. СТЕЙТ ЭТО КЛАСС ИЛИ ЭТО ОТДЕЛЬНЫЙ КОМПОНЕНТ РЕНДЕРА?

3. VertexArrayManager. Сюда входят VertexBuffer, IndexBuffer.
- Можно работать по упрощенной схеме I_VertexArray (включает в себя VB и IB, позволяет загружать данные, обновлять и отрисовывать)
- Можно работать с I_VertexBuffer, I_IndexBuffer напрямую через VAMan (I_VertexArrayManager). Бывает нужно чтобы например текстурные координаты были в Video, а позиции вершин в AGP (например скелетная анимация). Для этого нужно делать несколько VB и возможно несколько IB.
- Можно работать как по FVF схеме, а можно через SetStreamSource (это мои понятия, не путать в D3D)
ТУТ ВСЕ ВЕРНО.

4. Текстурный менеджер, сюда входят I_Texture, создание загрузка из файла, задание параметров, способы фильтрации. Возможность создание динамических текстур, возможность отрисовки в текстуру. Установка генерации текстурных координат. Настройка текстурных стадий (TexCombiner который wat написал)
... ДИНАМИЧЕСКИХ... - В СМЫСЛЕ АНИМИРОВАНЫХ ИЛИ ПОДВЕРЖЕНЫХ SUBTEXTURE? ИЛИ ОНИ КАКИЕТО ОСОБЕННЫЕ?
... ОТРИСОВКИ В ТЕКСТУРУ... В СМЫСЛЕ РЕНДЕРИНГ В CONTEX?

5. LightManager. Отвечает за освещение. Обрабатывает I_Light, и служит хранителем настроек для освещения.
...

6. ShaderManager. Отвечает за шейдеры, причём работает только с массивами текстовых строк. Умеет ставить, убирать параметры и т.д.
ТОЕСТЬ ПОЗВОЛЯЕТ ИЗМЕНИТЬ ШЕЙДЕР НА ЛЕТУ??

-------------------------------------------
Далее идёт более высокий слой:
Main Graphics Layer (MGL)
-------------------------------------------
1. Естесвенно RenderManager
2. MaterialManager
...........
И т.д. СМОТРИМ GUN :)

А ВОТ КАК У ТЕБЯ ПРОСХОДИТ ОТРИСОВКА ОБЬЕКТОВ.
ОНИ :
1.САМИ СЕБЯ ОТРИСОВЫВАЮТ
2.ОТРИСОВЫВАЮТСЯ ДРУГИМИ МЕНАДЖЕРАМИ(СЕКТОР,FX...)
3....

ВОТ ЭТО ИНТЕРЕСНО.

Страницы: 1 2 39 10 Следующая »
RGDEngineФорум

Тема в архиве.