.[ ČeskéHry.cz ].
SceneGraph
Jdi na stránku Předchozí  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
Radis



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

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

Jo, komponenty mezi sebou obcas musi komunikovat, takze se to resi tak, ze GameObject ma metodu GetComponent<T>() a navic komponenta vi, k jakemu gameobjectu patri.

Takze treba takto:
var position = this.GameObject.GetComponent<Transform>().Position;

Samozrejme si to muzes ruzne zjednodusit pomoci pomocnych properties pro nejpouzivanejsi komponenty, aby ses neupsal k smrti a nakonec z toho muze byt treba:

var position = Transform.Position;

(v C++ vlastne properties nemate... ale myslenku jsi asi pochopil Smile)
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
perry



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

PříspěvekZaslal: 18. leden 2015, 11:35:02    Předmět: Odpovědět s citátem

Díky... ještě jeden dotaz Smile

Když jsi mluvil o parent transform např. Co když udělám update rodiče. Musím pak udělat něco jako compoment.Invalidate() a přepočítat pozice všech potomků. Tzn. že rodič musí mít informace o potomcích a v transformacích mám vlastně strom. Plus abych přepočítal pozice, tak musím držet offsety v rotaci, translaci a scalu mezi uzly, jenom pozice mi nepomůže. Nebo to jde i jinak a lépe? Smile
_________________
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: 229

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

Jo, transform musi mit lokalni scale, lokalni rotaci a lokalni pozici. A ano, transform musi vedet o svych childech.

Jeste se pak podivej na tento clanek o dirty-flag, cachovani world transform, a deferred recalculation:
http://gameprogrammingpatterns.com/dirty-flag.html
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
perry



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

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

Díky.. tohle už mám funkční ze scene graphu Smile Jen jsem myslel, jestli se to nedělá nějak jinak
_________________
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: 264

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

Radis napsal:
Jo, komponenty mezi sebou obcas musi komunikovat, takze se to resi tak, ze GameObject ma metodu GetComponent<T>() a navic komponenta vi, k jakemu gameobjectu patri.

Tohle bych nedělal, zavání to špatným konceptem - ta metoda getComponent bude iterovat přes všechny komponenty a snažit se je přetypovat. Dynamické ořetypování = skoro vždycky chyba. Co když tam bydeš mít dvě BulletComponent, kterou to pak vybere? Jedna ze základních výhod 'composition over inheritance' je, že objekt může obsahovat několik objektů stejné třídy.

Dal bych to tak, že prostě GraphicsComponent dostane BulletComponent v konstruktoru nebo pomocí nějaké metody. Ten, kdo volá jejich konstruktory, zná jejich typy, tak je může rovnou spojit. Na úrovni SceneGraphu bych to vůbec neřešil.

Jestli chceš nějaký sofistikovanější způsob sdílení referencí na různé objekty, tak bych maximálně udělal nějakou další strukturu nad tím, která už by byla zaměřena konkrétněji na specifičtější použití (třeba na vlaky, ale to nemám úplně promyšlené do detailů).
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
perry



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

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

citace:
Tohle bych nedělal, zavání to špatným konceptem - ta metoda getComponent bude iterovat přes všechny komponenty a snažit se je přetypovat. Dynamické ořetypování = skoro vždycky chyba.


Tohle řeším tak, že IComponent má metody GetTransform() return NULL, GetGraphics return NULL apod. Uvnitř příslušných tříd pak tuhle virtuální metodu přetížím a vracím this. Žádný casty nikde nepotřebuji.

Add opakovaný výskyt toho samého. U nečeho jo, ale třeba Transform má ten objekt jen jeden a BoundingObject taky (pokud potřebuji více, mám vymyšlenou třídu ComplexBoundingObject, která to zapouzdří, ale nikdy jsem na to zatím nenarazil v mých potřebách). Behavior mám v listu, toho může být více.

Ten GetComponent má pak dvě verze - GetCompomenent<T> a GetComponent<T>(index). Ve většině případů mi ale stačí ta první verze.
_________________
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: 264

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

Stejně bych to prostě předával v konstruktoru. Je to mnoooohem jednodužší a umí toho potenciálně trochu víc (umí to např vybrat kterou instanci BulletComponent použiješ, pokud bys jich měl více a chtěl je třeba střídat). Ale hlavně je to jednodužší a nepotřebuješ k tomu kopu kódu v IComponent a v GameObjectu.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Radis



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

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

TeaTime: Ten priklad je z Unity API, jeste tam maji variantu GetComponents, samozrejme. Byl to jenom priklad, stejne jako se vsim ostatnim je moznosti strasne moc. Mne osobne tohle prijde nejpohodlnejsi. V zacatcich je to treba jedno a predavat si vsechno pres konstruktory muze nekomu pripadat jako prima napad, ale ver tomu, ze u realnych projektu je podobna metoda vazne handy. (Nejen v Unity, treba UDK ma tuhle vec samozrejme taky.)

