Mama, es geht auch ohne Matrizen

• Ein Experiment, bei dem Euclidean PGA konsequent in einem glTF-kompatiblen Forward Renderer eingesetzt wird – statt der in 3D-Grafik gewohnheitsmäßig verwendeten 4x4-Matrizen
• Rotation und Translation werden als PGA motor aus 8 floats dargestellt; die Komposition allgemeiner Motoren benötigt mit 48 Multiplikationen und 40 Additionen weniger als eine 4x4-Matrixmultiplikation mit 64 Multiplikationen und 48 Additionen
• Punkttransformationen sind bei naiver Entwicklung teurer als Matrizen, lassen sich aber über das sandwich product unter Nutzung der Normalisierungsbedingung auf 21 Multiplikationen und 18 Additionen reduzieren; Transformationen von Richtungen und Basisrichtungen sind noch günstiger
• Beim tangent space normal mapping werden normal und tangent durch einen tangentRotor ersetzt, wodurch die Vertex-Daten von 12 floats auf 9 floats sinken; zugleich bleibt der Aufwand für world-space-Transformationen mit 47 Multiplikationen und 38 Additionen etwa auf Matrixniveau
• Für die Zusammenarbeit mit realen glTF-Inhalten müssen Matrizen beim Laden in Motoren umgewandelt und uniform scale als separates float verfolgt werden; non-uniform scale erfordert eingeschränkte Behandlung oder einen Fallback-Pfad mit 4x4-Matrizen

---

Ein matrixfreier Forward Renderer mit PGA

• Das Projekt heißt Look, Ma, No Matrices und zielt auf die Implementierung eines matrixfreien Forward Renderers ab
• Seit der SIGGRAPH 2019 hat Geometric Algebra, insbesondere Euclidean PGA, in der Grafik- und Machine-Learning-Community Aufmerksamkeit gewonnen; in der traditionellen 3D-Grafik blieb es jedoch oft dabei, dual quaternions einfach als PGA motor neu zu benennen
• Diese Implementierung integriert PGA algebra in eine glTF-kompatible 3D-Engine und gestaltet mehrere Teile der Grafikpipeline im PGA-Stil neu, statt nur algebraische Begriffe umzubenennen
• Als Referenzimplementierung dient der Khronos glTF viewer; es geht eher um ein kompromissloses Experiment zum Ersetzen von Matrizen als um eine auf maximale Performance optimierte Umsetzung
  • Am Ende dürfte wahrscheinlich eine hybrid solution die bessere Wahl sein

Warum 4x4-Matrizen hinterfragt werden

• 4x4-Matrizen spielten lange eine zentrale Rolle in Grafik-APIs und Fixed-Function-Pipelines von GPUs und sind weiterhin das Standardwerkzeug für typisches Forward Rendering
• Moderne GPUs ähneln eher programmierbaren Skalarprozessoren als Fixed-Function-Pipelines, sodass eine matrixzentrierte Darstellung nicht zwingend erforderlich ist
• In realen 3D-Engines enthalten viele Matrizen nur Rotation und Translation und sind damit orthogonale Matrizen
• Die PGA motor manifold stellt die gesamte Euclidean motion mit geringerem Rechen- und Speicheraufwand dar und kann auch quaternions und dual quaternions ohne Umwandlung einschließen

PGA-Datendarstellung und Grundoperationen

• Die PGA algebra wird aus den vier Basisvektoren e0 bis e3 erzeugt
  • e1, e2, e3 entsprechen jeweils den Ebenen x=0, y=0, z=0
  • Der besondere degenerate vector e0 steht für die Ebene im Unendlichen
• In Shadern werden GLSL-Builtin-Typen genutzt, um Addition, Subtraktion und Skalarmultiplikation ohne Operator Overloading zu verwenden
  • motor mat2x4
  • line mat2x3
  • point vec3
  • direction vec3
• Die Komposition allgemeiner PGA motoren erfolgt über das geometric product
  • 4x4-Matrixmultiplikation: 64 Multiplikationen, 48 Additionen
  • Allgemeine Motor-Komposition gp_mm: 48 Multiplikationen, 40 Additionen
• Für spezielle Transformationskombinationen sind günstigere Operationen möglich
  • gp_rr: 16 Multiplikationen, 12 Additionen
  • gp_tt: 0 Multiplikationen, 3 Additionen
  • gp_rt / gp_tr: 12 Multiplikationen, 8 Additionen
  • gp_rm / gp_mr: 32 Multiplikationen, 24 Additionen
  • gp_tm / gp_mt: 12 Multiplikationen, 12 Additionen

Optimierung von Punkt- und Richtungstransformationen

• Um in PGA einen Punkt p mit einem Motor M zu transformieren, nutzt man das sandwich product M p M̃
• Die naive Entwicklung benötigt 33 Multiplikationen und 29 Additionen und ist damit größer als ein Matrix-Vektor-Produkt mit 16 Multiplikationen und 12 Additionen
• Nutzt man aus, dass ein normalisierter Motor M M̃ = 1 erfüllt, lässt sich die Punkttransformation auf 21 Multiplikationen und 18 Additionen reduzieren
• Richtungen, also Punkte im Unendlichen, sind günstiger, weil der implizite e123-Koeffizient 0 ist
  • Allgemeine Richtungstransformation: 18 Multiplikationen, 12 Additionen
  • Die Transformation einer basis direction, etwa der x-Achse, lässt sich auf 6 Multiplikationen und 4 Additionen senken
• Diese basis-direction-Optimierung liefert später beim Umgang mit tangent frames ein Argument gegen die verbreitete Annahme, dass Matrizen immer am schnellsten seien

Normalisierung, Quadratwurzeln sowie Exponential- und Logarithmus-Maps

• Die squared pseudonorm eines PGA motor hat die Form M M̃ = a + b e0123 und ist eine Study Number
• Normalisierung ist keine einfache Vektornormalisierung, sondern ein Verfahren, das sicherstellt, dass der resultierende Motor eine orthonormal transformation ist
  • Implementierungskosten für allgemeine Motor-Normalisierung: 21 Multiplikationen, 5 Additionen
  • Für reine translation oder rotation lassen sich effizientere Varianten verwenden
• Eine rigid transformation zwischen zwei Punkten, zwei Linien oder zwei Ebenen a, b wird als M = sqrt(b / a) dargestellt
  • Das geometric product ba zweier Elemente gleichen Typs erzeugt einen Motor, der der doppelten Transformation von a nach b entspricht
  • sqrt M lässt sich in der Form normalize(1 + M) berechnen
• Der Logarithmus eines PGA motor ist eine scaled line, und eine scaled line kann durch exponentiation einen Rotationsmotor erzeugen
• Die exponential map einer allgemeinen 4x4-Matrix ist numerisch teuer, aber auf der PGA motor manifold ist eine effiziente closed form möglich

Inverse und Motor-Faktorisierung

• Geometric Algebra kann Inverse normalisierter Objekte effizient berechnen
  • plane inverse: das Objekt selbst
  • line inverse: Vorzeichenumkehr
  • point inverse: Vorzeichenumkehr
  • motor inverse: reversion
• Wenn ein allgemeiner bivector die Plücker condition nicht erfüllt und daher keine einzelne line darstellt, wird die Inverse über die Study Number inverse berechnet
• In der Rendering-Implementierung werden zwei Faktorisierungen verwendet
  • Euclidean factorization: zerlegt einen Motor in eine rotation um den origin und anschließende translation
  • Invariant factorization: zerlegt einen Motor in commuting translation und rotation; in 3D ist diese Form als Mozzi-Chasles theorem bekannt
• Beim Komponieren eines tangent frame mit einem object-to-world motor ist die Euclidean factorization nützlich, weil die Eigenschaften des frame invariant gegenüber translation sind

glTF-Matrizen und Umgang mit scale

• Für Interoperabilität mit bestehenden glTF-Inhalten müssen Matrizen beim Laden in PGA motoren umgewandelt werden
• Eine 4x4 orthogonal matrix wird über die Isomorphie mit quaternions in einen Motor konvertiert
  • Alle importierten matrices und transformations werden zur load time umgewandelt
• PGA motoren behandeln rigid body transformations und enthalten daher kein scaling
• Uniform scaling ist invariant gegenüber rotation und translation und wird deshalb pro Node mit einem einzelnen float verfolgt
  • Der total scale jedes Elements wird als Produkt aus eigenem scale und parent scale berechnet
  • Auf vertices wird der total scale zur load time oder im ersten Schritt des vertex shaders angewendet
  • Auf translation wird der parent scale zur load time und bei animation updates angewendet
• In einer Stichprobe von rund 400 zufälligen glTF-Dateien lag der Anteil mit scale animation unter 0,5%; fixed uniform scale kam dagegen recht häufig vor
• Non-uniform scaling ist nicht invariant gegenüber rotation und daher schwieriger
  • Für allgemeines non-uniform scale ist ein Fallback-Pfad mit 4x4 matrix praktisch unvermeidlich
  • In den glTF-Beispielen wurde non-uniform scale nur an leaf nodes gefunden; in diesem Fall wird scale ohne Einfluss auf animation keys separat vor den übrigen Transformationen angewendet

Ersatz für Model-View-Projection

• Der Forward Renderer transformiert mesh geometry aus dem object space in den screen space und bestimmt, welche pixel von jedem triangle abgedeckt werden
• Von den model-, view- und projection matrices der üblichen Pipeline werden model und view durch PGA motoren ersetzt
  • vertex position: sw_mp
  • normal- und tangent-Richtungen: sw_md
• Die projection matrix hat üblicherweise nur fünf non-zero entries; statt sie erzwungen in PGA zu übertragen, wird daher ein direkter projection expression verwendet
• Beim scene graph hierarchy update auf CPU-Seite sinkt der Rechenaufwand, weil motor composition statt matrix composition verwendet wird
• Auf GPU-Seite wirkt die Vertex-Transformation in einem einfachen Vergleich für Motoren ungünstig; ändert man jedoch die Darstellung des tangent frame, ergibt sich ein anderes Bild

Optimierung von tangent space normal mapping

• Der vertex shader eines typischen tangent-space-normal-mapped mesh muss position, normal und tangent transformieren
• Da normal, tangent und bitangent einen orthonormal frame bilden, lassen sie sich in PGA als tangentRotor darstellen, der vom canonical basis frame zum gewünschten tangent frame führt
• Diese Methode verkleinert den vertex descriptor
  • Klassisch: position 3 + normal 3 + tangent 4 + uv 2 = 12 floats
  • PGA-Methode: position 3 + tangentRotor 4 + uv 2 = 9 floats
  • Die Anzahl der floats pro Vertex sinkt um 25%
• tangentRotor hat eine double cover; das Vorzeichen des scalar coefficient wird mit dem klassischen handedness flag abgeglichen, um even/odd k-reflection zu unterscheiden
  • Dies hängt von signed zero ab; im vertex shader wird die handedness mit sign(1/tangentRotor.x) extrahiert
• Werden position, normal und tangent mit einer 4x4 matrix transformiert, sind insgesamt 48 Multiplikationen und 36 Additionen nötig
• Die PGA-Methode transformiert den gesamten tangent frame auf einmal und extrahiert danach normal und tangent
  • tangent-frame-Komposition: 16 Multiplikationen, 12 Additionen
  • Extraktion von normal/tangent: 9 Multiplikationen, 8 Additionen
  • position-Transformation: 21 Multiplikationen, 18 Additionen
  • 1 Multiplikation zur handedness-Extraktion
  • Insgesamt 47 Multiplikationen, 38 Additionen
• Die Kosten der Vertex-Transformation sind fast identisch mit der Matrixmethode, während der Speicher für transformations von 32 floats auf 8 floats sinkt

Fragment Shader und Einschränkungen durch baked textures

• Um bestehende Inhalte zu laden, wird in der fragment-shader-Phase wieder eine TBN matrix benötigt
• Baking tools interpolieren beim Backen eines high-detail mesh auf ein low-detail mesh vertex normal und tangent über die triangle face und erzeugen an jedem fragment eine orthogonale TBN matrix, aus der die tangent space normal texture entsteht
• Die Interpolation von basis vectors erzeugt typische Fehler der Matrixmethode, und dieser Fehler ist bereits in die texture baked
• Deshalb extrahiert diese Implementierung normal und tangent vector explizit aus dem tangentRotor
• Wenn man auch das baking tool kontrollieren kann, lässt sich der tangentRotor direkt an den fragment shader weiterreichen, dort normalisieren und zur Transformation der sampled normal verwenden
  • Es muss keine TBN matrix erzeugt werden
  • Die normal/tangent-Extraktion im vertex shader entfällt
  • Ein varying parameter lässt sich einsparen
  • Auch die teure orthogonalization im fragment shader wird entfernt

Motor Skinning und Animation Blending

