Visual-Basic-Forum VB-Paradise.de

Name der DLL:
GDI3D oder auch Graphics3D

Beschreibung:
Da ich mich in der letzten Zeit wieder mal mit DirectX beschäftigt habe, mir aber das seitenlange coden, Errorhandling, OnLostDevicehandling, usw, usw, langsam auf den Senkel ging, habe ich mich nach einer Alternative umgeschaut, konnte aber kaum etwas brauchbares finden. Durch diesen Thread kam mir die Idee von GDI3D.

GDI3D ist eine Klassenbibliothek, mit der man schnell und einfach 3D zeichnen kann - mit GDI.
Dazu können alle möglichen sogenannte Meshes (also Drahtgittermodelle) aus Dateien geladen werden.
Das (zur Zeit einzige) unterstützte Dateiformat ist das *Obj-Format von Wavefront. Nahezu jede Modeller-Software (auch Blender!) kann dieses Format exportieren.

Was mich selbst überrascht hat, ist die relativ hohe Performance von GDI. Erst ab etwa 5000 Polygonen pro Frame, kommt es bei mir zum leichten Ruckeln.

Open Source!

Anwendung:
GDI3D lässt sich leicht integrieren.
Wichtig sind jedoch folgende Schritte:
• Instanziierung der Graphics3D-Klasse und Übergabe der Zeichengröße
• Festlegen der World-, View-, und Projection-Matrizen (wer schon einmal mit DX gearbeitet hat, sollte das kennen)

Und schon kann es losgehen. Hier ein Beispiel-Code zum zeichnen eines Meshes, das aus einer Datei geladen wurde, in die gesamte Form "Form1":



Screenshot und Video:

Und hier noch ein tolles Video.


Verwendete Programmiersprache:
VB.Net

Systemanforderungen:
• .NET Framework 2.0
• Es ist keine DirectX-Runtime nötig.

Lizenz:
LGPL ;-)

Download:
GDI3D Release (10 KB)
GDI3D Source-Code-Projekt (30 KB)

Beispiel OBJ-Mesh (45 KB)



Viel Spaß!

Wow!! Vielen Dank für die guten Kritiken.
Hätte niemals gedacht, dass das so vielen hier gefällt.


Ich werde auf jeden Fall daran weiter arbeiten. Falls es dann bald stabil ist gibt's auch den Sourcecode.
Eine Doku dazu wird auch kommen.

Zuerst aber:
- Vielleicht ist das jemanden schon aufgefallen, dass es kein "Tiefensortierung" (also kein Z-Buffer) gibt. Das heißt, die Polygone werden nacheinander, so wie sie im Mesh angeordnet sind, gezeichnet.
Daher kann es dazu kommen, dass ein Polygon, das eigentlich verdeckt sein müsste, über ein vorderes Polygon gezeichnet wird. Das sieht sehr unrealistisch aus (zB hier).

Daher werde ich ein Z-Buffer einbauen.

- Ein weiteres Manko ist, dass zur Zeit nur mit einer Farbe gezeichnet werden kann. Langweilig...
Damit sich das ändert kommt gegebenenfalls programmierbare Pixel- und Vertex-Shader hinzu, um für jeden Pixel einen Farbwert zu errechnen.
Somit sind Schatten, Texturen und alle möglichen Materialien möglich.
Ich hoffe mal, dass ich das hinkriege und die GDI-Performance dabei nicht den Bach herunterläuft.

- Das Laden von Obj-Files ist ein wenig fehlerhaft. Cinema4D beispielsweise exportiert irgendwie anders. Mal schauen.

Ich freue mich über jeden Vorschlag.




So zur Technik:
Wie ich oben schon beschrieben habe, läuft alles wie auf Grafikkartenebene bei DX ab.
Ein Mesh besteht aus einer Liste von Vertices, also Raumpunkten. Jeweils 3 Vertices spannen ein Polygon bzw. Dreieck im Raum auf.

Für jeden Vertex eines Dreiecks passiert nun folgendes:
• Der Vertex ist ein 4-D-Vektor. Die ersten 3 Koordinaten sind die Raumpunkte. Die 4 Koordinate, also "w" ist immer 1.
Der Vektor wird mit der World-, dann der View- und dann der Projektions -Matrix multipliziert. Alle diese Matrizen sind ebenso 4-dimensionale Matrizen. In ihnen stecken die Informationen über Verschiebung, Rotation, Projektionsmethode usw.
• Der resultierende Vektor besitzt wieder 4 Koordinaten. Zur Vervollständigung unser Berechnung müssen nun xdie ersten 3 Koordinaten durch die 4. Koordinate geteilt werden.
Der ersten beiden Koordinaten sind jetzt die fertig projezierten 2-D-Koordinaten des Vertex. Die 3. gibt Asukunft darüber, wie weit der Vertex weg ist.

Hier noch ein genauerer Artikel.

Zitat

ich schätze mal, dass das ganze auf Eulerscher Rotation basiert.

Die Drehung im Raum beruht auf dieser Methode, ja.

Zitat

und diese dann mit Regions/Paths zeichnet?

Zur Zeit wird alles mit mit FillPolygon und DrawPolygon gezeichnet.




Und hier noch ein Obj-Modell. Vor allem hier ist zu sehen, dass ein z-Buffer nötig ist.