[Alg] 3D scene object manager

[Verwijderd]

Ik vroeg me af of deze techniek zou kunnen verbeterd:

Stel dat je een SceneManager klasse hebt die alle 3D objecten in een omgeving verhandelt. Er is een algemente SceneObject klasse, waaruit 2 klassen worden afgeleid:
- FixedSceneObject
- AlterableSceneObject

Elk SceneObject heeft een mesh, en elke mesh heeft minstens 1 groep vertices. Elke groep vertices heeft een translatie en rotatie matrix en elke groep kan gekoppeld zijn aan een andere vertexgroep opdat ze elkander kunnen beinvloeden.

Elk SceneObject heeft deze eigenschappen:
- vertices met texture met coordinaten
- een plaats (standaard 0X,0Y,0Z)
- een rotatie (standaard 0°X,0°Y,0°Z)
- een naam/ID (voor debugging)
- een bounding box (die optioneel kan worden berekend)
- een bounding sphere (die optioneel kan worden berekend)
- rendertype (lijnen, punten, polygonen)
FixedSceneObjecten zijn in principe gewone SceneObjecten, maar AlterableSceneObjecten kan ook matrixberekeningen doen opdat de vertices kunnen worden aangepast.

Elke vertex groep heeft deze eigenschappen:
- polygonen
- een bounding box (die optioneel kan worden berekend)
- een bounding sphere (die optioneel kan worden berekend)

De SceneManager zelf heeft ook nog opties zoals:
- Alles renderen met een bepaald rendertype, ongeacht het gedefinieerde type van het object zelf
- Alle bounding boxes/spheres renderen, ongeacht wat er is gedefinieerd in het object.

De hele scene manager zou moeten voorzien zijn op physics, omdat ik dat later misschien wil toepassen (*heeft op de trein nog es zitten kwijlen naar de HalfLife2 E3 movie*). Het geheel zal worden geimplementeerd in een 3D engine die bedoeld is voor een first person shooter.

[edit] Aanpassing wegens info van .oisyn

[ Voor 17% gewijzigd door Verwijderd op 18-12-2003 21:04 ]

[.oisyn]

je moet je mesh data loskoppelen van je objecten. Een object is namelijk gewoon een instantie van een mesh met een bepaalde transformatie-matrix

tevens zou je eraan kunnen denken om een scenegraph systeem op te bouwen waarbij je een boomstructuur creëert waarbij elk kind de transformaties van z'n ouders meekrijgt. Daar hang je dan ergens een camera in, en dan kun je de relatieve transformaties tov die camera bepalen om de objecten te tekenen

(en dan omlaag in de boom betekent vermenigvuldigen met de transformatiematrix van die node, en omhoog in de boom betekent vermenigvuldigen met de inverse matrix van die node)

[Verwijderd]

.oisyn schreef op 18 december 2003 @ 15:27:
je moet je mesh data loskoppelen van je objecten. Een object is namelijk gewoon een instantie van een mesh met een bepaalde transformatie-matrix

Als ik het goed begrepen heb hou ik dus best de vertex van het data originele object bij en een gecompilede variant met de transformatie-matrix erop toegepast? Zoiets was ik van plan met de AlterableSceneObjects. Bij de FixedSceneObjects is dit niet echt nodig denk ik?

tevens zou je eraan kunnen denken om een scenegraph systeem op te bouwen waarbij je een boomstructuur creëert waarbij elk kind de transformaties van z'n ouders meekrijgt. Daar hang je dan ergens een camera in, en dan kun je de relatieve transformaties tov die camera bepalen om de objecten te tekenen

(en dan omlaag in de boom betekent vermenigvuldigen met de transformatiematrix van die node, en omhoog in de boom betekent vermenigvuldigen met de inverse matrix van die node)

Ik ben niet zeker dat ik begrijp wat je bedoeld:
Dus je hebt een lijst van meshes die aan elkaar zijn gekoppeld, met elk (optioneel) een transformatie. Bij het aanpassen van de ene mesh wordt een child mesh beinvloed. Of bedoel je wat anders? Net zoals bone animities, toch?

Zal ik dan aan elk SceneObject een pointer naar een eventueel "child" en "parent" scene object koppelen?

[ Voor 7% gewijzigd door Verwijderd op 18-12-2003 17:19 ]

[.oisyn]

Verwijderd schreef op 18 december 2003 @ 17:17:
[...]


Als ik het goed begrepen heb hou ik dus best de vertex van het data originele object bij en een gecompilede variant met de transformatie-matrix erop toegepast? Zoiets was ik van plan met de AlterableSceneObjects. Bij de FixedSceneObjects is dit niet echt nodig denk ik?

nee, een object heeft geen vertices. Een object is verbonden aan een mesh. De vertices aan die mesh zijn statisch en moet je vanaf blijven (tenzij je ze per-object op een bepaalde manier wilt aanpassen oid, maar dat is wat anders dan simpelweg een transformatiematrix eroverheen gooien).
Als je een object tekent teken je dus z'n mesh, met de transformatiematrix

Zoiets dus:

code:

void tekenObject (Object o)
{
    glLoadMatrix (o.matrix);
    glDrawMesh (o.mesh);
}