• Da PGA motoren isomorph zu dual quaternions sind, lassen sie sich natürlich für skinning einsetzen
• Nach der Umwandlung der inverse bind matrix in einen Motor werden bone motoren nach demselben Muster wie bei dual quaternion skinning geblendet
• Bei geblendeten transformations werden die Vorzeichen so ausgerichtet, dass sie dem shortest arc folgen; anschließend wird die resultierende transformation erneut normalisiert
• Auch animation blending funktioniert auf dieselbe Weise: Auf der CPU werden PGA motoren direkt geblendet und anschließend normalisiert

Ergebnis des Experiments zum Ersetzen von Matrizen

• Es ist möglich, Matrizen in einem glTF-kompatiblen Forward Renderer ausschließlich durch PGA zu ersetzen
• Die Erwartung, dass transformation costs höher ausfallen müssten, ist nach Anwendung der tangent-frame-Darstellung und der sandwich-product-Optimierung nicht so eindeutig
• Im typischen Fall von tangent space normal mapping hält die PGA-motor-Methode die Kosten im vertex shader nahezu auf Matrixniveau und reduziert zugleich den vertex memory footprint deutlich
• Besonders groß ist die Speicherverbesserung: In denselben storage passen rund 33% mehr vertices
• Die Technik kann als drop-in replacement in bestehende 3D-Engines integriert werden, ohne die vertex shader costs nennenswert zu erhöhen oder den Rest der Pipeline zu verändern

[GN⁺]

Hacker-News-Meinungen

• Eine meiner liebsten Mathe-/Grafik-YouTuberinnen, Freya Holmér, hat vor einiger Zeit ein sehr gutes Einführungsvideo zur geometrischen Algebra gemacht: https://www.youtube.com/watch?v=htYh-Tq7ZBI&ab_channel=Freya...
  Wenn man sich für 3D-Grafik interessiert, insbesondere für Splines/Bézier-Kurven, sind all ihre Videos sehenswert.
  Persönlich fand ich lineare Algebra immer schwierig, aber dieser Ansatz über Clifford-Algebra fühlt sich viel intuitiver an.

  • Das war wirklich ein guter Vortrag, und ich musste an https://enkimute.github.io/ganja.js/ denken.
    Diese Library stammt vom Autor des Originalbeitrags, enkimute, und ist ziemlich erstaunlich: ein Single-File-Skript ohne Build, das trotzdem N-dimensionale Algebra und Rendering-Unterstützung bietet.
  • Ich dachte, in diesem Artikel würde es um sie gehen. Die Videos zu Splines und Bézier habe ich ebenfalls mit Vergnügen gesehen, und der Vortrag kommt gut zum Kern, ohne sich je gehetzt anzufühlen.
  • Auch in den YouTube-Kommentaren gibt es überraschend gute ergänzende Erklärungen und Fragen.
    Zum Beispiel sind die Erklärungen zu Stellen, über die Freya etwas schnell hinweggeht oder die sie auslässt, etwa zur Nichtkommutativität des Produkts, ziemlich gut.

