www.rolandk.de
- Aktuelle Themen zu .Net -
Achtung: Hier handelt es sich um meine alte Seite.
Die aktuelle ist unter folgendem Link erreichbar: www.rolandk.de/wp/
Home Blog Rendern von 3D-Text (Part 1)




















































Rendern von 3D-Text (Part 1)
Samstag, den 02. Februar 2013 um 08:54 Uhr

Vor einigen Tagen habe ich eine Baustelle begonnen, von der ich nicht erwartet hätte, dass sie so kompliziert werden würde. Kurz gesagt geht es um folgendes: Ich möchte einen String bzw. einen Text direkt als 3D-Objekt zeichnen (nicht einfach nur als flache Textur). Mein erster Ansatz bei Mosaic Snake 3D ist eigentlich relativ einfach. Das Objekt im 3D-Modeller erzeugen, normal aus einer Datei laden und dann anzeigen.

Nachfolgender Screenshot zeigt das Ergebnis.

 

 

In AC3D etwa ist das auch gar nicht mal so schwer. Man kann einfach wie im folgenden Screenshot per Tool ein 3D-Text erzeugen und fertig.

 

 

Nachteil an der ganzen Sache: Immer, wenn man so etwas braucht, muss man den Umweg über einen 3D-Modeller machen. Was mir weiterhin nicht gefällt ist, dass der Text damit relativ statisch ist, oder anders gesagt, um Dynamik rein zu bekommen, müsste man sehr viele 3D-Modelle im 3D-Modeller erzeugen. Vorgestellt hätte ich mir eigentlich mehr, dass ich in der eigenen 3D-Engine irgendwo eine Methode hätte:

  1. new Text3D(„Test-Text“)

Dazu dann noch Angabe der Schriftart, Schriftgröße usw.. Sollte ja eigentlich nicht so schwer sein, da ja so gut wie jedes Gui-Framework das auch in 2D macht – dachte ich jedenfalls.

 

Der Weg zur theoretischen Lösung

Einen interessanten Beitrag zu dem Thema gibt es direkt beim Msdn-Magazin (http://msdn.microsoft.com/de-de/magazine/cc163349.aspx). Am ersten Blick sah der super aus, am zweiten entpuppt sich aber: Hier werden nur die Ränder des Textes gezeichnet, nicht aber die Fläche selbst. Für die Fläche selbst entsteht hier nur der Eindruck, da der Text in die Tiefe erweitert wird und man damit eigentlich nur die Seitenränder sieht. Also kurz: Nicht sehr befriedigend für meinen Zweck.

 

Interessant an der Möglichkeit hier ist aber, wie man in WPF genaue Pixel bzw. Geometrie-Informationen aus einem beliebigen Text und einer beliebigen Schriftart bekommt.

 

Wo ich jetzt genau hin möchte, zeigt eigentlich schon ein Screenshot in diesem Artikel, und zwar folgender:

 

 

Ich würde gerne das Ergebnis rechts erhalten. Was mir WPF gibt, ist aber nur das Modell Links, also alle Außen- und Innenlinien der Buchstaben.

 

Nach weiterer Suche habe ich nicht wirklich etwas Verwendbares gefunden, was genau in meine Richtung geht. Meine Recherche hat mich aber jetzt wo anders hin geführt, und zwar zum Thema Triangulation. Dabei geht es darum, aus einem beliebigen Polygon ein Modell aus Dreiecken zu erhalten. Also genau der Weg oben vom linken A (nur Außen- und Innenlinien) zum rechten A (alle Dreiecke, welche die Fläche bestimmen). Sehr gut dazu ist etwa folgende Pdf , welche man auf http://www.geometrictools.com findet: http://www.geometrictools.com/Documentation/TriangulationByEarClipping.pdf. Darin wird das „Ear Clipping“ beschrieben, ein scheinbar verbreiteter Algorithmus zur Triangulation.

 

Nach Lesen dieses Artikels wollte ich das unbedingt mal ausprobieren. Glücklicherweise finden sich im Internet zahlreiche Implementierungen zu dem genannten Ear Clipping Algorithmus, so etwa auch im Helix Toolkit. Mithilfe der damit gefundenen Werkzeuge habe ich also meinen ersten Versuch gestartet und folgendes erhalten.

 

 

Die weißen Würfel hier sind die Eckpunkte, welche ich mit der Methode aus dem weiter oben erwähnten Msdn-Artikel bekommen habe. Die Füllflächen entstanden im Nachhinein durch den Ear Clipping Algorithmus. Tja, sieht gut aus, aber noch lange nicht perfekt. Mein Problem aktuell sind noch die „Löcher“. So etwa werden im „B“ die Hohlräume auch mit ausgefüllt. Ist ja eigentlich auch klar, denn die Triangulation generiert ja Dreiecke für die gesamt umspannte Fläche und weiß nicht, dass da in der Mitte ein Leerraum ist.

 

Nach etwas rumspielen habe ich dann auch herausgefunden, wie man aus den Geometrien von WPF erkennt, wo eigentlich diese Leerräume sind. Folgender Screenshot zeigt jede einzelne Geometrie, die ich von WPF bekomme, einzeln und jeweils etwas angehoben.

 

 

Hier sieht man, die Leerräume sind eigene Geometrien. Aber wie hält man jetzt Leerräume und Füll-Räume auseinander? Interessanterweiße (und darauf muss man erst einmal kommen), sind die Randpunkte der Leerräume genau anders herum angeordnet. Folgender Screenshot zeigt auch wieder alle Eckpunkte der Geometrien, allerdings ist dabei der jeweils erste am kleinsten und der jeweils letzte am größten dargestellt. Damit sieht man, in welcher Reihenfolge sie angeordnet sind.

 

 

Schon irgendwie interessant, oder? Die nächste Aufgabe ist also nun, die Leerräume während der Triangulation heraus zu schneiden. Interessanterweise ist genau dazu in oben genannter Pdf auch ein Algorithmus enthalten, und zwar im Kapitel 5 „Polygons with Multiple Holes“. Genau das wird dann eine meiner nächsten Aufgaben sein.

 

Schlussfolgerung

Tja, liest sich hier nicht nur kompliziert, sondern ist es auch. Aber genau das hat mich auch dazu gebracht, mehr Zeit mit diesem Problem zu verbringen. Irgendwie ist es aber auch oft so, dass denkbar leichte Sachen schnell sehr kompliziert werden können. Dieses Problem bringt aber sehr viel Einblick darin, wie solche Geometrien eigentlich im Hintergrund aufgebaut sind. Ich bin schon gespannt, auf welche Gemeinheiten ich da noch stoßen werde.

 

Kommentar hinzufügen

Ihr Name:
Kommentar: