spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Das Buch sagt aus dass jede Matrix, die hier hineingesteckt wird invertiert und transponiert wird. Der Code zeigt, dass dies tatsächlich implementiert wurde.

Die Dokumentation dieser Funktion im Buch sagt
"Transformiert einen Richtungsvektor".

Seit wann werden Richtungsvektoren mit der Transpose-Inverse transformiert? Das gilt AUSSCHLIESSLICH für Normalen.
Standard richtungsvektoren werden genauso transformiert wie Coordinaten auch, nur dass ihr w-Wert eben 0 beträgt, folglich die länge des Vektors irrelevant ist.

Hier wird bei jeder Transformation eines Richtungsvektors eine massive Rechenoperation aufgerufen, die nicht nur unnötig sondern auch schlicht falsch ist.

Die fällt zu 99% wahrscheinlich nicht auf, da die meisten Transformationsmatrizen für orthogonale Operationen stehen, bei denen die Transpose Inverse mit der ursprünglichen Matrix schlicht identisch ist, da dort gilt Inverse = Transpose.

In 99% aller Fälle wird hier also die Engine extrem runtergebremst nur um aus einer Matrix nochmal die selbe Matrix zu berechnen...

Und für nicht orthogonale Operationen ist diese Rechnung nicht nur langsam sondern fatal falsch.

Da die Funktion in etwa an die entsprechende DIrect3D Funktion angelehnt ist, denke ich sollte sie auch entsprechend funktionieren.

Jene Funktion transformiert Richtungsvektoren (tut das gleiche wie transformCoords() nur dass sie den w Wert ignoriert, da der eh 0 ist).
In der Doku zur FUnktion steht drin, dass man die Matrix schon als Transpose Inverse übergeben muss, sollte man Normalen transformieren wollen.

Das ist nicht nur schön weil man die Transpose Inverse meist nicht braucht und ausserdem klar ist, dass man bei Normalen nen zusätzlichen Schritt machen muss (der dank entsprechender Funktionen kein großer AUfwand ist), sondern er erleichtert ausserdem einiges wenn man sich etwas auskennt mit Matrizen.
Denn wenn man weiß dass eine Rotation orthogonal ist, kann man diese Anweisung schlicht ignorieren und die normale Matrix übergeben, das man WEISS dass die Matrizen eh identisch wären.
So kann man viele Schritte optimieren, wenn man sich etwas auskennt.

Die momentane TriBase Funktion macht dies (selbst wenn sie ansonsten korrekt wäre, sprich nur für normalen gedacht wäre) unmöglich, da hier dieser Schritt immer von der FUnktion selbst übernommen wird. Das ist unkomfortabel da nur der Programmierer weiß wann man evtl so einen Schritt weglassen kann und wann nicht. Die Funktion macht es einfach immer und berechnet so sehr oft unnötig eine aufwendige Matrixoperation.