• Geometrische Algebra war für mich eine ganze Weile ein völliges Rätsel, bis es schließlich so Klick gemacht hat: Es ist einfach Polynom-Multiplikation, nur dass es Größen gibt, bei denen die Reihenfolge der Multiplikation wichtig ist, und die Multiplikationstabelle seltsam ist. Zum Beispiel i*i = 1, i*j = -j*i
  Die meisten Einführungen lassen das geometrische Produkt zweier Vektoren (x1*i + y1*j) * (x2*i + y2*j) tiefgründig und mysteriös wirken, aber eigentlich ist es dieselbe FOIL-Ausmultiplizierung, die man aus der Algebra im ersten Jahr kennt:
  (x1*i + y1*i)(x2*i+y2*j) = x1*x2*i*i + x1*y2*i*j + y1*x2*j*i + y1*y2*j*j = (x1*x2 + y1*y2) + (x1*y2 - y2*x1)*i*j
  Der Wert in der ersten Klammer ist das vertraute Skalarprodukt, der Wert in der zweiten Klammer entspricht dem vertrauten Kreuzprodukt, wird aber als Basis einer neuen Dimension i*j ausgedrückt. Und anders als das Kreuzprodukt verallgemeinert es sich auf beliebige Dimensionen; in der geometrischen Algebra nennt man es Wedge-Produkt.
  Sobald man das verstanden hat, werden auch Dinge wie die Herleitung von Rotationsformeln einfacher, weil man die aus der Algebra bekannten Techniken direkt auf geometrische Probleme anwenden kann.

  • In dem in einem anderen Kommentar erwähnten Video https://youtu.be/htYh-Tq7ZBI?si=lOmsCL2DoqUCQgh1&t=1540 erklärt Freya hervorragend, wie man die Axiome auf eines reduziert.
    Wenn man das Produkt eines Vektors mit sich selbst als das Quadrat der Länge dieses Vektors definiert, folgt der Rest vollständig aus einfacher Polynom-Multiplikation. Ziemlich schön.
  • Diese Erklärung zeigt einen interessanten Kontrast. Vor ein paar Tagen fragte jemand, warum Mathematikunterricht nicht die Art und den Grund von Operationen lehrt, sondern nur Formeln vorgibt und rechnen lässt; hier liegt der Fokus darauf, was eine Operation tut, statt darauf, warum sie gilt.
    „Wie funktioniert es?“ und „Warum funktioniert es?“ sind zwei Fragen, zwischen denen Mathelehrer eine Balance finden müssen, und es ist schwierig, in einem Kurs immer beide gut zu beantworten.
  • Der zweite Term ist kein Kreuzprodukt, sondern ein äußeres Produkt oder ein Bivektor. Das Kreuzprodukt funktioniert nur in drei Dimensionen, während das äußere Produkt auch in höheren beliebigen Dimensionen möglich ist.
    Das Kreuzprodukt zweier 3D-Vektoren ist ein weiterer Vektor, der senkrecht auf der von den beiden Vektoren aufgespannten Ebene steht. Das äußere Produkt dagegen ist ein 2-Vektor, also ein Bivektor, der das Parallelogramm zwischen den beiden Vektoren überstreicht und in der Ebene liegt, in der die beiden Vektoren liegen. In drei Dimensionen steht der Kreuzprodukt-Vektor senkrecht auf dieser Bivektor-Ebene.
  • Eines der Dinge, für deren Erkenntnis man in der Mathematik am längsten braucht, ist, dass die meisten Dinge auf die einfachste mögliche Weise definiert sind.
    Insbesondere ist die Definition eines bilinearen Produkts m:V x V -> V auf einem Vektorraum V genau dasselbe wie die Festlegung von m nur für Paare von Basisvektoren. Wenn man das „universelle Eigenschaft des Tensorprodukts“ nennt, sagt man vermutlich einfach: „Ach so.“

• Für Rotationsinterpolation gibt es mehrere Ansätze, darunter geometrische Algebra, Quaternionen und sogar die Interpolation ganzer Matrizen; das ist interessant: https://www.gamedev.net/tutorials/programming/math-and-physi...
  Wenn man den Code aber von Hand optimiert hat, sieht der endgültige Code bei den meisten Ansätzen fast gleich aus. Der Unterschied liegt darin, wie man die Regeln und Möglichkeiten versteht.
  Soweit ich es ein wenig beurteilen kann, wirkt geometrische Algebra wie der konsistenteste und leistungsfähigste Ansatz. Sie ist ungewohnt und anfangs ziemlich schwer zu akzeptieren, aber wer diese Hürde genommen hat, mag sie.
  Umgekehrt verwenden alle Quaternionen, klagen aber darüber, sie nicht zu verstehen, und sagen, man brauche ein ganzes Buch, um sie zu visualisieren — etwa Andrew J. Hansons und Steve Cunninghams „Visualizing Quaternions“.

  • Ich bin kein Mathematiker und benutze Geometrie beruflich auch nicht viel, aber ich habe aus Spaß geometrische Algebra gelernt und früher auch versucht, Quaternionen zu lernen.
    Geometrische Algebra macht Spaß, Quaternionen nicht. Bei geometrischer Algebra habe ich das Gefühl, sie verstanden zu haben; bei Quaternionen war ich mir trotz Vorlesungen und Aufgaben nur sicher, dass ich sie nicht verstanden hatte. Jetzt, da ich ein wenig geometrische Algebra kenne, habe ich endlich das Gefühl, auch Quaternionen einigermaßen zu kennen.
  • „Naive Lie Theory“ ist ein hervorragendes Buch und lehrt im ersten Kapitel Quaternionen.
    https://www.goodreads.com/en/book/show/4419538

• Wenn euch dieses Thema interessiert, gibt es gute Folien, die die Konzepte von Grassmann-/Clifford-/geometrischer Algebra überblicksartig behandeln: http://www.terathon.com/gdc12_lengyel.pdf
  Außerdem gibt es noch eine weitere gute Website: https://mattferraro.dev/posts/geometric-algebra

