Hallo,

Ich frag mich schon seit längerem wie man am besten Physik an OpenGL anbinden kann.
Also ich will mich am Prozessor um die Physik kümmern und die Grafikkarte soll inzwischen Rendern.
Aber wie mach ich das mit den Position der Vertices? Nach der Manipulation durch die Tanslations bzw. Rotationsmatrizen kann man ja die Informationen nicht mehr ausleden, oder?

Vielen Dank im Voraus!
Andreas

Die nötigen Matrizen sollten von der Physik engine geliefert werden und können dann mit glMultMatrix[f|d]() mit der kamera (world) matrix kombiniert werden.
Es macht sinn sich die debug render beispiele der physikengines (Newton, PhysX...) einmal anzuschauen.

_________________
Lumina plattform unabhängige GLSL IDE

Hm, das ist eine recht kurze Beschreibung. Vielleicht zu kurz? Hier ist eine andere, etwas längere Beschreibung:

Wir nehmen an, dass uns ein hübsches Mesh (eine Ansammlung von Dreiecken) zur Verfügung steht, sagen wir mal: ein Kämpfer-Modell. Wir laden diese Daten mal in den Hauptspeicher. Anhand dieses Mesh kann man jetzt auf automatisierte Weise ein vereinfachtes grobes Mesh herstellen, oder auch nur eine Bounding Box des Mesh berechnen oder vielleicht sind solche Daten sogar in der Meshdatei vorhanden. Die Mesh-Daten, die zum Zeichnen bestimmt sind, schicken wir an die Grafikkarte weiter, damit sie schnell gezeichnet werden können. Diese Daten sehen den Hauptspeicher normalerweise nie wieder. Man könnte die Vertex-Daten schon wieder zurücklesen, aber es ist gar nicht nötig und auch kontraproduktiv, denn es wäre viel zu langsam.

Das vereinfachte Mesh (oder die Bounding Box) behalten wir im Hauptspeicher zurück. Das ist eine „dünne“ Repräsentation unseres Modells. Je „dünner“ (also je weniger Daten es hat), desto besser (nämlich schneller), aber auch nicht zu dünn, sonst werden unsere Berechnungen zu ungenau. Hier muss man sich zwischen Geschwindigkeit und Genauigkeit entscheiden. Das Schnellste, was man hier nehmen kann, ist eine Kugel („Bounding Sphere“), aber unser Kämpfer wird durch eine simple Kugel ziemlich schlecht repräsentiert.

Auf dieses Pseudomesh und einige andere Physik-Daten (Masse, Geschwindigkeit, augenblickliche Position und Orientierung etc.) werden jetzt die Physikberechnungen angewendet (Anwenden von Kräften, Kollisionsberechnungen). Wenn man eine externe Physikengine verwendet, wäre die Struktur der Daten zwar von der Physik-Engine bestimmt, aber in welchem Umfeld sie gespeichert werden, ist unsere Sache. Das Pseudomesh und seine zugehörigen Physik-Daten könnte man z.B. in ein Objekt kapseln, denn sie gehören eindeutig zusammen.

Wichtiger ist aber, dass das Ergebnis der Physik-Berechnungen Verschiebungen und Drehungen sind (Ortsveränderungen und Veränderungen der Orientierung). Diese verändern die aktuelle Position und Orientierung und ergeben eine NEUE Position und Orientierung. Im nächsten Renderpass fliesst diese neue Position/Orientierung aus der Physikberechnung daher in die Renderpipline mit ein, z.B. einfach als glTranslate/glRotate. Ja, es wird normalerweise glMultMatrix benutzt, aber ein einfaches glTranslate/glRotate tut genau dasselbe.

Wenn wir allerdings für unser Kämpfer-Modell wirklich nur eine Bounding Box haben, sehen wir ganz schön alt aus. Besser wäre hier z.B. eine Ansammlung von Bounding Boxen: eine für die Brust, je eine für die Oberarme, Unterarme, usw.

Kollisionskörper werden „Bounding Volumes“ genannt, wenn Du ein Stichwort fürs Suchen im Web haben möchtest. Für ein Mesh, dass sich per Skelett bewegt („skeletale Animation“) gibt es nicht nur ein Bounding Volume, sondern gleich eine ganze Hierarchie davon.

Bei der Demonstration von Physik-Engines sieht man manchmal solche Bounding Volumes, die hier ausnahmsweise auch gezeichnet werden.

Viele Grüße,
Traude

Vielen Dank für eure antworten!
Ganz besonders Traude, du hast mir sehr geholfen!

Wenn es wieder Fragen gibt, melde ich mich

