rendern bei bone-animation



  • Ich hab mir ein Datenformat gebastelt, welches zum einen ein 3D-Model mit bones beinhaltet. Die bones selber besitzen einen Namen vom Typ char[16].
    Zur Animation existiert ein zweites Datenformat, welches die absolute Position der Bones pro frame beinhaltet, wobei besagte Ausgangsposition im frame 0 enthalten ist. Hierbei existiert eine m zu n - beziehung, was bedeutet, dass jedes vertex mehrere bones haben kann, wodurch diese dann je nach anbindungsstärke gezerrt werden.

    der Hintergrund ist hier die Kombination mehrerer Animationen, um beispielsweise Gesichts- und Laufbewegung gleichzeitig ablaufen zu lassen.

    Ich habe also einen Renderer, der eine Liste von Animationen übergeben bekommt und noch einen Zeitindex, anhand dessen errechnet wird, welches Frame der Animationen jeweils gerendert werden muss.

    Nur fragt sich jetzt, was effizienter ist: für jeden Vertex schauen, an welchen bones er hängt, in jeder animation schauen, ob dieser bone verschoben wird, hieraus den Mittelwert berechnen und entsprechend der Anbindungsstärke den Vertex verschieben?
    erscheint mir leicht komplex das..


  • Mod

    normalerweise blendet man sich die bones aus 2 oder 3 animationsphasen zusammen.
    danach geht man pro vertex 3 oder 4 bones durch und transformiert das vertex damit (gewichtet).
    bones berechnet man auf cpu seite, setzt sie als constanten in den VS, vertices transformiert und accumuliert man dann im vertexshader.



  • ein Datenformat, welches die absolute Position der Bones pro frame beinhaltet

    Bones sind Gelenke und die koennen sich lediglich drehen.
    Man bewegt ein Bone an eine andere Position indem man dessen Parent-Bones entsprechend rotiert.
    Evtl das Konzept nochmal ueberdenken...

    Normalerweise bildet man Polygonhaufen deren Vertices alle die gleichen Bones (kleine Anzahl, manche mit Gewichtung=0) teilen um die noetigen Matrizen in Vertex-Shader-Konstanten halten zu koennen.
    Bei mittlerer Polygonzahl und Multipass-Rendering (zb ein Renderpass pro Lichtquelle) macht es oft Sinn, die Transformation CPU-seitig zu erledigen.
    Je nachdem aus welcher Software Deine Daten kommen, solltest Du sehr kleine Gewichte verwerfen (und die restlichen neu normieren) um die Bone-Pro-Vertex-Anzahl niedrig zu halten.



  • da bin ich permanent dabei ;-p
    Edit:
    und NATÜRLICH sind auch Rotationsdaten dabei..
    Eigentlich wollte ich aber auch eine Verschiebung drin haben..

    Hmm.. vielleicht sollte ich die Grundposition und Abhängigkeit der Bones voneinander speichern und anschließend nur noch Rotationswinkel.
    Ich müsste dann ja eigentlich nichts weiter machen, als die Rotationswinkel sämtlicher Animationen aufeinander-addieren.

    Anschließend müsste ich dann ausrechnen, wie die neue Position der Bones ist und dann die Vertize entsprechend ihrer Anbindung an die bones verschieben und rotieren..? 😕


  • Mod

    DocJunioR schrieb:

    sollte ich die Grundposition und Abhängigkeit der Bones voneinander speichern und anschließend nur noch Rotationswinkel.
    Ich müsste dann ja eigentlich nichts weiter machen, als die Rotationswinkel sämtlicher Animationen aufeinander-addieren.

    ich glaube helli meinte genau das mit 'Man bewegt ein Bone an eine andere Position indem man dessen Parent-Bones entsprechend rotiert.'

    es gibt einige tutorials/sources dazu fuer das milkshape format, dazu samples scenes etc. ist zwar nicht das praechtigste editier tool, aber zum animationscoden vielleicht gerade recht.



  • dann frag ich mal das große Gorakel..


Anmelden zum Antworten