• Nicht fehlen darf auch Sudgys hervorragendes „A swift introduction to projective geometric algebra“: https://www.youtube.com/watch?v=0i3ocLhbxJ4
  Und die zentrale Referenzseite ist https://bivector.net
  Man kann auch dem bivector-Discord mit über 1000 Professoren, Forschern und Enthusiasten beitreten: https://discord.gg/vGY6pPk

  • Eric Lengyel, der Autor dieses Vortrags, hat auch „Foundations of Game Engine Development, Volume 1: Mathematics“ geschrieben; Kapitel 4 behandelt dasselbe Thema

• Ehrlich gesagt mochte ich an geometrischer Algebra nie besonders, dass allerlei gemischte Elemente entstehen, wenn man nicht genau darauf achtet, was man womit multipliziert
  Dass man für etwas, das ein n-dimensionaler Raum war, bis zu 2^n Terme braucht, fühlt sich ebenfalls schwer handhabbar an
  Es scheint, als sollte man Geometrie, also das Skalarprodukt, damit besser behandeln können, aber ich habe keine überzeugende Erklärung gesehen, warum man nicht einfach das äußere Produkt und den Hodge-Stern-Operator oder musikalische Isomorphismen verwenden sollte
  Auch diese „Magie“, einen Bivektor u^v in eine Rotation e^(u^v)t in dieser Ebene zu verwandeln, besteht im Grunde darin, per musikalischem Isomorphismus die 2-Form u^v in einen linearen Automorphismus zu überführen und e^(u^v)t als Matrixexponential zu verstehen
  Ein weiteres häufiges Beispiel ist, dass man die Maxwell-Gleichungen zu einer einzigen Gleichung machen kann; mit Differentialformen lassen sie sich aber bereits zu zwei Gleichungen zusammenfassen, die aus unterschiedlichen Gründen gelten, daher habe ich den Nutzen, sie zu einer einzigen zu verschmelzen, nicht verstanden

  • Dass man „für etwas, das ein n-dimensionaler Raum war, bis zu 2^n Terme braucht“, ist als Ersparnis manchmal eine Illusion
    Zum Beispiel transformieren Normalenvektoren anders als Positionsvektoren. Man kann beide mit derselben Datenstruktur darstellen, muss dann aber nachverfolgen, welche Art von Vektor darin steckt, und überall im Code Sonderfälle einbauen, die sie jeweils unterschiedlich behandeln
    Geometrische Algebra geht das direkt an: Für Vektoren verwendet sie die Basis (i,j,k), für andere Arten eine eigene Basis (j*k, k*i, i*j)
    In dem Sinne, dass eine Gleichung besser ist als zwei oder vier, ist das ein gutes Beispiel dafür, dass ein höherdimensionaler Raum speicherseitig sogar ökonomischer sein kann als ein niedrigerer
    Das elektrische Feld unterscheidet sich vom magnetischen Feld ziemlich ähnlich wie sich ein Vektor von einem Bivektor unterscheidet. Man kann elektrisches und magnetisches Feld mit separaten Gleichungen als Sonderfälle behandeln, oder sie einheitlich auf eine Weise handhaben
  • Gerade die gemischten Elemente sind der wichtige Teil
    Ein Quaternion mit w=1, x,y,z=0 ist die Identität, und Quaternionen wie w=0, x=1 oder w=0, x=y=0.7 entsprechen nur 180-Grad-Rotationen
    Für beliebige Rotationen braucht man eine Kombination aus beidem. Man mischt „ein bisschen 180-Grad-Rotation um diese Linie“ mit „ein bisschen 0-Grad-Rotation/Identität“. Genau das bedeutet es, Skalar und Bivektor gemeinsam zu haben
    Wenn man mit äußerem Produkt und Skalarprodukt „vorsichtig“ versucht, Mischungen zu vermeiden, verwendet man es falsch. Das geometrische Produkt ist der Star und erzeugt sehr nützliche Mischungen
  • Ich stimme zu, dass die Verwirrung bereits existiert. Der traditionelle Ansatz kehrt diese Verwirrung nur unter den Teppich
    Wenn man zum Beispiel Normalen behandelt, muss man mindestens zwei n-dimensionale Räume im Blick behalten, die ziemlich unterschiedlich transformieren
    Punkte, Ebenen, Geraden, Normalen, Translationen und Rotationen alle mit einem einzigen multivector-Typ und konsistenten Regeln darzustellen, fühlt sich ziemlich befreiend an, sobald man es verstanden hat. Ich lerne es allerdings selbst noch

