[alg] 3D scene manager

[Verwijderd]

Sinds enkele dagen ben ik van plan m'n scene manager uit te breiden. Het is de bedoeling dat hij standaard alle objecten in een octree plaatst en dat objecten aan elkaar gekoppeld kunnen worden dmv relatieve coordinaten (1 matrix per object dus).
Ik heb hier onderaan m'n werkwijze genoteerd, maar wil graag weten of dit de juiste is. (en of ik het dus goed begrepen heb).

Stel je hebt de wereld coordinaten. In die wereld staat:
- een terrein
- een auto (die kan bewegen)
- een wapen (op de auto gemonteerd)

Voor zover ik het weet wordt elk bewegend object als een root node in de octree geplaatst. Dus het terrein en de auto zijn een rout node, die recursief kan worden afgelopen met behulp van frustum culling. Op de auto is dan een wapen gemonteerd en dit heeft dan relatieve coordinaten tov de auto. Dit sla je dan op in een matrix.

Idem met bone animaties, elk object (arm, been, romp, hoofd) is gekoppeld aan een ander object. Bvb: de armen, benen en hoofd zijn gekoppeld aan de romp. Je gaat dan bvb de romp renderen en recursief alle bones afgaan met de nodige matrix-transformaties (naargelang bvb de arm beweegt verandert de matrix van deze bone).
Dit in totaal geeft dan een "speler" object en is dan ook weer een root node van de octree. Animeer ik de speler, dan animeer ik enkel de bones en manipuleer ik de object space matrix.


Maar hoe moet ik dit opslaan?

Ik veronderstel dat een mesh:
- 1 of meerdere polygonen kan bevatten
- een id nummer heeft voor de octree
- (optioneel) een id nummer heeft voor een bone

Ik verondertel dat een scene object:
- 1 of meerdere meshes kan bevatten
- 0, 1 of meerder bones kan bevatten
- een plaats heeft in de octree (in een node op hoger niveau dan de meshes die het bezit).

Maar hoe zit het dan met een mesh dat net op de scheidingslijn zit van twee octree nodes? Stel dat je door je octre wandelt en je zou eigenlijk beide nodes tegenkomen:
Ga je dan gewoon een boolean opslaan die onthoudt of de mesh reeds gerenderd is of ga je dit gewoon negeren en render je desnoods het object 2x?

En als de speler - die een root node is in de octree - zich verplaatst, dan moet je toch opnieuw die root node en zijn child nodes updaten?

Plus: hoe combineer ik dit met bsp? Ik zou een bsp map ook als object beschouwen en dit aan een root node toewijzen? Het probleem is dan echter: als die bsp map in je frustum zit, maar de speler zit niet in de map zelf, dan moet je in principe heel de map renderen... of maak ik dan een low poly versie van deze bsp map?

Nog suggesties? Zit ik fout? Kan het ergens beter?

[ Voor 4% gewijzigd door Verwijderd op 12-12-2004 16:02 ]

[Zoijar]

Je haalt een beetje dingen door elkaar volgens mij. Je mengt nu een transformatie boom, met een space division quadtree, en daarna wil je nog een bsp tree. Je moet die dingen appart opzetten, begin bij eentje.

Je transformatie opzet is goed; elk object heeft een eigen matrix, en eventueel een parent object, die dan dus ook een matrix heeft. (Ik zou trouwens eerder een positie vector, en een quaternion gebruiken, maar beiden kan.)

Je hebt nu dus een boom van objecten, om te transformeren. Nou kan je alles in een octree opslaan om te cullen. Je transformeert je octree blokken naar camera space, en kijkt of ze visible zijn, etc. Op een gegeven moment kom je objecten tegen, en die ga je renderen. Dan ga je je transformaties doen naar wordl space, en dan naar camera space etc. Voor die transformaties gebruik je je transformatie boom. Op grenzen lijkt me in beiden blokken opslaan en een was_rendered boolean flag een aardige oplossing.

Je BSP tree objecten wil je vaak helemaal appart renderen. Als het maar een wereld is, dan kan je misschien ook je octree hierin verwerken.

[Verwijderd]

Zoijar schreef op zondag 12 december 2004 @ 16:50:
...
Op een gegeven moment kom je objecten tegen, en die ga je renderen. Dan ga je je transformaties doen naar wordl space, en dan naar camera space etc.
Voor die transformaties gebruik je je transformatie boom.
...

Hoe bedoel je, de transformatieboom? Bedoel je de boom die begint aan de root node die in je frustum zit(waar dus dat object in zit)?

Je BSP tree objecten wil je vaak helemaal appart renderen. Als het maar een wereld is, dan kan je misschien ook je octree hierin verwerken.

Dat snap ik niet goed...
Je bedoelt dat ik de BSP niet in de octree moet plaatsen en apart moet renderen? Ik bekijk de BSP map als een stukje van de wereld, bvb een huisje in die wereld met een aantal kamers.
De wereld (met alle bsp objecten, bomen, landschappen, etc) is dan de octree zeg maar, dus het bsp object zit toch in een root node (of overlapt meerdere root nodes)van de bsp tree?

[.oisyn]

Zoijar schreef op zondag 12 december 2004 @ 16:50:
Je transformeert je octree blokken naar camera space, en kijkt of ze visible zijn

Dat lijkt me een beetje de omgekeerde wereld. Als de berekening er makkelijker op werd zou je er wel wat voor kunnen zeggen, maar dat wordt het niet en dus zit je sowieso aan planetests e.d. vast. Beter genereer je dus gewoon een view-frustum in worldspace zodat je de octree nodes niet eerst hoeft te transformeren (1 transformatie voor het viewfrustum van camera naar world space vs. n transformaties van octree nodes van world naar camera space)

Overigens ga ik mee met je stelling dat een scene graph en spatial subdivision 2 hele verschillende dingen zijn die in principe niets met elkaar te maken hebben

[ Voor 9% gewijzigd door .oisyn op 13-12-2004 10:11 ]

[Verwijderd]

.oisyn schreef op maandag 13 december 2004 @ 10:10:
[...]
...
Overigens ga ik mee met je stelling dat een scene graph en spatial subdivision 2 hele verschillende dingen zijn die in principe niets met elkaar te maken hebben

Natuurlijk, maar dat beweerde ik toch ook niet?
Ze hebben beide niks met elkaar te maken, maar ze zijn wel voortgekomen uit het resultaat van gezamenlijke gegevens (vertices).
Het hoort niet echt rechtstreeks bij de scene manager, maar als die scene graph wordt aangepast, dan heeft dat invloed op de spatial subdivision. Vandaar dat ik het even hier ook erbij zette.