SceneGraph

[perry]

Začal jsem pracovat na složitějším projektu, kde potřebuju fyziku a kolize. Přidal jsem do enginu scene-graph a potřeboval bych nějaké typy a názory, na to, co jsem udělal

Takže co mám
Každý objekt ve scéně je vytvořen základní posloupností uzlů v grafu

[TeaTime]

Moc o tom nevím, jen mám obavu, jestli to neděláš moc obecně. Aby se pak nestalo, že to bude vhodné jen na gravitaci ale na tu to bude moc obecné.

Spíš bych to udělal tak, že součástí SceneGraph bude jen grafika a žádná logika. Samotnou logiku bych radši neudržoval v tolik rozvětvené struktuře jako je SceneGraph ale v jednodužší struktuře (množina - set). Ovlivnění gravitací bych tam dal spíše pomocí kompozice objektů - tím myslím, že budeš mít objekt reprezentující nějakou věc a ten objekt bude obsahovat jako membery jednak objekt SceneGraphu a jednak objekt zařizující gravitaci.

Něco jako bys měl jednu entitu a té přiřazoval role.

Mám to takhle nějak ve 2d hře co teď dělám. U větší 3d hry to bude asi trochu odlišné, ale myslím si, že tím spíš by to nechtělo moc míchat grafiku (scene graph a transformace) s logikou.

[perry]

Logiku jako logiku mám oddělenou. Pouze jeden uzel grafu (SceneObject) je takový wrapper nad vším a víceméně tvoří pevný bod ve struktuře, přes kterou můžu dohledat všechny objekty)
Fyziku musím mít v tom grafu protože mi updatuje pozice, popř. deformuje meshe.
_________________
Perry.cz

[TeaTime]

Ok, já asi nejsem ten pravý, co ti s tímhle poradí.

[quas4]

perry> uvahami nad SceneGraph / SceneObject bych se vubec netrapil a nedoporucuji se vydavat timto smerem. K cemu potrebujes grafovou reprezentaci modelu/meshu/objektu? Culling? Hierarchicke transformace? Kolik takovych "objektu" ma skutecne vice nez jeden uzel a animuji se?

[perry]

[Radis]

Tak vetsina enginu je v dnesni dobe component-based, jinak se to uz dneska snad ani nedela... Takze nodes by IMHO mely byt proste nejake kontejnery komponent, pricemz transformace je povinna komponenta a ma referenci na svou parentni transformaci (=> graf). Pak budes mit komponenty na renderovani, na fyziku, skripty...

Takze ve tvem prikladu bys mel nejaky root a pak dva kontejnery komponent (gameobject#1, gameobject#2) a oba by mely dve komponenty (transformace, mesh).

Kdyz u nejakeho objektu budes potrebovat fyziku, tak mu proste pridas fyzikalni komponentu (jako je v Unity Rigidbody).

[quas4]

z vlastni zkusenosti vim ze tahat do enginu hierarchii transformaci neprinasi zjednoduseni ale naopak. Engine by mel pracovat s co nejjednodussi reprezentaci dat a vztahy mezi modely / meshi / objekty ma resit az ridici logika. Doporucuji precist diskusi pod clankem: http://c0de517e.blogspot.cz/2010/03/3d-engines-out-there.html

[perry]

Mám tam něco jako tohle:

http://www.perry.cz/files/scenegraph.png

Jako komponenty se to chová pro uživatele, ten když nechce, do grafu nijak šahat nemusí. Nastavuje object->AddMesh(), object->AddLogic() apod. Uvnitř je to pak ale celé spojené do grafu, místo aby to bylo v nějakém listu.

Jednotlivé typy uzlů (BulletShape, SubMesh apod) jsou pak ve svých vlastních managerech, které se starají o update fyziky, běh skritpů, rendering apod. Strom využiji pak vlastně pouze pro rendering, kde se submesh dotazuje na nejbližší TransformNode aby věděl, kam ten model vykreslit.

Např. výsledek z BulletShape se vždy promítne do nejbližší vyšší TransformNode a pak se zpětně promítne do všech uzlů ve stromu pod ním.
Když uživatel potřebuje, může si pak ručně ten strom upravit například vložením nějaké mezi transformace, nebo nějak přilepit neviditelné čistě kolizní objekty, které budou existovat pouze v Bulletu a nikde jinde se s nimi nebudu muset zaobírat.

Můj hlavní cíl je udělat to co nejpružnější a nejuniverzálnější. V 90% případů se to nevyužije, ale radši teď počítat s těmi 10%, než to pak celé předělávat
_________________
Perry.cz

[Ladis]

Zauvažuj o možnosti to spíš teď udělat jednoduše za 10 % času a příp. později předělat, pokud nebude vyhovovat. Jinak nechápu ty problémy: 1) vagóny jsou spojené pevně, ne na gumě -> žádná fyzika, 2) animace kol = jen točení, fyziku potřebuješ jen na pérování, ale to stačí dost jednoduše napodobit, 3) najíždění aut na vagón = pevná animace (jak moc by musel být silný vítr, aby to zfoukávalo ta auta?).

Prostě si musíš uvědomit, jestli je cílem udělat tu hru v rozumném čase, nebo se v tom babrat. Obě možnosti jsou ok, ale nejdou dohromady (klidně si dělej svou hru roky a každý rok pod jiným tématem).

[VODA]

Osobně bych žádný scene-grafy neřešil, je to zbytečně složité a ty vazby (hierarchie) se dají udělat i bez toho. Jak už tu padlo (quas4), graf spíš věci komplikuje. Např. já v enginu žádnou takovou věc nemám a ještě jsem nenarazil na případ, kde bych to postrádal.

[Radis]

Perry: No jestli scene graph delas kvuli tem vlackum, tak to je vazne overkill

Graf na obrazku mi prijde dost prekomplikovany... Tolik typu uzlu a vlastni manager pro kazdy z nich mi nedava moc smysl. TransformNode, Transform, ObjectInfo, SceneObject - opravdu jsou vsechny tyhle typy uzlu potreba?

[perry]

[Radis]

[perry]

Tak jsem to začal předesignovávat na ten Componentn-based system.

Udělal jsem komponenty:
- BulletComponent
- GraphicsComponent - obsahuje list submeshu (každý má svojí world matici) - ty pak třídím podle materiálu apod. v rendereru
- BehaviorComponent
- MyBoundingObjectComponent
- TransformComponent

Všechny implementují IComponent rozhraní.

Pak mám SceneObject, který obsahuje seznam IComponent. Při přidání objektu do scény se jednotlivé komponenty přiřadí do managerů
- BulletComponent do Bulletu
- GraphicsComponent do RenderManageru
- BehaviorComponent do LogicManageru
- MyBoundingObjectComponent je tam jen pro nějaké debug účely, protože Bullet neumí testovat objekt / paprsek přímo).
- TransformComponent pak drží pozici objektu ve scéně

Teď mám akorát logický problém, jak dostat pozici ať už z BulletComponent nebo TransformComponent do GraphicsComponent . Jak se tohle řeší?
_________________
Perry.cz