• Die Animationsinterpolation weiter unten ist wirklich cool, aber ich wünschte, die Modelle auf dem Rest der Seite wären etwas weniger lebhaft
  Mathematik ist auch ohne kleine Elefanten-Cheerleader schon schwer genug

  • Im Gegenteil. Ohne diese elefantenartige Aufmunterung hätte ich es nicht bis ans Ende der Seite geschafft

• Falls der Autor mitliest: Ich fände es gut, wenn die Abkürzung PGA bei der ersten Verwendung definiert würde

  • Für alle, die neugierig sind: PGA steht für projective geometric algebra, also projektive geometrische Algebra
    Man fügt den Basisvektoren des Raums, in dem man arbeitet, einen Null-Basisvektor hinzu. Dadurch lassen sich auch geometrische Objekte, die nicht durch den Ursprung gehen, algebraisch darstellen
  • Besonders die Stelle, an der „Fast PGA“ als FPGA geschrieben wurde, fand ich ziemlich verwirrend
  • Korrigiert. mea maxima culpa

• Sind solche Algorithmen auch mit Blick auf die GPU effizient?
  Ich habe den vagen Eindruck, dass GPUs gut auf Matrixoperationen zugeschnitten sind, und frage mich, ob man diesen Vorteil mit einer Formulierung in geometrischer Algebra verliert und am Ende in der Praxis doch nicht schneller ist
  Das ist nur eine uninformierte Vermutung; bitte korrigiert mich, wenn sie falsch ist

  • Es ist ein sehr verbreitetes Missverständnis zu glauben, dass GPU-Hersteller Matrix-Matrix- und Matrix-Vektor-Produkte zwangsläufig beschleunigen, nur weil sie in GPU-Standards vorkommen
    Tatsächlich ist der gesamte Shader-Core bereits SIMD, daher ist das nicht unbedingt möglich. Manche GPUs tun es, manche nicht
  • Beim Programmieren muss man zwei Dinge herausfinden: welche Größe man berechnen will und welche Methode dafür am effizientesten ist
    PGA ist nicht gerade leicht zu verstehen, aber eine sehr gute Methode, um das erste Problem anzugehen. In der Regel ist es ohnehin besser, zuerst die einfachste und am leichtesten zu implementierende Methode auszuprobieren
    Eine Implementierung, die man erhält, indem man mit PGA das erste Problem löst, reicht aus, um den Rest des Programms zu prototypisieren, Benchmarks zu machen und den echten Flaschenhals zu finden. Glücklicherweise ist sie in den meisten Fällen entweder die schnellste Berechnungsmethode oder schnell genug, um kein Bottleneck zu sein
    Und selbst wenn sie zum Bottleneck wird, vermittelt sie ein tiefes Verständnis des Problems, das man lösen will. Ich finde, dieses Verständnis sollte man haben, bevor man anfängt, Zyklen herauszufeilen und darauf zu hoffen, dass es schnell genug wird
  • Genau darum geht es in diesem Artikel. Kurz gesagt: Meist kann es ungefähr auf dasselbe Niveau hinauslaufen

• Das wirkt wie ein Streit um winzige Unterschiede am Ende des Fortschritts
  Dass 3D-Skeletal-Animation auf der GPU immer noch 4x4-Matrizen verwendet, bedeutet, dass die Mathematik, die etwa zur Zeit von Half-Life 1 auf der CPU für diesen Zweck entwickelt wurde, immer noch Stand der Technik ist. Von 1998 bis 2024 sind es 26 Jahre
  Auch in 1000 Jahren wird 3D-Animation noch genauso sein

• Dieser Artikel liegt außerhalb meines Verständnishorizonts, aber der Titel erinnerte mich an ein Experiment, bei dem ich einen einfachen 3D-Renderer gebaut habe
  Nachdem ich mehrfach daran gescheitert war, lineare Algebra zu lernen, kam mir unter der Dusche der Gedanke, dass 3D-Rotation einfach aus drei 2D-Rotationen besteht – und die kannte ich bereits. Etwa eine Stunde später hatte ich einen Wireframe-3D-Renderer samt Perspektive gebaut
  Ich kann nur empfehlen, es einmal auszuprobieren