Mostanában egy lenge növényzettel és egyéb fizikával nem rendelkező objektumokkal foglalkoztam. A Havok alapjáraton 16K rigidbody-t enged egyszerre a szimulációba, ami a 16 biten tárolt értékek miatt van. Át lehet kapcsolni 32 bitre is, ami már 4giga objektum, de semmi értelme ennyivel kezdeni, és felére lassul az axissweep-teszt dupla memóriaigénye miatt. Egyébként sem ildomos minden fűt-bokrot fizikailag leképezni, csak akadályozna a mozgásban. Ez a (CDecor) osztály tehát nem tud mást, mint tartalmaz egy mesh-t, amit kirajzolhatunk, más játékra gyakorolt hatása nincsen. Fura is volt ezt csinálni, mert az elmúlt kb 1 évben csak a legfontosabb elemekkel, a játékmotor nyers mechanikájának összebarkácsolásával foglalkoztam (egy lépés előre, kettő oldalra formában). Mondjuk a framerate-re igen szép hatással tud lenni – hw instancing már nem késhet soká.
A jópofa ezekben a nagyrészt statikus dekorációkban az, hogy bevezettem egy ’parenting’ (szülő-gyerek) rendszert a játékbeli objektumok között, amivel össze lehet őket kapcsolni, amennyit a ’szülő’ elmozdul, annyit mozog a ’gyerek’ is. Ez egyébként is bevett dolog játékmotorokban. A videó elején látható, hogy a pálmát megütve a rácsatlakozott ’fagyöngyök’ együtt mozognak a levéllel, vagy az ellőtt fa kidőlő részével együtt mozog a lombja. A csatlakozásokat a pályaszerkesztőben kell kijelölni, majd töltéskor a játék megkeresi (összetett fizikai objektumok estén) a legközelebbi rigidbody-t (itt a pálma-model esetén a megfelelő levelet). Eltárolja a relatív transzformációt, majd bejegyzi a szülőnek, hogy van gyereke. Ezután ha a szülő elmozdul, értesíti a gyereket, aki frissíti a mátrixát. A kapcsolati rendszer fix tömbökkel történik, minden objektumnak max 8 gyereke lehet (egyéb ízületekkel együtt). Ha a szülő törhető, mint az kettérobbantott/lőtt fák, akkor törésnél meg kell keresni azt a darabot, amelyikhez a legközelebb van, és arra újra rá kell csatlakoztatni. Vagy törölni, ha nem maradt semmi. (esetleg széjjelfagy – ez is opció volt egy darabig ;))