Also Traude... das gefällt mir. Vielleicht sollte man sowas beim Techniken und Algorithmen im Wiki verlinken.
Ich finde das recht gelungen und auch schön abgerundet.
Bitte ins Wiki.

Edit: @Traude: Hier klicken und einfügen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich will jetzt noch zu OpenGL zurück kommen.

Also lade ich das gesammte Mesh in den Speicher der Grafikkarte (über ein VBO). Es soll ein Bone animiertes Mesh sein.
Die Bones beziehen sich ja auf ganz bestimmte, vordefinierte Vertices.
Wie komme ich dann also an genau diese Vertices ran?

Die Physik-Daten bestehen ja dann aus Bones. Diese bestehen wiederum aus einzelnen oder einer Bounding-Boxe(n).

Ich glaub ich hab das mit den Bones unter OpenGl noch nicht ganz verstanden...

Hallo, ihr beiden,
@Flash: ich schreib es ins Wiki, versprochen. Aber nicht mehr Heute.
@Andreas: Du musst Dich auch bis morgen gedulden. Ich sitze mit nassen Haaren vor dem Bildschrim und muss ins Bett - Heute abend steigt ein große Fete und da sollte ich fit sein, und naja, bin halt eben nicht mehr 16. Ich bin schon mehr als dreimal 16 und heute beneide ich Euch brennend dafür, 16 zu sein. Mann, wenn ich jetzt 16 wäre - aber lassen wir das lieber.

Dafür wünsch ich Euch allen heute ein ganz fettes, großes: PROSIT NEUJAHR!
Silvesterliche Grüße,
Traude

Ich glaub ich weiß was du damit meinst
Heute nix mehr PC. Bin schon weg.

Da muss ich jetzt nachfragen, wie Du das gemeint hast. Meinst Du jetzt nur, wie Du sie an Opengl übergeben sollst? Oder zu welchem sonstigen Zweck brauchst Du die Vertices?


Die Bounding Box allein genügt nicht. Wir brauchen pro Bone auch noch unbedingt die Position und Orientierung. Wie genau diese Daten vorliegen hängt von der Physikengine ab. Einigen wir uns mal auf eine Matrix[4x4], denn sie enthält alles was wir brauchen: Position und Orientierung und zusätzlich ist man damit auch für einen Vertex-Shader gerüstet, denn es könnte sein, dass einer nötig wird...

Ich meinte folgendes:

Die Physikengine kommt auf die Idee (wiso auch immern) den Bone XYZ zu drehen.
Jetzt muss aber irgendwer wissen welche Vertices betroffen sind und diese dann an der Grafikkarte ändern.

Da die Vertices an der Grafikkarte abgelegt werden sollen, werden ja VBOs benutzt.
Aber ich habe bisher nur davon gehört das man diese dort ablegen kann, aber nie etwas von manipulation...


>> Einigen wir uns mal auf eine Matrix[4x4]
Find ich gut weil da denk ich, kenn ich einigermaßen gut aus.


>> Vertex-Shader
Ist zwar jetzt off topic aber ich muss das jetzt fragen...
Ich hab noch immer nicht ganz verstanden, was so ein Shader ist.
Folgendes weiß ich (hoffe das stimmt so): er wird auf der Grafikkarte ausgeführt, man kann kurz vorm Rendern noch die Daten manipulieren

Sehr weit vom Thema entfernt: Könnte man mit einem Shader die Grafikkarte zum Rechnen von Daten anderer Natur ausnutzen?

Oder hab ich "Shader" da überhaupt falsch verstanden?

Vertices ändern ist nicht nötig, außer Du möchtest einen Modeller schreiben, denn da wird grundsätzlich das Mesh geändert.

Die Physikengine erzeugt Matrizen (pro Bone eine) und wir übergeben diese Matrizen an OpenGL an der richtigen Stelle. Die Matrizen bewirken die Änderung der Vertices. Wenn ich einen simplen sich drehenden Würfel mit glBegin/glEnd zeichne, muss ich die Vertices ja auch nicht dauernd ändern. Das erledigt glRotate, und das erzeugt einfach eine Rotationsmatrix, die alle Würfel-Vertices transformiert, ohne dass ich einen Finger rühren muss.


Genau. Weil sie im Normalfall gar nicht manipuliert werden müssen, sie müssen bloß mit der Modelviewmatrix multipliziert werden. Siehe oben: Matrizen übergeben genügt.


Super.


Rein grundsätzlich stimmt das. Was meine Shader-Kenntnisse angeht: siehe unten die Antwort auf Deine letzte Frage.


