Isometrisch Zeichnen

[milos]

Hallo,

ich arbeite seit einiger Zeit an einer Spiele Engine für Android und iOS die mein Spiel in Isometrischer Ansicht rendern soll.
Das ganze geschieht mit der Firemonkey Canvas. Das Berechnen der Punkte funktioniert schon und ich habe auch eine funktion implementiert die mir Wavefront (.obj - 3D Modelle) einliest und darstellen kann. (Bilder im Anhang - Wichtig: Das Flugzeug und der Dinosaurier sind nur zur Demonstration da. Im Spiel werden nicht annähernd so komplexe Objekte benötigt, es geht eher um das Auto ^^)

Ich komme momentan leider nicht weiter bei der "Reihenfolge" in der gezeichnet werden soll damit auch nur die Polygone sichtbar sind, die es sein sollen. Am besten wäre es natürlich wenn ich auch nur diese Zeichnen müsste. Kann mir da einer ein Tipp geben? Wie ich den Punkt von der 3D Welt auf die 2D Oberfläche umrechne, ist auch als Bild angefügt.

Schon mal danke für eure Zeit

[Jens01]

Kannst Du das nicht bei FMX nicht in eine 3D-Engine einbinden?
Wenn Du eine Tiefensortierung machen willst, wird das sehr aufwendig.

[Desmulator]

Angenommen dein zu zeichnendes Dreieck sei durch die Vertizes u, v und w geben.
Dann musst du als erstes die Flächennormale berechnen. Dies geschieht mittels des Kreuzprodukts und zwar so:

Code:

n = ( v - u ) x ( v - w )

Wichtig, der Vektor n ist nicht normal! Falls er später gebraucht wird um zum Beispiel Licht zu berechnen, musst du ihn noch normalisieren. Allerdings ist im Allgemeinen die Normale für Licht Teil der Vertex-Definition und wird über das Dreieck interpoliert, die hier berechnete Normale dient nur zum Backface-Culling.

Code:

n' = 1/|n| * n

Angenommen der Betrachter befindet sich am Punkt p. Man betrachte nun das Skalarprodukt:

Code:

q = ( p - v ) * n

Falls q größer als 0 ist, so zeigt das Dreieck zum Betrachter hin, muss also gezeichnet werden. Falls kleiner als 0 ist die Rückseite sichtbar. Das ganze bezeichnet man als Backface-Culling. So kann man falsche Dreiecke aussortieren.

Wichtig: Das ganze funktioniert nur bis auf Vorzeichen, wenn du also irgendwo ein Vorzeichen umgedreht hast, musst du es auch hier tun. Also am besten einfach ausprobieren. Wichtig ist auch die Reihenfolge in der die Vertizes aufgelistet sind. Diese entscheidet nämlich ob wie ein Dreieck orientiert ist.

Um nun Objekte in der richtigen Reihenfolge zu zeichnen hast du zwei Möglichkeiten:
Dreiecke nach ihrer Tiefe, vom Betrachter aus gesehen, sortieren. Das ist allerdings sehr und teilweise gar nicht möglich ohne die Dreiecke in kleinere unterteilen zu müssen.

Die "moderne" Methode ist ein Z-Buffer. Dieser merkt sich die Tiefe eines jeden Pixels. Wenn du die Dreiecke also später rasterisierst musst du für jeden Pixel den Tiefenwert berechnen und ihn mit dem im Z-Buffer vergleichen. Ist dieser vergleich positiv, so kann der Farbpuffer aktualisiert werden.


Die Tiefe berechnet sich ganz einfach während der Projizierens auf den Bildschirm. Nach der Homogenen Division steht in der Z-Koordinate der Tiefenwert.

Das ist aber das kleinste Problem. Es wird noch eine ganze Menge Mathematik auf dich zu kommen. Besonders wenn du Texturen verwenden möchtest. Gerade der Rasterisieren von Dreiecken ist ein Flaschenhals auf einer CPU. Es wird jeder Pixel einzeln berechnet! Das keine Grafikkarte mit 100 Shadereinheiten einfach deutlich besser.
Außerdem ist es sehr schwer effektiv einen Z-Buffer zu realisieren. Der Overhead ist einfach gigantisch.

Es lohnt sich wirklich sich damit auseinander zu setzen und die Vorgänge einer Grafikkarte nach zu programmieren. Ich habe es auch getan. Sogar in Assembler mit SSE Optimierung. Das geht auch ganz gut, ist aber absolut nicht zu empfehlen, da das ganze ziemlich schnell in die Knie geht. Und das auf einem Desktop-CPU.


Darum lieber die 3D-Schnittstelle des Handys nutzen.

[Medium]

Zitat von Desmulator:

Es lohnt sich wirklich sich damit auseinander zu setzen und die Vorgänge einer Grafikkarte nach zu programmieren.

Das ist im Grunde auch das, was ich dazu sagen würde. Wenn es sich nicht um ein rein akademisches Projekt zum Lernen handelt, ist es heutzutage Selbstmord sich um derart "low level" Dinge selbst zu kümmern. Man nutzt einfach die bestehenden, und mittlerweile immens vereinheitlichten 3D-Standards und überlässt denen die ganze ekelige Fummelarbeit.
Selbst dabei gibt es noch mehr als genug Feinheiten und Möglichkeiten Dinge individuell zu realisieren, dass man sich um Mangel an Arbeit oder Fragen keine Sorgen machen muss.

Und WENN man denn schon akademisch an die Sache heran geht, so würde ich es als für deutlich interessanter und umfassender empfinden, statt einer Realtime-Software-3D-Engine lieber einen Raytracer zu programmieren. Das meiste an zu Grunde liegender Mathematik ist praktisch identisch, und man kann zunächst erstmal viel mehr "geradeaus" an die Sache heran gehen, da man im Realtime-Bereich oftmals zu Tricks und zunächst nicht offensichtlichen Optimierungen greift, um die man sich für den "physikalisch korrekteren" (sehr große Anführungszeichen hier) Fall des Raytracings erstmal nicht sorgen muss. (Ein Z-Buffer und Backface- sowie Frustum-Culling sind dabei allerdings auch relevant. Die 3 Dinge sind sozusagen DIE 3 wesentlichen Optimierungen, weshalb 3D am Computer überhaupt erst effizient möglich wurde.)

Aber wenn es darum geht ein Produkt herzustellen, mit dem Fokus auf Story, Gameplay oder was auch immer, so ist es eigentlich nicht sinnvoll viel tiefer anzusetzen als auf einer fertigen 3D-API (welche noch allgemein genug sind um richtig oft richtig böse auf die Nase fallen zu können), oder gleich eine fertige Engine. Und FMX ist quasi, mit ganz viel Wohlwollen und Weggucken durchaus als kleine Engine zu bezeichnen.