.[ ČeskéHry.cz ].
SceneGraph
Jdi na stránku 1, 2, 3  Další
 
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> Obecné
Zobrazit předchozí téma :: Zobrazit následující téma  
Autor Zpráva
perry



Založen: 28. 07. 2009
Příspěvky: 863

PříspěvekZaslal: 17. leden 2015, 12:20:53    Předmět: SceneGraph Odpovědět s citátem

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 Smile

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

kód:
Transformace -> SceneObject
-> Transformace#1 -> Mesh#1
-> Transformace#2 -> Mesh#2
-> atd


Všechno jsou to potomci ISceneNode. SceneObject je speciální uzel, který drží info třeba o logice, nějakých skriptech apod.

Teď zapojení fyziky. Mezi např. Transformace#1 a Mesh#1 dám fyzikální uzel - ten má bounding object a pozici, provádí updaty v Update smyčce. Nakonci update se pozice přenese do Transformace#1 - to by tam bylo i zbytečné, klidně by ten fyzikálnáí uzel mohl být transformační, ale více se mi to líbilo takhle.

Řekněme, že gravitace ten objekt stáhne dolů - aplikuje se to pouze na Mesh#1. Pokud za Mesh#1 připojím další potomky, tak pak jejich pozice bude ovlivněná uzlem Transformace#1, který je ovlivně fyzikou.

Pokud ručně posunu uzel Transformace#1, změny se propagují dolů na jeho potomky a promítnou se do fyziky (i když tohle by se moc dělat nemělo, fyzika by to měla řídit silami).

V každém snímku pak pokud dojde ke změně, projdu strom změněných uzlů a v každém transformačním uzlu spočtu aktuální pozici ve světě, s kterou pak renderuji. Tzn. předpočítám si pozici a offsety od minulého transformačního uzlu.

Vypadá to tak nějak OK ?
Díky
_________________
Perry.cz
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
TeaTime



Založen: 17. 06. 2011
Příspěvky: 263

PříspěvekZaslal: 17. leden 2015, 15:22:41    Předmět: Odpovědět s citátem

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.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
perry



Založen: 28. 07. 2009
Příspěvky: 863

PříspěvekZaslal: 17. leden 2015, 16:17:56    Předmět: Odpovědět s citátem

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
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
TeaTime



Založen: 17. 06. 2011
Příspěvky: 263

PříspěvekZaslal: 17. leden 2015, 16:21:49    Předmět: Odpovědět s citátem

Ok, já asi nejsem ten pravý, co ti s tímhle poradí.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
quas4



Založen: 18. 10. 2007
Příspěvky: 199

PříspěvekZaslal: 17. leden 2015, 17:37:49    Předmět: Odpovědět s citátem

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?
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
perry



Založen: 28. 07. 2009
Příspěvky: 863

PříspěvekZaslal: 17. leden 2015, 17:46:03    Předmět: Odpovědět s citátem

citace:
Kolik takovych "objektu" ma skutecne vice nez jeden uzel a animuji se?


Budu tam mít vláčky Smile, kde celý vlak = objekt s X vagony.. popř. se můžou spojit dva vlaky do jednoho apod. Takže tady mi přijde takhle reprezentace celkem užitečná. Plus potřebuju rozanimovat kola, takže ta musí viset samostatně.

Nebo např. převoz aut na vlaku.. auto přijede, najede na vlak a pak dál se "veze".. opět s grafem easy, jen přepnu uzel a auto se dál pohybuje s vlakem / vagonem.
_________________
Perry.cz
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Radis



Založen: 29. 03. 2014
Příspěvky: 216

PříspěvekZaslal: 17. leden 2015, 17:54:50    Předmět: Odpovědět s citátem

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).
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
quas4



Založen: 18. 10. 2007
Příspěvky: 199

PříspěvekZaslal: 17. leden 2015, 18:12:36    Předmět: Odpovědět s citátem

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
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
perry



Založen: 28. 07. 2009
Příspěvky: 863

PříspěvekZaslal: 17. leden 2015, 19:10:08    Předmět: Odpovědět s citátem

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 Smile
_________________
Perry.cz
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Ladis



Založen: 18. 09. 2007
Příspěvky: 1480
Bydliště: u Prahy

PříspěvekZaslal: 17. leden 2015, 20:50:10    Předmět: Odpovědět s citátem

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).
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
VODA



Založen: 29. 07. 2007
Příspěvky: 1688
Bydliště: Plzeň

