THREE.js SphereBufferGeometry - Warum so viele Ecken?

Question

Ich schaue, wie THREE eine SphereGeometry erstellt und ich sehe, dass es die Funktion SphereBufferGeometry() verwendet.

Ich versuche zu verstehen, warum es die Anzahl der Scheitelpunkte erstellt, die es tut. Wenn ich zum Beispiel die Kugel mit 4 Breitensegmenten und 4 Höhensegmenten festlegen möchte, definiert DREI 25 Eckpunkte.

Eine Skizze zeigt an, dass die "Sphäre" 4 + 8 + 8 + 4 = 24 separate Dreiecke haben sollte und wenn jedes Dreieck 3 ungeteilte Ecken hat, erhalten wir insgesamt 72 "virtuelle" Ecken. Aber wenn wir jede Ecke zwischen mehreren Dreiecken teilen, dann wird es 1 + 4 + 4 + 4 + 1 = 14 "echte" Ecken geben.

Im Code gibt es diese Zeile: -

var vertexCount = ((widthSegments + 1) * (heightSegments + 1)); 

dies So würde erklären, wo die Anzahl der Ecken (4 + 1) * (4 + 1) = 25 herkommt. Und diese Zahl (VertexCount) bestimmt auch die Anzahl der erstellten Positionen, Normalen und UVs. Aber warum werden so viele (25) Ecken benötigt? Da THREE die Indexierung verwendet, um Scheitelpunkte über mehrere Dreiecke zu teilen, warum kreieren Sie nicht einfach 14 "echte" Scheitelpunkte?

---

bearbeiten

Praktisch die (wS + 1) * (hs + 1) vertexCount Formel verursacht mir ein Problem, wenn eine Kugel durch die Anwendung zufällig Skalare zu jedem Eckpunkt zu verformen versuchen. Wenn es nur 14 "echte" Vertices gäbe, gäbe es kein Problem. Aber bei 25 Vertices muss ich wissen, welche virtuellen Scheitelpunkte sich auf den gleichen reellen Scheitelpunkt beziehen, so dass alle virtuellen Scheitelpunkte demselben Skalarwert zugewiesen werden können. Ansonsten erscheinen räumliche Lücken zwischen benachbarten Dreiecken.

---

aktualisieren

Siehe WestLangley Antwort.

Beachten Sie auch, dass der Index der (4x4-großen) SphereBufferGeometry 72 Elemente enthält, die den 72 "virtuellen" Scheitelpunkten entsprechen. Jedes Element zeigt auf die entsprechende 1 (von 25) In-Puffer-Vertices. Wenn gewünscht, kann der Index somit (im Code) verwendet werden, um aus der SphereBufferGeometry zu lesen und alle 72 "virtuellen" Scheitelpunkte (tatsächlich alle 72 * 3 = 216 Scheitelpunktkoordinaten) in einen neuen anfänglich leeren "flachen" benutzerdefinierten Puffer zu schreiben .

Answer 1

SphereBufferGeometry ist BufferGeometry das ist "indiziert" - Vertices können zwischen den Flächen geteilt werden.

Der Grund, warum die zusätzlichen Scheitelpunkte benötigt werden, liegt an den Nähten.

Es gibt eine Naht an der Seite der Kugel, und an den Nord- und Südpolen ist eine Naht.

Doppelte Scheitelpunkte werden entlang jeder Naht benötigt, da die UVs entlang der Nähte variieren.

Jeder Scheitelpunkt kann eine beliebige Anzahl von Attributen haben. Wenn jedoch zwei Scheitelpunkte an derselben Stelle mindestens ein Attribut aufweisen, das sich unterscheidet, müssen die Scheitelpunkte dupliziert werden.

three.js r.75