Тёмная тема
- innuendo
- Постоялец
innuendo
>я не знаю, что ты понимаешь под SG, то что я понимаю, это классический от OpenInventor, так вот там в SG и трансформации, и др фичи
я не знаю что такое SG, но народ типично любит намешать кучу несвязанных вещей и назвать это SG.
SG из NVSG, OSG, OGRE - все непонятно для чего написанная иерархия, которая порождает ненужные связи в коде и провоцирует написание ненужного кода.
мешать в кучу слабо связанные вещи неправильно, порождать ненужные связи совсем плохо.
обычно вменяемые люди стараются разделять код разных сущностей, писать меньше кода, не писать ненужный код, писать нужный, лол.
Scene graph - граф сценъ. Все дело в переводе - если просто перевести, не ознакомившись с термином как его создали, то конечно - ето только граф сценъ какой-то. Любая йерархия по сцене.
А возникло оно в виде нодов, содержаших разнородную информацию для рендеринга - трансформации, освещение, матриалъ с соответно йерархичнъм их сетапом, якобъ оптимизировать переключение стейтов + йерархично задавать свойства.
Все ето конечно сейчас неправда, т.е. сейчас надо иначе даннъе разкладъвать.
А иначе люди правильно говорят, объчно такие структуръ формируются еволюцией по ходу проекта.
У нас ето бъло так:
- вектор для всех обьектов мира -> 2D грид для симуляции, логика бъстро находит кто вокруг обьекта + heightfield для ландшафта
- квад-три для бъстрого фрустум куллинга ландшафта, заодно по видимъм нодам - получение обьектов из 2D грида
- обьект хранит указатель на своего родителя
- рендер рисует/апдейтит сначала родителей, т.е. если обьект видим и охота его проапдейтить или нарисовать, сначала ето делается для его родителя, если уже не сделано на етом же кадре
Вот такой пирог из трех слоев - 'граф' трансформаций в обьктах, разбиение мира для симуляции и йерархия поверх ландшафта для куллинга.
Xunter
> SG из NVSG, OSG
Это всё ягоды с одного поля... SG = Scene Graph, от него же VRML
Xunter
> все непонятно для чего написанная иерархия, которая порождает ненужные связи в
> коде и провоцирует написание ненужного кода.
SG о котором я говорю, это классическое понимание сцены ( наверно ещё с IrisGL ), которое уже было, когда мы все в детсад ходили - я точно.
Этот самый SG - очень низкоуровневое описание сцены, свои задачи выполняет и писали его очень вменяемые люди :)
про канонический SG ( который только про рендер, иерархия по материалам, свойствам, стейтам ) я, в общем, знаю,
вроде как у народа очень быстро понятие SG мутировало в иерархию игровых объектов.
при том с абстрактным GO, в который понапихали и transform и culling info и еще всякого,
иерархии, наверное эволюционно, строились забавным образом - отношения parent-child строили на странном смешении
понятий отношения parent-child из transform tree и абстрактных умозаключениях о игровых сущностях.
довольно характерный и унылый пример - http://www.gamedev.ru/code/articles/?id=4226
про какие-то такие иерархии строчки
render::node n = Plane.find_node_recursive(“FlapsLeft”);
отсюда http://www.gamedev.ru/code/articles/?id=4234
и даже в современном Unity3D, где, в отличии от OGRE, знают о component design,
вся сцена - это иерархия GameObject "All objects in your game are inherently GameObjects"
у которого есть, например, мемберы guiTexture и hingeJoint.
это, на самом деле, just fine, если нам надо кучу энтропии на коротком забеге.
на не особо маленьком отрезке времени оно мутирует во что-то страшное.
и думается что ConcreteGameObject : Transform<Gluer>, SpatialDBStaticEntry<Gluer>, .. 10штук<Gluer> {};
наверное все-таки лучше. отдельно transform tree, отдельно spatial db и т.д.
каждый компонент лежит в своей подсистеме как ей удобно, хоть grid, хоть tree, graph, list, hash и пр.
Z
>Вот такой пирог из трех слоев - 'граф' трансформаций в обьктах, разбиение мира для симуляции и йерархия поверх ландшафта для куллинга.
вот оно понятно для чего всё сделано, но уже наверно правильно говорить об организации сцены в игре (что очевидно game specific).
и в каждом отдельном случае интересно скорее как какая подсистема реализовывалась, какие проблеммы, как решали.
как deathtrack рожали, какой ландшафт в аллодах.
а не об абстрактно-иерархичном SG. потому-что хорошие решения почему-то плохо ложатся на общую иерархию, и хорошо на свои специфические db.
innuendo
>SG о котором я говорю, это классическое понимание сцены ( наверно ещё с IrisGL ), которое уже было, когда мы все в детсад ходили - я точно.
на классическое понимание сцены, которое уже было когда ты в детсад ходил мне глубоко всё-равно.
Многие вещи устаревают, и задачи у людей, наверное, были другие. Зачем тот SG в современных играх я не знаю.
Экстраполировать структуру для рендера 20-летней давности на структуру сцены современной игры и считать это хорошим решением -
по мне является признаком легкой невменяемости.
Xunter
> SG о котором я говорю, это классическое понимание сцены ( наверно ещё с IrisGL
> ), которое уже было, когда мы все в детсад ходили - я точно.
> на классическое понимание сцены, которое уже было когда ты в детсад ходил мне
> глубоко всё-равно.
> Многие вещи устаревают, и задачи у людей, наверное, были другие. Зачем тот SG в
> современных играх я не знаю.
> Экстраполировать структуру для рендера 20-летней давности на структуру сцены
> современной игры и считать это хорошим решением -
> по мне является признаком легкой невменяемости.
А кто заявляет и экстраполирует ? Я рассказал про классическое понимание SG. Естественно, что в играх это слабо применимо. Но, есть задачи 3D графики - где рендер 20 летней графики очень даже используется и СЕЙЧАС :)
Тема в архиве.