ZFX + Developia

Ich glaube, ich muss das einfach Mal versuchen umzusetzen und etwas damit rumspielen, bevor ich hier mit guten Argumenten weiterreden kann. Das Unreal-Bild würde schon reichen, ist aber wiederum weit mehr als eine Kapsel. Und wenn die Animation tatsächlich durch mehrere Joints nicht so viele Kollisionserkennungs-Fehler hervorruft, wie ich denke, ist es natürlich auch eine gute Lösung.

So, ich habe jetzt Mal die oberste Sphere-Ebene gebastelt. Es gibt also für jede Bone eine Sphere, die dann mit der Matrix bei Animation bewegt wird. Und ich muss sagen, das sieht schon Mal sehr gut aus, wird also vermutlich reichen. Auch beim testwuson, das alle vier BoneIndices nutzt, sieht die Ausgangsform gut aus.

Ich werde das dann jetzt für tiefer gelegene Spheres grafisch umsetzen und dann für die eigentliche Animation und nicht nur für die BoundingSphere-Anzeige.

Wenn das geschafft ist, brauche ich nur noch ein wenig Performance-Optimierung machen, die Engine etwas aufräumen und dann kann ich eigentlich schon mit einem einfachen Testlevel anfangen. :) Dann geht der Spaß also endlich los nach 2-3 Jahren ! (ich habe halt nur äußerst extensiv bisher dran gearbeitet an der Engine, ich weiß, dass 14.000 LOC für 2-3 Jahre nichts ist).

Falleri und fallera, jeder kleine Erfolg macht mich echt fröhlich.

Hier ein Video: http://www.youtube.com/watch?v=AGBHjVvktVc

Eisflamme hat geschrieben:Hier ein Video: http://www.youtube.com/watch?v=AGBHjVvktVc

Freut mich, dass es läuft.

BTW: Der Zwerg kommt mir sowas von verdächtig bekannt vor. ;-) Hihi!

EDIT: Hier ist meine (Re-)Inkarnation des guten Zwergs (leider ohne sichtbares Boundingvolume):

Jep, der gute Zwerg. ;) Assimp rulez!

Eisflamme hat geschrieben:Also zur Zeit erstelle ich einen Bounding-Sphere-Tree entsprechend dem obigen Paper für alle Vertices. D.h. ich bilde erst eine Bounding-Sphere, die alle Vertices abdeckt. Dann mache ich je nachdem, wie ich die Vertices mit bester Gleichverteilung hinbekomme, entlang einer der drei Achsenflächen (xy, yz, xz). Die darunter liegenden Vertices umfasse ich mit wiederum einer Sphäre.

Da ich leider obiges Paper nicht öffnen kann (offensichtlich Anmeldung erforderlich), habe ich noch eine kurze Frage dazu: Ich gehe davon aus, dass die gewählte Schnittebene neue Vertices erzeugt, die für die nächste Stufe an BoundingSpheres mit einbezogen werden? Denn sonst endet ja jeder Vertex einzeln mit einer 0-Sphere... Oder wird das anders getrickst?


Und noch was zu deinem Problem:

Eisflamme hat geschrieben:Na ja, schon klar, dass ich bei Animationen einfach Bones update und die Spheres irgendwie an Bones hefte. Aber ich habe ja nur ein Mapping von Spheres zu Vertices. Die Überlappungen von Bones zu Spheres können ja in allen möglichen Formen vorliegen. Wie löse ich das? Wenn eine Sphere von Vertices so beeinflusst wird, dass vier Bone beeinflussend wirken, ist es nicht so einfach, die Sphere an die Bones anzupassen, da die Vertexpositionen ja auch von der Ausgangsposition abhängt...
Kurz: Ich weiß nicht, wo ich da das Aktualisieren aller einzelnen Vertices "rauskürzen" kann in meiner Aktualisierung, wenn ich mich nur auf die Bones fokussiere.

Für die Positionen der Spheres müsstest du es so lösen, dass du Gewichte für mehrere Bones benutzt, genauso wie du einen einzelnen Vertex transformierst. Beim Erstellen kannst du ja für jeden enthaltenen Vertex aufsummieren, welcher Bone mit wieviel % einwirkt und so einen Gewichtungs-Durchschnitt für den Kugelmittelpunkt berechnen. Was allerdings die evtl. erforderliche dynamische Größe angeht versagt gerade meine Vorstellungskraft ob man das ähnlich lösen könnte...

Ein weiterer Ansatz wäre evtl., die Matrizen bzw. Quaternions n-mal zufällig zu belegen (im Bereich der erlaubten Bewegung) und die verschiedenen BoundingSpheres zu mitteln oder gar irgendwie zu klassifizieren... (mein Urin sagt mir, Spherical Harmonics als interpolierter Richtungs-Lookup könnten ein potentieller Klassifizierungskandidat sein, auch wenn ich noch nicht weiß wie) - hört sich außerdem nach längerer Vorberechnung an und ist vom Prinzip her vielleicht vergleichbar mit vorberechneter globale Beleuchtung u.ä.

Ansonsten denke auch ich, der bisher genannte Ansatz sollte in den üblichen Fällen reichen.
Außerdem ist es durchaus legitim (egal auf welchem Gebiet), nur eine grobe automatische Lösung anzubieten und dem Designer (bzw. dir selbst - sei nicht zu verwöhnt ;-)) einen Weg offenzulassen, etwas manuell zu ändern: Quick Prototyping mit möglichem manuellem Finetuning ist durchaus akzeptabel.