Название темы не вполне корректное, т.к. SceneGraph'ы бывают очень разными.
На всякий случай, скажу что за свою пока еще небогатую практику встречался с реализациями, которые:
1. Являются ациклическими (иной раз раздражет искусственное наведение зависимостей через разные вызовы в обработчиках узлов);
2. Имеют классы основных узлов для transforms, render-states, renderables;
3. Выполняют пространственные запросы;
4. Отражают полную семантику объектов (т.е. если надо изобразить дом с интерьером, то интерьер расписывается по нисходящей в иерархии).
С одной стороны, расширение системы сводится к созданию новых типов узлов. Обычно это просто, значит достоинства налицо. А с другой стороны, я одним местом чую, но математическим языком объяснить не могу -- что-то мне не совсем они нравятся.
Вообщем, хочу чтобы мне помогли определиться с минусами "классических" графов.
---
Пока не буду выливать все свои соображения и недоумения, чтобы никого не смущать. Однако, продумываю вариант, где к графу не предъявляется никаких требований в отношении связей - следовательно нет иерархии. Сам граф не отражает семантической структуры объектов. Вместо этого, характер узла графа сродни узлу oct/quad tree. Более того, узлы группируются в пучности по пространственному признаку для оптимизации пространственных запросов. Предполагаю, что на основе этого графа будет проще построить механизм предсказаний для загрузки ресурсов. Проще будет построить систему профилирования производительности рендера и проще будет "настраивать" производительность через локльные изменения размеров узлов и их количества.
---
Правка: небольшой косяк
Не скажу про scene graphs, но вообще говоря очень часто делается просто "прошивка" множества объектов по тому или иному признаку. При этом образуется набор графов над одними и теми же узлами.
Очевидным образом есть более-менее статические в смысле связей прошивки, а есть - сильно динамические.
Более того, есть прошивки, которые по мере улучшения уходят от графов всё дальше и дальше.
Крайним случаем таких прошивок является dependency graph для обновления и/или рендеринга мира.
Подробнее:
Game Object Structure: Scene Graphs Revisited by Kyle Wilson
Dependency Graphs In Games by Jelle van der Beek
Highly Detailed Continuous Worlds: Streaming Game Resources from Slow Media by Stuart Denman
A Streaming Bestiary by Kyle Wilson
Еще можно почитать про гиперграфы Maya - они немножко не про это, но тоже очень полезно.
кстати, я тут как раз решил рефакторить свою систему анимации, в которой самое неуклюжее место это скелет. его мне хотелось бы заменить на что нибудь более красивое и обобщеное. то есть полноценный scene-graph. базовым паттерном, на котором я решил его строить, является паттерн Visitor. который позволяет очень четко разграничивать логику и данные, что является Хорошим Делом.
но встала еще одна проблема в плане организации логики. хочется иметь сложные алгоритмы просчета графа и что бы самому в них не путатся. для этого надо граф строить на основе state machines. для упрощения задачи, не будем требовать от графа, что бы он был сильно data-driven. это все от лукавого :)
к счастью я в песочнице буста нашел отличные библиотеки для создания динамических визиторов аля Александреску и машин состояний. единственное что настораживает, что их не включили до сих пор в буст, и вроде не собираются включать. может быть там есть какие то косяки? может быть лучше самому написать? уф... не знаю. не хочется писать велосипеды
да нет, косяков там (если верить обсуждениям) вроде нет.
у меня приятели вовсю используют.
да и у нас народ частенько песочницей балуется.
aruslan
Спасибо
subscribe на всякий случай
Тема в архиве.