Dezelfde mesh kun je dus op verschillende plaatsen tekenen zonder ook maar iets aan z'n vertices te doen (dat is het hele idee van transformatiematrices in een 3D api juist)

Ik ben niet zeker dat ik begrijp wat je bedoeld:
Dus je hebt een lijst van meshes

nee objecten

die aan elkaar zijn gekoppeld, met elk (optioneel) een transformatie. Bij het aanpassen van de ene mesh wordt een child mesh beinvloed. Of bedoel je wat anders? Net zoals bone animities, toch?

meshes pas je niet aan, maar puur de transformatiematrices van de objecten. Zoals het idd ook met bones gaat, maar het is nogal ondoenlijk om elke bone apart in je scenegraph op te nemen. De scenegraph werkt dus op object-niveau, en lijkt op de bonestructuur die op model-niveau zit.

Stel, je hebt een planeet, en daaromheen draait een maan. De planeet en de maan zijn beide een apart object. De maan is een child van de planeet, en de transformaties zijn dan ook relatief tov de planeet. Je kunt nu de planeet verplaatsen, maar de maan zal er altijd omheen blijven draaien, omdat het relatief is.

Maar dingen als camera's en microfoons passen hier ook in. De camera representeert de kijkpositie en orientatie in de wereld, en de microfoon is je oren zeg maar. Vaak wil je deze 2 dingen op dezelfde plek hebben, maar dat hoeft niet per se.

Als je nu de camera een child maakt van de maan, dan beweegt de camera dus automatisch met de maan mee, zonder dat je daar iets voor hoeft te doen

Zal ik dan aan elk SceneObject een pointer naar een eventueel "child" en "parent" scene object koppelen?

ja en een next (en misschien prev), want een node kan meerdere childs hebben, dus kun je met die next een gelinkte lijst maken

[Verwijderd]

Ah er gaat een lichtje branden.

Eigenlijk was de bedoeling dat ik bepaalde matrix-veranderingen direct op de mesh (vertices) zou toepassen, omdat ik dan echt objecten kan gaan vervormen (bvb een vouwmeter die wordt opengevouwen) opdat er onmiddellijk een correcte collisiedetectie op kan worden toegepast.

Maar nu ga ik het dus anders doen

Om even kort samen te vatten:
Een SceneObject omvat een mesh. Een mesh bestaat uit 1 of meerdere groepen van vertices. Een mesh kan gekoppeld zijn aan 1 of meerdere meshes, opdat ze elkander kunnen beïnvloeden. Elke mesh heeft een rotatie en translatie matrix. Physics worden toegepast op een mesh of de bounding box/sphere van die mesh en beïnvloed eventueel gekoppelde meshes.

Ik had blijkbaar een verkeerd beeld van het woord 'mesh' Ik post m'n ondervindingen hier nog wel en misschien ook wat source of uml schema's.

[.oisyn]

Een mesh is het raamwerk, oftewel gewoon de faces, edges en vertices

Als je collision detection wilt doen direct op de mesh die bovendien ook nog eens elk frame kan veranderen, veel plezier, maar klinkt makkelijker dan dat het is Voor een FPS ook nog niet eens nodig, bounding volumes voldoen in zo'n geval echt prima

Over het algemeen zijn meshes statisch, die moet je niet dynamisch willen veranderen. Dan kun je ook gewoon dingen als bounding volume trees van tevoren maken, zodat je je collision detection & response systeem veel efficienter kunt maken

[Verwijderd]

Dat klopt, maar in sommige gevallen zijn bounding boxes/spheres niet goed genoeg. Een mogelijke oplossing is dan om een low poly model te maken van die mesh.

Een ander probleem dat ik nu zie is:
stel dat ik - zoals in HalfLife2 - een matras echt als een matras wil laten reageren (bvb: als een van de hoeken ergens op ligt, dat het dan lichtjes buigt), moet ik dan alles niet anders indelen? Of deel ik gewoon alles in zoals het nu is maar ga ik bvb de bounding box op de nodige plaats vervormen?

[.oisyn]

Zo'n matras is een ragdoll, en het collision model werkt niet op de mesh (dat gebeurt vrijwel nooit, omdat het gewoon veel te traag is). Een soort van bones systeem, maar dan met strings vermoed ik. Zoek maar eens op strings en cloth

collision detection & response is een ramp als je mesh kan veranderen. Daar worden meestal gewoon versimpelde modellen voor gebruikt, zoals bijvoorbeeld losse collision meshes, of dingen als strings en particles

[Verwijderd]

.oisyn schreef op 19 december 2003 @ 14:27:
Zo'n matras is een ragdoll, en het collision model werkt niet op de mesh (dat gebeurt vrijwel nooit, omdat het gewoon veel te traag is). Een soort van bones systeem, maar dan met strings vermoed ik. Zoek maar eens op strings en cloth

collision detection & response is een ramp als je mesh kan veranderen. Daar worden meestal gewoon versimpelde modellen voor gebruikt, zoals bijvoorbeeld losse collision meshes, of dingen als strings en particles

"Strings en cloth" ... we hebben het over programmeren toch? niet over tanga's en kledij (a) ...just kidding

'k Ga het zeker eens opzoeken. Ragdoll's ken ik wel van naam, kga wat onderzoek uitrichten, maar weet nog niet zeker of ik het ga toepassen dan, want dat lijkt me zware stuff.