Es ist nicht so, dass ich mich mit Shadern wirklich auskenne. Zu dieser Frage kann ich nur vorsichtig antworten: ich glaube schon. Wie man aber die Ergebnisse wieder dort herauskriegt, weiß ich nicht.

Genau das habe ich gemeint... wie kann ich diese Matrix dann an genau eine Gruppe von Vertices anwenden?

Für den Fall, das die physikengine einen körper mit bones simulirt gibt es verschdene möglichkeiten:

1. Jedem bone wird ein eigenes mesh zugewiesen. Das render kann dann allein über matrizen meshses aus VBOs erfolgen. Dies ist vorallem für Maschinen ein guter weg.

2. Alle Vertices werden von der CPU transformiert und das komplette mesh nur einmal benutzt. Es ist der flexibelste weg vorallem dann wenn man keine shader nutzen kann oder will. Die Doom3 Engine geht diesen weg. Das sieht man z.B. andem MD5 format, welches extrem GPU unfreundlich ausgelegt ist.

3. Ein Vertexshader gewichtet ein oder mehr transformierte vertices. Aus performancegründen ist es schneller die matrizen zu gewichten. Ein nachteil ist die lineare interpolation, welche zum einfallen von stark gekrümten gelenken führt.

4. Ein Vertexshader verarbeitet ein quaternion basierendes Bonesystem. Das konzept basiert darauf, das alle vertices relativ zu den gelnken plaziert werden und zu diesen immer den Gleichen abstand haben.
Dazu muss erst einmal festgestellt werden von welchem Joint (glenk) ein vertex am meisten beeinflusst wird. Dies ergibt sich aus den zwei größten gewichtungen. Dann wird stat der absoluten position die relative berechnet und mit einer dazugehörigen joint nummer abgespeichert.
Der Vertexshader bekommt zwei uniform Arrays: Eines mitr den vortransformierten Joint positionen und eines mit den Quaternionen der Bones. Jeder vertex hat außer der relativen position und der joint nummer noch die gewichtung der bones.
Die berechnung ist dann einfach: die Quaternionen werden gemittelt und zum rotieren der reltiven vertexposition benutzt. nach dem addieren der joint position kann das ergebniss normal weiter transformiert werden.

http://lumina.sourceforge.net/Tutorials/Armature.html

_________________
Lumina plattform unabhängige GLSL IDE

Vielen Dank für die einsicht in die verschiedenen Techniken!

Zu den einzelnen Punkten:

1. Gefält mir nicht so gut, da das System nicht sehr dynamisch ist (jeder Vertax kann nur von einem Bone beeinflusst werden)
2. Würde ich zur Not verwenden, aber hier wird auch massen haft Transfer zwischen CPU und Grafikkarte entstehen
3. Das hört sich jetzt sehr schlimm an. Ist die Teschnik wirklich so "schlecht"?
4. Wenn das ganze mit Matrizen auch funktioniert, dann wäre das der Favorit... ist aber bestimmt nicht leicht umzusetzten.


Achja, bevor ich die das jetzt nocheinmal vergesse:
Man muss die Physikdaten auf der CPU ändern (also Transformieren und Rotieren).
Und das VBO ändert ja OpenGL eig. von alleine.

Soweit ich das beurteilen kann, ist der Unterschied zwischen Punkt 3 und 4 die Interpolierung. In Punkt 3 werden mehrere Ergebnis-Vertices erzeugt und daraus ein Durchschnitt gebildet - das ist eine rein lineare Interpolation. Das wird hier so gemacht, weil sich Matrizen selbst nicht interpolieren lassen.

In Punkt 4 verwendet er m.E. Quaternionen wegen der Interpolation. Quaternionen lassen sich interpolieren, sowohl linear (Stichwort: LERP) als auch sphärisch (Stichwort: SLERP). Mit SLERP lassen sich Gelenke runder machen, mit normaler linearer Interpolation sieht man den Knick deutlicher.
Der Schwierigkeitsgrad dieser Variante ist nicht wirklich so viel höher wie Du glaubst. Wenn Du das mit Matrizen umsetzen kannst, kannst Du es mit Quaternionen auch. Die Formel für SLERP ist im DGLSDK in der geometry.pas bzw. in Sascha Willems' Mathematik-Units und auch mehrfach im Internet zu finden. Bei den relativen Jointpositionen handelt es sich um das Ergebnis einer simplen Vektorsubtraktion: Vertexposition abzüglich Jointposition.

Hier ist ein Link, wo man sich ansehen kann, wie der Unterschied zwischen linearer und sphärischer Interpolation ist: http://www.gamasutra.com/features/gdcarchive/2000/weber.doc