SceneGraph

[Radis]

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 )

[perry]

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

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?
_________________
Perry.cz

[Radis]

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

[perry]

Díky.. tohle už mám funkční ze scene graphu Jen jsem myslel, jestli se to nedělá nějak jinak
_________________
Perry.cz

[TeaTime]

[perry]

[TeaTime]

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.

[Radis]

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.

[TeaTime]

[perry]

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

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

[TeaTime]

[quas4]

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).

[Radis]

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

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.

[nem0]

[quas4]

nem0> tak tak. virtualni funkce je taky mimojine cache-miss.