PříspěvekZaslal: 17. leden 2015, 23:59:23    Předmět: Odpovědět s citátem

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.

Ladis napsal:
(klidně si dělej svou hru roky a každý rok pod jiným tématem).

Tohle mě tedy trochu urazilo... a vlastně ten výrok ani moc nechápu. Mad
_________________
Opravdovost se pojí s trýzní...
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Radis



Založen: 29. 03. 2014
Příspěvky: 216

PříspěvekZaslal: 18. leden 2015, 09:31:15    Předmět: Odpovědět s citátem

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

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?

citace:
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.

A proc by komponenty nemohly byt v listu u game objectu? Nebylo by jednodussi? Podivej se na zdrojove kody nejakych enginu a trochu se inspiruj... Komponenty maji byt proste komponenty, ne se tak jen "chovat pro uzivatele". Byt tebou, tak jdu opravdu striktne cestou "composition over inheritance", prejdu na jeden typ nodu, na gameobjects, ktere nejsou nic vic nez kontejnery komponent. Navic nechapu AddMesh a AddLogic, nebylo by treba lepsi AddComponent(new Mesh()) a AddComponent(new Behavior())? Game object prece nemuze mit presne dany seznam moznych komponent a pro kazdou z nich vlastni metodu... Ale to uz trochu rypu Smile

Jinak, jak uz tady zaznelo, popremyslej, jestli je ted nutne tam vubec mit scene graph - stejne v pripade vlacku bude graf degenerovan v podstate na list (bude hodne melky, uzly budou vsechny blizko rootu) a nic extra ti to neprinese. Jen kvuli tomu auticku na vagonu to delat nemusis.

citace:
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

Radsi se rid principy YAGNI a KISS. Usetri ti to spoustu casu a nervu.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
perry



Založen: 28. 07. 2009
Příspěvky: 863

PříspěvekZaslal: 18. leden 2015, 10:09:59    Předmět: Odpovědět s citátem

citace:
Tolik typu uzlu a vlastni manager pro kazdy z nich mi nedava moc smysl.


Vlastní manager má jen grafika (RenderManager), fyzika (tam je tim managerem vlastně Bullet) a Logika (logika je vše ostatní - není součástí stromu a je v listu).

Ad obrázek. Transform a TransformNode je to samý, jsem to blbě napsal Smile SceneNode jako taková neexistuje, ta je virtuální. Je v ní zabalené to ve žlutém rámečku. Takže SceneNode je scene object a v něm mám akorát místo listů podgraf. Když tam hodím obyčejný list, tak při renderingu hierarchických objektů mám problém.

Ale jako ano, ten graf je trochu overkill. Ty vláčky, to byl jen případ co mě zrovna napadnul Smile

citace:
Prostě si musíš uvědomit, jestli je cílem udělat tu hru v rozumném čase, nebo se v tom babrat.


Nikde jsem neříkal, že dělám hru Wink
_________________
Perry.cz
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Radis



Založen: 29. 03. 2014
Příspěvky: 216

PříspěvekZaslal: 18. leden 2015, 10:56:39    Předmět: Odpovědět s citátem

citace:
Když tam hodím obyčejný list, tak při renderingu hierarchických objektů mám problém.

Kdyz GameObject bude mit list komponent a jedna z komponent kazdeho GameObject bude Transform, ktera bude mit referenci na svou parent Transform, tak s hierarchii samozrejme zadny problem mit nebudes. Kdyz mas vagon a na nem mas auto a chces aby auto bylo childem vagonu, tak proste mas dva GameObjects:

auto.Transform.Parent == vagon.Transform && vagon.Transform.Parent == null (root).

To je cele. Auto i vagon budou mit dalsi komponenty (mesh, collider, ...) ulozene v prislusnych listech (nikoli grafech Smile) danych gameobjectu.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
perry



Založen: 28. 07. 2009
Příspěvky: 863

PříspěvekZaslal: 18. leden 2015, 10:57:45    Předmět: Odpovědět s citátem

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
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Zobrazit příspěvky z předchozích:   
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> Obecné Časy uváděny v GMT + 1 hodina
Jdi na stránku 1, 2, 3  Další
Strana 1 z 3

 
Přejdi na:  
Nemůžete odesílat nové téma do tohoto fóra
Nemůžete odpovídat na témata v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete hlasovat v tomto fóru


Powered by phpBB © 2001, 2005 phpBB Group


Vzhled udelal powermac
Styl "vykraden" z phpBB stylu MonkiDream - upraveno by rezna