Java Polygon-Meshes und der Umlaufsinn

Vulpecula

Commander
Registriert
Nov. 2007
Beiträge
2.241
Hallo!

Ich habe mal eine Frage bezüglich des Umlaufsinns von Polygonen (bzw. deren Vertices).

Wenn ich in Java ein TriangleMesh erzeugen will, dann muss bzw. sollte ich mich auf eine Umlaufrichtung festlegen. Wenn ich nichts weiter angebe, dann wird ja als Standard das Rechtssystem (CCW / gegen den Uhrzeigersinn) benutzt. Den Umlaufsinn der Vertices herauszufinden ist dank Spatprodukt nicht besonders kompliziert.

Ich rechne also das Spatprodukt aus und wenn dessen Vorzeichen negativ ist, dann weiß ich, dass die Vertices in die falsche Richtung drehen und ich z.B. die ersten beiden tauschen muss, damit ich ein Rechtssystem erhalte.

Allerdings: Muss ich zwingend ein positives Vorzeichen erhalten, um sicherzustellen, dass es sich um ein Rechtssystem handelt? Es kann ja auch sein, dass das Spatprodukt Null ergibt, da die gebildeten Vektoren alle auf einer Ebene liegen. Ich frage mich auch, ob dann quasi undefiniert ist, was Außen- und was Innenseite ist und ob es dann probleme mit dem Rendern gibt.

Vielleicht kann mich mal jemand Aufklären. ;)

MfG - Vulpecula
 
Zuletzt bearbeitet:
Das Ergebnis des Kreuzproduktes ist schon richtig so. Und wenn die Vektoren auf einer Ebene liegen kommt nicht 0 raus. 2 Vektoren liegen immer auf einer gemeinsamen Ebene. Ist das Kreuzprodukt 0 sind sie höchstens parallel. Da du das Kreuzprodukt aber auf die Verbindungsvektoren der Vertices untereinander anwendest würde das bei einem Triangle bedeuten, dass sie ineinander liegen.
Beim Skalarprodukt (Teil des Spatprodukts) bestimmst du den Winkel zwischen den Vektoren, Kreuzprodukt ist hier besser geeignet und reicht alleine schon um nur die Drehrichtung zu bekommen.
 
Zuletzt bearbeitet:
Wie würde das dann konkret aussehen? Das Kreuzprodukt zu berechnen ist kein Problem; das mache ich für das Spatprodukt ja sowieso schon. Nur liefert mir das Kreuzprodukt nicht einen Vektor, der orthogonal auf der aufgespannten Ebene zweier Vektoren liegt? Würde ich dann nach dem Resultierenden Vorzeichen entscheiden?

Falls sich jemand wundert: Ich habe eine liste mit Polygonen/Dreiecken (bzw. deren Vertices) und möchte den Kram so in mein TriangleMesh aufnehmen, dass beim Rendern nichts "verschwindet". Das Problem habe nämlich ich momentan noch; bei einigen Faces stimmt die Umlaufrichtung nicht und dementsprechend wird das jeweilige Face dann "unsichtbar".
 
Zuletzt bearbeitet:
Ich merk schon ich bin auch ein wenig eingerostet. Solche Sachen habe ich zuletzt im View-Space berechnet, da ist das etwas vereinfacht. Aber so viel kann ich sagen: Du kannst im View-Space anhand der z-Koordinate entscheiden, ob das Polygon der Kamera zu- oder abgewandt ist. Bei OpenGL ist -Z die Forward-Axis, d.h. wäre Z positiv, zeigt die Normale des Polygons entsprechend zur Kamera und ist sichtbar. Wäre das Polygon entsprechend falschrum, wäre das Vorzeichen invertiert. Die Reihenfolge mit der du die Vektoren als Operanden im Kreuzprodukt verwendest entscheidet letztendlich dann darüber, ob du auf CW oder CCW überprüfen willst (bzw alternativ ob du negatives oder positives Vorzeichen als korrekt ansiehst).
Da ich aber selbst gerade merke über das Szenario hinaus etwas eingerostet zu sein, wäre evtl eine dritte Meinung hilfreich.

Aber um die eigentliche Frage zu beantworten, ich vermute mal, dass ein solches Polygon weder als Frontfacing noch als Backfacing angesehen wird und in diesem Fall als Strich gerendert wird. Wird es als Backfacing angesehen und Backface Culling ist aktiviert, wird es einfach verworfen und nicht dargestellt. Sollte in der Praxis aber nicht vorkommen, da so ein Polygon einfach keinen Sinn macht in einem 3D Modell.
 
Du kannst den Umlaufsinn nur für eine bestimmte Kameraposition bestimmen. Wenn du willst, dass alle Dreiecke sichtbar sind, dann kannst du das nur für konvexe Körper berechnen, dann muss die Kamera aber innerhalb des Körpers sein und du musst die Vertizes entsprechend transformieren (also um die invertierte Kameraposition verschieben).

Für konkave Körper funktioniert das im Allgemeinen nicht.

In 2D oder allgemein für feste Kamerawinkel mit orthografischer Projektion geht das natürlich für alle Körper und Flächen.

Den Umlaufsinn solltest du in deinem Programm aber gar nicht prüfen müssen, normalerweise sollte dies das Programm, mit dem der Mesh erstellt wird, automatisch richtig erstellen. Ggf. musst du deinen Renderer entsprechend konfigurieren (ein boolean namens z.B. FrontCounterClockwise bei Direct3D), das müsste eine Einstellung der Rasterizer Stage sein, bei Direct3D lässt sich das einfach einstellen, was du in Java dafür tun musst, weiß ich nicht.
 
Zuletzt bearbeitet:

Ähnliche Themen

Antworten
9
Aufrufe
2.388
R
Zurück
Oben