Auflösung unabhängiger kubischer Bezier auf GPU-Zeichnung (Blinn/Loop)

Question

auf den folgenden Ressourcen auf der Grundlage, ich habe versucht, unabhängig von der Auflösung kubische Bezier auf der GPU zu bekommen Rendering zu arbeiten:

GPU Gems 3 Chapter 25

Curvy Blues

Resolution Independent Curve Rendering using Programmable Graphics Hardware

Aber wie auf der Curvy Blues Website angegeben, gibt es Fehler in den Dokumenten auf den anderen beiden Websites. Curvy Blues sagt mir, dass ich mir die Kommentare ansehen soll, aber ich kann diese Kommentare nicht finden. Ein anderes Forum irgendwo sagt mir dasselbe, ich erinnere mich nicht, was dieses Forum war. Aber da ist definitiv etwas, was mir fehlt.

Wie auch immer, ich habe versucht zu regenerieren, was passiert, und ich verstehe nicht den Teil, wo die Diskriminante aus den Determinanten einer Kombination von transformierten Koordinaten berechnet wird.

Also habe ich die ursprünglichen Koordinaten, ich stecke sie in eine 4x4-Matrix, transformiere diese Matrix mit der M3-Matrix und bekomme die C-Matrix. Dann erstelle ich 3x3 Matrizen aus den Koordinaten in der C-Matrix und berechne die Determinanten, die dann kombiniert werden können, um die a, b und c der quadratischen Gleichung zu erzeugen, die mir helfen werden, die Wurzeln zu finden.

Problem ist, wenn ich es genau so mache: die Diskriminante ist falsch. Ich habe klar Koordinaten für eine Serpentine (eine symmetrische, aber eine richtige Serpentine), aber es gibt an, dass es eine Spitze ist. Wenn ich es selbst mit wxMaxima errechne, auf die 1. und 2. Ordnung ableitend und dann das Produkt, das sich auf eine quadratische Gleichung vereinfacht, berechnet, scheint die Diskriminante dieser Gleichung korrekt zu sein, wenn ich die gleichen Koordinaten einstelle. Wenn ich den Code zwinge, meine eigene Diskriminante zu verwenden, um zu bestimmen, ob es eine Serpentine ist oder nicht, aber ich die Determinanten verwende, um die weiteren k, l, m Texturkoordinaten zu berechnen, ist das Ergebnis auch falsch. Also vermute ich, dass es einen Fehler in den Determinanten geben muss.

Kann mir jemand helfen, das richtig zu machen?

Answer 1

Ich denke, ich habe es geschafft, es zu lösen. Die Ergebnisse sind nahezu perfekt (manchmal invertiert, aber das ist wahrscheinlich ein anderes Problem).

Dies ist, wo ich falsch gelaufen bin, und ich hoffe, ich kann anderen Menschen helfen, die ganze Zeit nicht zu verschwenden, die ich verschwendet habe, dies zu suchen.

Ich habe meinen Code auf dem Blinn-Phong-Dokument basiert. Ich hatte Koordinaten b0, b1, b2, b3. Ich habe sie als 2D-Koordinaten mit einem w angesehen, aber ich habe diese Ansicht geändert, und das hat das Problem gelöst. Indem man sie als 3D-Koordinaten mit z = 0 betrachtet und sie zu homogenen 4D-Koordinaten für die Transformation macht (w = 1), ist die Lösung angekommen.

Durch die Berechnung der C-Matrix: C = M3 * B, habe ich diese neuen Koordinaten. Bei der Berechnung der Determinanten d0, d1, d2, d3 verwendete ich die x, y Koordinaten aus den Spalten 0 und 1 in der C Matrix und den w Faktor aus Spalte 2. FALSCH! Wenn man darüber nachdenkt, sind die Koordinaten tatsächlich 3D-Koordinaten, also sollte man für die w-Faktoren Spalte 3 nehmen und Spalte 2 ignorieren.

Dies gab mir korrekte Determinanten, was zu einer Diskriminante führte, die sortieren konnte Aus welcher Art von Kurve ich handelte.

Aber Vorsicht, was meine Suche noch länger machte, war die Tatsache, dass ich annahm, dass, wenn es sichtbar eine Serpentine ist, das Ergebnis der Diskriminante immer> 0 (Serpentin) sein sollte. Aber das ist nicht immer der Fall, wenn Sie einen mathematisch perfekten Septentin haben (Koordinaten sind so, dass der Mittelwert genau in der Mitte liegt), wird die Determinante sagen, es ist ein Höcker (Determinante = 0). Ich dachte immer, dass dieses Ergebnis falsch ist, aber das ist es nicht. Also lass dich nicht täuschen.

Answer 2

Das Buch GPU Gem 3 hat hier einen Fehler, und the page on nVidia's website den Fehler hat zu:

a3 = b2 * (b1 x b1) 

Es ist eigentlich a3 = b2 * (b1 x b0).

Es gibt andere Probleme mit diesem Algorithmus: Der exp-Teil des Fließkommas wird während der Berechnung überlaufen, also sollten Sie vorsichtig sein und Operationen in Ihren Code normalisieren.