Type checking nebo casting je samozrejme vzdycky red flag a clovek by mel zpozornet, ale to neznamena, ze nemaji legitimni vyuziti.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
TeaTime



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

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

Radis napsal:
TeaTime: Ten priklad je z Unity API, jeste tam maji variantu GetComponents, samozrejme. Byl to jenom priklad, stejne jako se vsim ostatnim je moznosti strasne moc. Mne osobne tohle prijde nejpohodlnejsi. V zacatcich je to treba jedno a predavat si vsechno pres konstruktory muze nekomu pripadat jako prima napad, ale ver tomu, ze u realnych projektu je podobna metoda vazne handy. (Nejen v Unity, treba UDK ma tuhle vec samozrejme taky.)


Já jen, že jsem to jednou zkoušel pomocí toho GetCompoment a podruhý pomocí konstruktorů a metod a i když ani jeden z těch projektů není dokončený, tak se pak ten přístup s těmi konstruktory ukázal jako jednoznačný krok vpřed. Příště bych to udělal ještě tak, že by tam nebylo ani GetComponent ani to s těmi konstruktory, ale udělal bych to tak, že bych si udělal zvlášť strukturu, která by se plnila v místě, kde se volají konstruktory objektů a která by udržovala co nejpřehledněji všechny objekty tak, jak by měly být ve hře (co nejmíň obecně, žádná dědičnost, žádné interfacy - prostě ukazatel tpu MyObjectA bude obsahovat objekt přesně typu MyObjectA). Jestli to bude krok vpřed, to teď samozřejmě nemůžu říct. S čím jsem si docela jistý je, že bych vůbec neřešil přístup ke komponentům na téhle úrovni abstrakce, ale o něco výš.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
perry



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

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

Tak jsem to nějak základně přepsal. uff.. Díky za podmětné rady a tipy Smile

Co se týče konstruktorů, to řešení se mi moc nelíbí. Co když chci pak k objektu po jeho vytvoření něco přidat / smazat?
_________________
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: 264

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

perry napsal:
Co se týče konstruktorů, to řešení se mi moc nelíbí. Co když chci pak k objektu po jeho vytvoření něco přidat / smazat?

Ok, myslím, že už jsem to celé popsal docela důkladně, nebudu tě už dál přemlouvat Smile.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
quas4



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

PříspěvekZaslal: 18. leden 2015, 20:35:40    Předmět: Odpovědět s citátem

zkusim jeste zareagovat.

Myslim ze pri vyvoji hry je casto potreba sahnout k unikatnim resenim ktere odrazeji presne naroky konkretni hry a hw. Obecne pojmy jako IComponent, GameObject jsou presne pravy opak. Co rika "GameObject" o sve podstate? imho vubec nic..

Zkusim na konkretnich obrazcich:



Na tomto obrazku je videt hodne stromu ktere se v pri rychle jizde jen mihaji. Ale zadny objekt/instance (mimo auto) ve viditelne scene vlastne neni. Uz pri sestavovani "areny" jsou pro kmeny vytvoreny v bulletu staticke capsule. Meshe kmenu se stejnou texturou jsou transformovany a pospojovany po blocich do velkych meshu. Tyto velke meshe (resp. jejich vbo/vao) a aabb vlozeny do BVH pro testovani co z pohledu kamery kreslit. Samotne "objekty" jsou uplne zahozeny! Naopak koruny stromu se musi kreslit s blendingem (alpha testing je na mobilnich zarizenich nepouzitelny) takze je potreba jine reseni, ale ani v nem nefiguruje zadny "objekt" - jen jednoducha data usporadana presne podle potreby pricemz nejsou promichana s zadnymi dalsimi daty ktera s nimi nesouvisi. Data driven development ma peknou poucku o znalosti svych dat (viz prednasky od Mike Acton). Tj. na zacatku sice pracuji s modelem, jeho transformaci a dalsimi parametry ale ty v urcite fazi prestavaji byt potreba a data jsou pretransformovany do uzitecnejsi a pro dany ucel rychlejsi podoby.



na tomto obrazku jsou "objekty" ale jsou to jen ty pneumatiky. Vse(!) ostatni je opet zapeceno (pri loadingu areny) do bloku kvuli minimalizaci poctu drawcalls (vcetne statickych stencil stinu!). Jina hra, na jinem hw muze mit jine optimalni reseni. Pneumatiky jsou vlastne jen struct mesh, shadow caster a pointer do bulletu (ten mam upraveny podle potreb hry - mnohem setrnejsi udrzba tzv. islands apod., celkove je navrh bulletu (mimo obsazenou matematiku) dost velke nestesti). Data pro dynamicke modely jsou spravovany v 2d aabb stromu kvuli viditelnosti, posouvani modelu nasledkem kolize a prubeznemu odebirani/pridavani dyn. rigid bodies do bulletu. Opet zadne komplikovane datove struktury. Jen to co je skutecne potreba a v podobe ktera je rychlostne nejvhodnejsi pro cpu a obzvlast jeho cache.

