Aufgabenstellung   |   Pseudocode   |   DXF Leser   |   Kamera   |   Vektorgeometrie / Misc   |   Probleme

Probleme beim Softwareprojekt

Die Probleme fingen schon beim Einlesen der DXF-Datei an. Die Dokumentation von AutoCAD zu diesem Dateiformat (http://www.autodesk.com/techpubs/autocad/acad2000/dxf/index.htm) wurde mittlerweile von der Version v.u16.1.01 abgelöst. Die Version, auf die sich unser Programm ursprünglich bezog, war die Version v.u15.0.02. Da für unser Programm das Auslesen der 3DFaces und die Feststellung, ob es sich um ein Dreieck oder Viereck handelt, essentiell ist, ergaben sich hier Probleme. Unser Programm funktionierte auf einmal nicht mehr mit einer selbst erstellten DXF Datei, da die Abfrage, ob es sich um ein Dreieck oder Viereck handelt, von AutoCAD umgestellt wurde (die Punkte des 3DFace für diesen Vergleich wurden geändert, weswegen unsere Funktion daraufhin keine sinnvollen Werte mehr lieferte). Weiterhin sind im Vergleich zu OpenGL die y und z Achse vertauscht, was zu Darstellungsfehler führte.

Ferner gibt es unter C/C++ Probleme, falls man die Gleichheit zweier double bzw. float Zahlen feststellen will. Hier muss mit einer Epsilon-Umgebung gearbeitet werden, da die Überprüfung auf 0 oft Fehler liefert.

Ein weiteres Problem ergab sich auch aus der ursprünglichen Aufgabenstellung. Es sollte eigentlich ein BSP-Tree erstellt werden, der dann zur Portalberechnung der 3D-Welt benutzt werden sollte [1]. Das Problem hierbei ergab sich aus der Komplexität der Aufgabe (einzige von uns gefundene Beschreibung des Portalalgorithmus im Quellcode von Quake 3 bzw. Pseudocode in Seth Tellers Dissertation über dieses Thema) und aus den DXF-Daten, die uns Vorlagen. Eine Portalberechnung macht nur Sinn, wenn man sich in geschlossenen Räumen (in der 3D-Welt) befindet - eigentlich eine treffende Annahme bei der Visualisierung eines Gebäudes. Allerdings enthielt unsere DXF-Datei nur den groben Grundriss mit einzelnen Pfosten, weswegen dieser Algorithmus keinen Sinn gemacht hätte.

Somit wurde nur der BSP-Algorithmus genau implementiert, und ein einfaches Clipping mit Hilfe der von OpenGL gelieferten MODELVIEW und PROJECTION Matrix realisiert. Die Technik, die hier zum Einsatz kam, nennt sich Frustum Culling [2]. Leider sind die meisten Implementationen fehlerhaft, da sie nicht berücksichtigen, wenn alle Punkte eines Dreieck ausserhalb des Frustums liegen, das Dreieck immer noch sichtbar sein kann. Ein Ansatz mit Hilfe einer Bounding-Box lieferte hier leider auch nicht die entsprechenden Ergebnisse.

Eine eigene Kameraklasse dient zur Übersichtlichkeit, wird aber eigentlich nicht benötigt.

Durch die (für uns im Endeffekt) zu offene Problemstellung, gab es einige weitere Probleme beim Clipping. Hier gibt es einige interessante Ansätze, die in der Literatur allerdings nur sehr vereinzelt angesprochen werden, aber sehr effizient sind (Plücker-Koordinaten [3], Fast BackfaceCulling mit Hilfe von vorberechneten Vektoren [4]). Es wurde zwar versucht, diese Clipping-Algorithmen zu implementieren, allerdings scheiterte dieser Versuch wegen mangelnder Quellen und schwer zugänglichem Material(Die meisten Quellen sind Eigentum amerikanischer Universitäten, die sich ihre Arbeit bezahlen lassen wollen).

Das Problem bei einem zusätzlichen Backface-Culling ist folgendes: Da wir bei der Kamera in OpenGL mit einem Sichtkegel arbeiten, funktioniert der einfache Ansatz mit Sichtvektor * Normalenvektor des 3dface nicht, da dies nur für parallelgleiche Sichtvektoren möglich ist. Wenn dieses Problem umgangen wird, finden sich hier in der Literatur weitere Optimierungsmöglichkeiten, wie z.B. das Backface-Culling mit Hilfe von vorberechneten "Sektoren".

Quellenangaben:
[1] Seth Teller Publikationen (http://graphics.lcs.mit.edu/~seth/)
[2] Frustum Culling in OpenGL (http://www.markmorley.com/opengl/frustumculling.html)
[3] Introduction To Plücker Coordinates (http://www.flipcode.com/tutorials/tut_pluecker.shtml)
[4] Fast backface culling with normal masks (http://www.cs.unc.edu/~zhangh/backface.html)