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

EngineResearch(1): CatMother RenderAPI (2 стр)

Автор:

1.3 Shader

1.3.1 Обзор

Базовый класс Shader вводится на уровне Scene Graph. Этот уровень не планировалось рассматривать, но пришлось в данном случае.

Shader объявляет методы работы с шейдерными константами – параметрами, позволяет их именовать и задавать типы в run-time. Shader наследует интерфейс ContextObject, который объявляет полностью виртуальные методы для загрузки и выгрузки ресурсов в/из GPU.

Shader не полностью определен, по концепции напоминает Material (см. 1.2.3), так как присутствуют Begin, Apply, End. Эти методы полностью виртуальные и определяются производными классами.

В классе не присутствуют даже виртуальные методы для загрузки/компиляции шейдера. Значит, это автоматически отдается потомкам. Нет и подсчета ссылок, хотя причина этого более чем непонятна.

Есть странная особенность – все примитивы (модели, спрайты и т.д.) ассоциируются не с материалом, как это обычно принято, а с объектом интерфейса Shader. Здесь же возникает связь между Material и Shader. Связь построена тоже странно: возникает еще один класс – sg::Material (теперь есть два класса, sg::Material и gd::Material, рассматриваемый ранее).

Sg::Material агрегирует gd::Material и одновременно является производным от Shader. То есть, получается что Sg::Material дублирует интерфейс Gd::Material, просто перенаправляя выполнение методов на агрегируемый экземпляр Gd::Material. Опять же, полученный Sg::Material не имеет отношения к programmable pipeline, это еще одна обертка над оберткой обертки рендер-стейтов, плюс реализация методов ContextObject (см. выше).


Чисто-FFP направление в Shader развивается в классе ShadowShader (stencil-shadows), который агрегирует уже Sg::Material. В результате имеем уже четвертую обертку над render-стейтами.

Что касается самих шейдеров, т.е. programmable pipeline, то ситуация повторяется: есть базовый интерфейс Gd::Effect, который похож на Shader, но является отдельным от него. На уровне Scene Graph появляется еще один класс Sg::Effect, который подобно Sg::Material агрегирует Gd::Effect и является потомком Shader. У Gd::Effect есть реализация Dx9Effect, основанная на файлах .fx. Фактически, .fx-файл определяет технику, которая может быть многопроходной и использовать шейдеры.


1.3.2 Иерархия классов

catmother_shaderclass | EngineResearch(1): CatMother RenderAPI

1.3.3 Выводы
•  Странно выбраны названия (Material скрыт за Shader, а Shader – это не обязательно Shader…).
•  Наличие классов с одинаковыми именами в разных пространствах имен, которые очень похожи по содержанию, содержат те же enumerations. Концепция «египетской пирамиды» применена не вполне удачно, так как строятся обертки до четырех (!) уровней.
•  Производительность fx зависит от реализации directx. Очень многое скрыто в fx.
•  Четко видна попытка склеить две параллельные линии (FX-Effect и FFP-material) под один интерфейс Shader.
•  Сортировка становится возможной только на уровне Scene Graph и только по экземплярам Shader. На деле она не выполняется, нужно надеяться на правильную структуру Scene Graph.
•  Вывод Material, Effect и т.д. на уровень Scene Graph не оправдан. Сделано это только для выделения GAPI-независимой функциональности (ShadowShader). Эту функциональность стоило обеспечить на уровне RenderAPI, при этом не понадобились бы SG:Material, SG:Effect.
•  Нет препятствий для комбинирования (в местах агрегации). Однако комбинирование реализовано только в compile-time через наследование.
•  Схема Begin->Apply->End представляется удачной для материала.
•  Вероятно, стоило создать одну сущность Material (вместо Shader), в которой были бы настройки, касающиеся реакции на освещение и затенение, контроль прозрачности, назначенный шейдер (или набор шейдеров). В производных классах останется только обеспечить необходимый способ реализации настроек, используя схему Begin->Apply->End.

Страницы: 1 2

9 февраля 2006 (Обновление: 24 сен 2006)

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