Архитектура движка.Форум

[?] Минусы SceneGraph'ов

#0
22:55, 22 янв 2006

Название темы не вполне корректное, т.к. SceneGraph'ы бывают очень разными.

На всякий случай, скажу что за свою пока еще небогатую практику встречался с реализациями, которые:

1. Являются ациклическими (иной раз раздражет искусственное наведение зависимостей через разные вызовы в обработчиках узлов);
2. Имеют классы основных узлов для transforms, render-states, renderables;
3. Выполняют пространственные запросы;
4. Отражают полную семантику объектов (т.е. если надо изобразить дом с интерьером, то интерьер расписывается по нисходящей в иерархии).

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

Вообщем, хочу чтобы мне помогли определиться с минусами "классических" графов.

---
Пока не буду выливать все свои соображения и недоумения, чтобы никого не смущать. Однако, продумываю вариант, где к графу не предъявляется никаких требований в отношении связей - следовательно нет иерархии. Сам граф не отражает семантической структуры объектов. Вместо этого, характер узла графа сродни узлу oct/quad tree.  Более того, узлы группируются в пучности по пространственному признаку для оптимизации пространственных запросов. Предполагаю, что на основе этого графа будет проще построить механизм предсказаний для загрузки ресурсов. Проще будет построить систему профилирования производительности рендера и проще будет "настраивать" производительность через локльные изменения размеров узлов и их количества.
---


Правка: небольшой косяк

#1
0:08, 23 янв 2006

Не скажу про 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 - они немножко не про это, но тоже очень полезно.

#2
2:32, 23 янв 2006

кстати, я тут как раз решил рефакторить свою систему анимации, в которой самое неуклюжее место это скелет. его мне хотелось бы заменить на что нибудь более красивое и обобщеное. то есть полноценный scene-graph. базовым паттерном, на котором я решил его строить, является паттерн Visitor. который позволяет очень четко разграничивать логику и данные, что является Хорошим Делом.
но встала еще одна проблема в плане организации логики. хочется иметь сложные алгоритмы просчета графа и что бы самому в них не путатся. для этого надо граф строить на основе state machines. для упрощения задачи, не будем требовать от графа, что бы он был сильно data-driven. это все от лукавого :)
к счастью я в песочнице буста нашел отличные библиотеки для создания динамических визиторов аля Александреску и машин состояний. единственное что настораживает, что их не включили до сих пор в буст, и вроде не собираются включать. может быть там есть какие то косяки? может быть лучше самому написать? уф... не знаю. не хочется писать велосипеды

#3
2:38, 23 янв 2006

да нет, косяков там (если верить обсуждениям) вроде нет.
у меня приятели вовсю используют.
да и у нас народ частенько песочницей балуется.

#4
8:04, 23 янв 2006

aruslan
Спасибо

#5
1:05, 3 фев 2006

subscribe на всякий случай

Архитектура движка.Форум

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