Вот картинка:
http://www.gamedev.ru/images/?id=8883
Здесь я изобразил сущности, которые прямо или косвенно участвуют в графическом конвеере. Стараясь при этом концентрироваться на прослойке графического API (GAPI).
Краткая справка по моей нотации:
1. Стрелками указано направление зависимости. Оно достаточно абстрактно и на данном этапе может быть не точно.
2. В прямоугольниках приводятся названия сущностей.
3. В скобках под прямоугольниками приводятся свойства сущностей.
4. В кружочках - просто нумерация зависимостей.
Моя цель:
1. Создать PowerPoint-документ, в котором эти сущности будут появляться последовательно и с объяснениями
2. Скомпилировать из приведенных здесь идей требования на Low-level Render API и добавить для него соответствующий слой в структуре.
3. Перспектива: обсудить иерархическое представление данных по пространственному признаку - короче про Scene Graph и также описать его.
4. Параллельно с 2 и 3 очертить возможные планы реализации стандартных эффектов на том или ином уровне (2/3).
5. Получить новую статью для этого сайта.
6. Существенно понизить энтропию в своих представлениях =)
Для начала, нужна обратная связь, главным образом по приведенной структуре: что не понятно, что плохо, что добавить, что убрать, что подправить. Ну и вообще.
Что это?
(я долго и честно пытался понять)
Присоединяюсь к neteraser: о чём и зачем это?
neteraser
Что такое графический конвеер ты итак знаешь. Поэтому:
1. Да, это не схема конвеера, так как не отражен порядок следования данных.
2. По характеру это больше похоже на схему данных, которую составляют при проектировании БД.
3. На самом деле, сакрального смысла в той схеме нет.
Я полагаю что в общих чертах я ответил на вопрос "Что это?".
Если более конкретно, то пример - вычисление цветов пикселей - финальная стадия конвеера (fragment processing) происходит с использованием:
- Результатов трансформ-пайплайна - (8),
- Вершинных атрибутов - (12),
- Текстурных стейтов (упс, номер забыл)
- Установленных режимов вывода (бленд/альфа-тест/вспомогательные буферы) - (13)
(по отношению к блоку "Fragment processing", под FFP понимается всё кроме Pixel Shader'ов)
Также известно, что результат растеризации (цвет пикселя) зависит в общем случае не только от состояний сущностей, которые приводятся в схеме, но и от способа их комбинации. По причине этого обстоятельства, схема как бы не дает представления ни о чем, кроме как об основных сущностях и отношениях между ними.
Что будет дальше?
Дальше будет еще одна схема, соответствующая тонкой прослойке Render-API. А именно - должны сформироваться понятия различных рендер-стейтов (будут проведены зависимости к texture states, transform, Pixel/Vertex shaders, Render modes). Должны сформироваться понятия техник, а также требования к сортировке, etc.
Что еще дальше?
Дальше иерархическое представление данных - Scene Graph, как более высокоуровневое средство, применяемое не только для оптимизации (ускорения) работы конвеера, но и для организации более высокоуровневых эффектов.
Зачем это всё нужно?
Хочется, чтобы все сущности были "перед глазами". В то время как средства и набор сущностей, предоставляемых GAPI, остаются практически постоянными, структурный состав остальных надстроек может сильно меняться. По мне, так проще при добавлении какой-то фичи сразу просмотреть смежные элементы и найти путь наименьшего сопротивления.
Padawan
Я бы рекомендовал сразу рассматривать только vertex programs/fragment shaders и не мучать голову останками FFP.
FFP - это слишком просто и в то же время - довольно сложно или невозможно.
А еще лучше - сразу определись, куда и как ты потом начнёшь это использовать.
Следуя mainstream ты уберешь издержки на research, но автоматически лишишься возможности получить added value.
В игре про Кинг-Конга тебе могут оказаться куда важнее волосы и мех, чем параллакс-маппинг.
Тема в архиве.