Архитектура движка.Статьи

Рендер для бедных (3)

Автор:

1.Предпосылки: наличие движка с лёгким рендером под Brew на OpenGL ES

2.Цель: получить производный рендер с поддержкой Multi-Api для OGL/DX

3.Поставленные задачи:

а) Минимизация виртуальных вызовов функций (в критических частях).
б) Минимизация вызовов функций (в меньшей степени).
в) Расширяемость в compile-time.
г) Адаптация в run-time.

4.Идея работы:
Подсистема накапливает ссылки на некоторые графические объекты.
По полученным данным формируется "поток", который направляется
на графический адаптер. Цель подсистемы - минимизировать время
формирования и отправки потока за счет возможных особых приемов
программирования, а также минимизировать объем самого потока, в
соответствии с наличием особых возможностей видеоадаптера.

Короче, это должно выглядеть как "отдал и забыл", только,
на уровне рендера. "Поток" формируется от IRenderSystem::Render.
Под самим термином "поток" понимается совокупность вызовов
функций GAPI и данных, фактически отправляемых на видеоадаптер.

5.Основные элементы:

а) IRenderable - интерфейс для графических объектов, в нем есть
  QueryInterface.

б) Render Group - произвольное объединение объектов IRenderable,
  для каждого такого объединения можно устанавливать видимость
  и некоторые другие подобные флаги.

в) TransformTicket - просто число - идентификатор трансформа
  видовой матрицы, устанавливаемое для Render Group, как
  состояние. Все последующие добавляемые ссылки на графические
  объекты будут ассоциированы с этим идентификатором.
  Это нужно, чтобы не трогать зря видовую матрицу для
  объектов с одним TransformTicket.

г) IFXMaterialOption - интерфейс "опции" для материалов.
  Обычно, опции - это идентификаторы текстур.

д) IFXMaterial - интерфейс для материала. Именно к материалу
  сводится процедура добавления ссылки на графический объект.
  Материал содержит опции. В системе таким образом может
  быть зарегистрировано несколько наборов опций для материала.
  Материал умеет минимизировать затраты на отрисовку мешей
  с разными наборами опций.

е) Texture - просто число (id) для текстуры. Текстуры создает
  рендер, а выдает идентификаторы (для Multi-api).


6. Концепция работы:

Создаются необходимые группы, заполняются объектами, расставляются
флаги и вызывается Render(), от которого вызовы проходят к материалам.

PS: сортировка по материалам+наборам опций+трансформам проходит
через 32-битное число. Объект размещается по воле своего FXMaterial,
либо полностью в VAR и/или VBO, предоставляемых ему рендером,
и рендерится оттуда. Либо, материал может не пользоваться этим
и рендерить как-то по-своему. Пример - есть FX для билбордов
и надписей, который просто обнуляет компоненты поворота в
видовой матрице и скидывает геометрию.

На Brew вообще были сделаны хинты, и так как большинство объектов
все-таки статические, то загруженные данные навсегда прописывались
в структурах рендера. Если по-русски, то грузились все меши в отделенные
64k, а оттуда копировались на усмотрение FXMaterialов в VAR/DL.

10 января 2006

Комментарии [1]