Войти
ПрограммированиеФорумГрафика

И всё-таки SceneGraph. (2 стр)

Страницы: 1 2
#15
13:24, 27 янв. 2010

innuendo
>я не знаю, что ты понимаешь под SG, то что я понимаю, это классический от OpenInventor, так вот там в SG и трансформации, и др фичи
я не знаю что такое SG, но народ типично любит намешать кучу несвязанных вещей и назвать это SG.
SG из NVSG, OSG, OGRE - все непонятно для чего написанная иерархия, которая порождает ненужные связи в коде и провоцирует написание ненужного кода.
мешать в кучу слабо связанные вещи неправильно, порождать ненужные связи совсем плохо.
обычно вменяемые люди стараются разделять код разных сущностей, писать меньше кода, не писать ненужный код, писать нужный, лол.

#16
13:53, 27 янв. 2010

Scene graph - граф сценъ. Все дело в переводе - если просто перевести, не ознакомившись с термином как его создали, то конечно - ето только граф сценъ какой-то. Любая йерархия по сцене.
А возникло оно в виде нодов, содержаших разнородную информацию для рендеринга - трансформации, освещение, матриалъ с соответно йерархичнъм их сетапом, якобъ оптимизировать переключение стейтов + йерархично задавать свойства.
Все ето конечно сейчас неправда, т.е. сейчас надо иначе даннъе разкладъвать.

А иначе люди правильно говорят, объчно такие структуръ формируются еволюцией по ходу проекта.
У нас ето бъло так:
  - вектор для всех обьектов мира -> 2D грид для симуляции, логика бъстро находит кто вокруг обьекта + heightfield для ландшафта
  - квад-три для бъстрого фрустум куллинга ландшафта, заодно по видимъм нодам - получение обьектов из 2D грида
  - обьект хранит указатель на своего родителя
  - рендер рисует/апдейтит сначала родителей, т.е. если обьект видим и охота его проапдейтить или нарисовать, сначала ето делается для его родителя, если уже не сделано на етом же кадре
Вот такой пирог из трех слоев - 'граф' трансформаций в обьктах, разбиение мира для симуляции и йерархия поверх ландшафта для куллинга.

#17
14:08, 27 янв. 2010

Xunter
> SG из NVSG, OSG

Это всё ягоды с одного поля...  SG = Scene Graph, от него же VRML

Xunter
> все непонятно для чего написанная иерархия, которая порождает ненужные связи в
> коде и провоцирует написание ненужного кода.

SG о котором я говорю, это классическое понимание сцены ( наверно ещё с IrisGL ), которое уже было, когда мы все в детсад ходили - я точно.
Этот самый SG - очень низкоуровневое описание сцены, свои задачи выполняет и писали его очень вменяемые люди :)

#18
15:58, 27 янв. 2010

про канонический 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-летней давности на структуру сцены современной игры и считать это хорошим решением -
по мне является признаком легкой невменяемости.

#19
16:04, 27 янв. 2010

Xunter
> SG о котором я говорю, это классическое понимание сцены ( наверно ещё с IrisGL
> ), которое уже было, когда мы все в детсад ходили - я точно.
> на классическое понимание сцены, которое уже было когда ты в детсад ходил мне
> глубоко всё-равно.
> Многие вещи устаревают, и задачи у людей, наверное, были другие. Зачем тот SG в
> современных играх я не знаю.
> Экстраполировать структуру для рендера 20-летней давности на структуру сцены
> современной игры и считать это хорошим решением -
> по мне является признаком легкой невменяемости.

А кто заявляет и экстраполирует ? Я рассказал про классическое понимание SG. Естественно, что в играх это слабо применимо. Но, есть задачи 3D графики - где рендер 20 летней графики очень даже используется и СЕЙЧАС :)

http://developer.nvidia.com/object/scenix-details.html

Страницы: 1 2
ПрограммированиеФорумГрафика

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