Prispevkem chci jen demonstrovat ze OOP a souvisejici vzory ktere mnoho knih pro psani her tak propaguje nejsou buhvico (casto jsou bohuzel napsany lidmi kteri zadnou velkou hru nenapsali). Lepsi (a osvedcilo se mi) je byt velmi pragmaticky a pri navrzich uvazovat o datech ne o objektech. Prepisovat takovy na prvni pohled "roztristeny" system je ale ve vysledku mnohem snazsi nez se snazit naroubovat mnoho pozadavku a potreb do jednoho provazaneho systemu trid a komponent.

ps: prosim nevsimat si toho deste (prave ladim a experimentuju).
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Radis



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

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

quas4: Jako jasne, ja taky nejsem zastancem pouzivani navrhovych vzoru za kazdou cenu, spis naopak. Na druhou stranu je dobre nedostat se do opacneho extremu. Urcite veci se standardne delaji urcitym zpusobem a ma to svoje duvody. Pamatuju si doby, kdy jsem cetl o tom, jak nekdo vitezoslavne pouzil ve svem 3D enginu (myslim, ze to bylo pro hru Tony Hawk) komponenty a jaky to byl pokrok proti tehdejsimu standardnimu postupu. Dnes uz je to normal a malokdo to dela jinak. Je to proste vyvoj, je to odzkousene praxi. Neni to nejaky vymysl akademiku nepolibenych praxi.

Nepripada mi, ze by pojmy jako Actor (GameObject) nebo komponenta byly nejak vyprazdnene a nevypovidaly nic o sve podstate. Naopak pro popis sceny se dost hodi. Nazev rozhrani IComponent ti mozna nic nerekne, ale kdyz se podivas treba na objekt s konkretnimi komponentami jako Rigidbody + SphereCollider + SpotLight + Transform, tak uz o sobe rika docela dost, ne?

Spojeni statickych objektu do jednoho meshe kvuli drawcalls tato reprezentace samozrejme nevylucuje, viz Unity Smile

Je jasne, ze pro kazdou hru takovouto reprezentaci nepotrebujes. Mozna ani perry by to nepotreboval, nevim. Ale obecny 3D engine si bez toho predstavit nedokazu.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
nem0



Založen: 23. 03. 2009
Příspěvky: 31

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

perry napsal:
Všechny implementují IComponent rozhraní.


Aky zmysel ma aby vsetky komponenty mali spolocneho predka? Vzdy ked toto niekde vidim, tak je to len na to, aby som si z GameObjectu vedel vypytat komponent daneho typu. Za aku cenu ale?

1. GameObject musi skladovat pointre na svoje komponenty - na beznej 32bitovej platforme to zozerie 4B x pocet komponentov per game object x pocet game objectov. Momentalne robim na hre, ktora ma cca 2 miliony objektov, 99% z toho su obycajne staticke meshe. Keby sme ich skladovali takymto sposobom, zozeru mi len tieto pointre 4B x 2miliony game objectov = 8MB, a to nevravim o rezii okolo. A to tieto pointre nikde v hre nie je treba a v zivote ich nikto negetuje, lebo renderer si ich aj tak musi drzat u seba v liste.

2. Volanie virtualnych funkcii
3. Cache missy - kapitola sama o sebe
4. nemoznost prisposobovat si sposob prace s danym komponentom - uplne ine potreby ma mesh component, ktory je na ~99% objektov, a ine camera component, ktory je na ~0.1%

Radis napsal:
Ten priklad je z Unity API

Mnoho ludi, co v Unity robili nieco vacsie a aj samotne Unity vedia, ze je GetComponent pomale

Radis napsal:
transform musi vedet o svych childech

alebo child o svojom parentovi Wink

perry napsal:
Tohle řeším tak, že IComponent má metody GetTransform() return NULL, GetGraphics return NULL apod.

Zbavis sa tym sice castovania ale nahradis ho virtual callom a stale budes musiet prechadzat vsetky komponenty. Naco vobec mat komponent ako classu?

K teme: ako to tu uz zaznelo, zlozito riesit scene graf je vo vacsine pripadov overkill, standartne hry maju velmi plytky scene graf, u nas ma nejakeho potomka < 0.01% objektov a aj z toho je vacsina objektov nabindovana na nejaku kost a nie priamo na objekt a netreba zabudat, ze s hierarchiou treba riesit aj spravne poradie updatovania
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
quas4



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

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

nem0> tak tak. virtualni funkce je taky mimojine cache-miss.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
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 Předchozí  1, 2, 3  Další
Strana 2 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