DGL
https://delphigl.com/forum/

BaseLevelBaker (BLB)
https://delphigl.com/forum/viewtopic.php?f=13&t=2524		 Seite 1 von 1
Autor:  Mars [ Di Feb 17, 2004 20:35 ]
Betreff des Beitrags:  BaseLevelBaker (BLB)
In der letzten Zeit habe ich mich ein wenig mit Leveleditoren- und Formaten beschäftigt - ich wollte ein Format haben, das für Innen- und Außenlevel gleichermaßen geeignet ist, sodass es auch möglich ist, beides zu kombinieren (z.B. in eine Höhle hineinzulaufen, ohne den Rendercode wechseln zu müssen).

Am Besten geeignet erscheinen mir dafür Octrees zu sein, die auch noch recht einfach zu implementieren sind. Aus diesem Grund möchte ich einen Octree Kompiler schreiben, der aus ganz normalen beliebigen Dreiecksmeshes mit zusätzlichen Vertexparametern (alles optional: bis zu zwei Farben pro Vertex, Normalvektor, Nebelkoordinate, beliebig viele Texturkoordinaten & Vertexattribute) einen Octree erstellt, und in einem gut dokumentierten und leicht ladbaren Format speichern kann, sodass BaseGraph für die Nutzung des Outputs nicht notwendig sein wird.
Die Polygone in den einzelnen Blattknoten werden noch diversen Shadertabellen zugeordnet, sodass Shader- und Texturwechsel innerhalb des Baumes automatisch berücksichtigt werden, wobei der Rendercode darauf achten sollte, ein "lazy" Management zu implementieren (also sich die letzte gesendete Shaderkonfiguration eines Blattes zu merken und nicht noch einmal zu senden, wenn die selbe Konfiguration von einer Dreiecksliste des nächsten gezeichneten Blattes angefordert wird).

In dem Octree sollen auch PVS Informationen abgespeichert werden (mit Berücksichtigung durchsichtiger Flächen), sodass jeder Ast/jedes Blatt weiß, welche anderen Baumelemente von ihm aus gesehen sichtbar sind, sodass wirklich effizientes Culling betrieben werden kann (was in Zeiten von komplexen Shadern ja wieder wichtig wird) und außerdem für eine eventuelle AI nützlich sein sollte.

Außer Carad Dateien sind als mögliche Eingabeformate auf jeden Fall 3DS und DeleD fest eingeplant, Normale und Tangenten sollen auf Wunsch auch "on the fly" berechnet werden können.
Ich hoffe in einigen Tagen ein Demo mit Beispielcode liefern zu können.
Autor:  Mars [ Fr Feb 20, 2004 23:06 ]
Betreff des Beitrags: 
So, die Grundlagen der Octreeklasse stehen jetzt. Eigentlich hatte ich es mir einfacher vorgestellt, dadurch dass ich zwecks Optimierung die Dreiecksdaten gegen die jeweiligen Bounding Boxes clippe, wurde die Generierung des Baumes recht aufwändig - dies war allerdings zwingend notwendig, da die einzelnen Knoten des Baumes auch als Displaylisten oder VBOs verwaltet werden können sollen, ohne dass ein Overdraw stattfindet (alternativ hätte ich auch Dreiecke mehreren Knoten zuordnen und doppelt zeichnen können, bzw. über Flags sicherstellen, dass ein gezeichnetes Dreieck nicht nochmal gesendet wird, was sich allerdings recht negativ auf den Speicherdurchsatz auswirkt).

Der Algorithmus ist getestet und stabil (Generierung der Knoten erfolgt über maximale Dreiecksanzahl pro Knoten), interessant wird jetzt die Generierung der PVS Informationen.
Grundsätzlich wird dies folgendermaßen aussehen, dass überprüft wird, ob aus einem bestimmten Knoten die Bounding Box eines anderen Knoten sichtbar ist oder nicht.
Dies hat zwar zur Folge, dass manchmal ein Knoten auch gesandt wird, wenn seine Polygone von anderen Polygonen verdeckt werden - dafür kann man diese Information auch nützen, wenn man dem Knoten ein dynamisches Objekt zuweist (z.B. eine Spielfigur) - wenn die Bounding Boxes der Knoten, in denen sich ein Objekt potentiell befindet nicht sichtbar sind, dann kann das Objekt auch nicht sichtbar sein, und man muss sich nicht weiter drum kümmern, auch wenn es eigentlich im Frustum liegen würde.

Dateianhänge:
Dateikommentar: Ein erster Screenshot eines etwas komplexeren Testobjekts, die Polygondaten werden entlang der Bounding Boxen zerlegt, was leider nicht so gut sichtbar ist.
Dafür sieht man, dass das Grundelement des Octrees nicht zwingenderweise ein Würfel sein muss
Unbenannt.jpg
Unbenannt.jpg [ 71.87 KiB | 11310-mal betrachtet ]
Autor:  Mars [ Sa Feb 21, 2004 20:58 ]
Betreff des Beitrags: 
Ein weiterer Schritt auf dem Weg zu einem fertigen Programm: dank Noeskas 3DS Loader (der Umstieg von Lischkes 3DS-Loader ging erfreulich problemlos von der Hand, man muss eigentlich nur die verschiedenen Render-Routinen umbauen, um die 3DS-Daten leicht in jedes beliebige Objektformat zu konvertieren - Textur- und Materialinformationen stehen praktischerweise auch schon zur Verfügung, die muss ich allerdings noch etwas umbauen, um sie in meine eigenen Renderroutinen zu integrieren).
Hier der Octree eines Tempels mit ca 40000 Schnittpunkten, sogar ohne PVS Informationen ist der Octree schon spürbar schneller, da der Frustumtest viel besser greift.
"Günstige" Szenen für Octrees sollten übrigens Polygone ungefähr der selben Größe enthalten - wenn es viele kleine und einige sehr große Dreiecke gibt, werden die großen Flächen ohnehin nur zerschnitten, was ja auch nicht der Sinn der Sache ist.
Wenn dann auch PVS Informationen verwaltet werden, werden sich auch "dicke" Wände bzw. Trennobjekte (also nicht nur einfache Flächen) als günstig erweisen, damit die "andere" Seite der Wand auch dann noch als Occluder wirken kann, wenn man dicht vor der Wand selbst steht.

Dateianhänge:
Unbenannt.jpg
Unbenannt.jpg [ 22.19 KiB | 11279-mal betrachtet ]
Autor:  Mars [ Mo Feb 23, 2004 21:37 ]
Betreff des Beitrags: 
PVS Informationen werden generiert, benötigen allerdings einen OpenGL Treiber mit Occlusion Queries. Der BLB wird optional die Mesa 6 Treiber verwenden können, sodass er auch (langsam aber doch) auf älteren Systemen ausgeführt werden kann.

Das Format für den Datenaustausch ist auch schon soweit, der Header sieht folgendermaßen aus:
Code:
  1.   TOctreeFileHeader = packed record
  2.     Magic            : Cardinal;       // $88888888
  3.     Verts,                             // number of vertices
  4.     Elements,                          // number of Octree nodes
  5.     Shaders          : integer;        // number of shaders used
  6.  
  7.     Norm,                              // vertex normals present ?
  8.     Color,                             // vertex colors present ?
  9.     SecondaryColor,                    // secondary vertex colors present ?
  10.     FogCoord         : LongBool;       // vertex fog coordinates present ?
  11.     TexCoordSets,                      // number of texture coordinate sets (0..32)
  12.     Attribs          : integer;        // number of general per-vertex attributes (0..32)
  13.  
  14.     ColorComponents  : integer;        // color components used (3, 4)
  15.     TexCoordComponents: array[0..31] of integer; // texture components used per texture set (1..4)
  16.     TexCoordUnits    : array[0..31] of GLenum;   // OpenGL texture units to send texture coordinates to (GL_TEXTURE0..GL_TEXTURE31)
  17.     AttribComponents : array[0..31] of integer;  // attribute components used per attribute (1..4)
  18.     AttribIndices    : array[0..31] of Cardinal; // attribute indices to send attributes to (0..31)
  19.  
  20.     VertOffset,                        // relative offset to vertex data
  21.     NormOffset,                        // relative offset to normal data (if present)
  22.     ColorOffset,                       // relative offset to color data (if present)
  23.     SecondaryColorOffset,              // relative offset to secondary color data (if present)
  24.     FogCoordOffset   : Cardinal;       // relative offset to fog coordinate data (if present)
  25.     TexCoordOffsets  : array[0..31] of Cardinal; // relative offset to texture coordinate data of set n (if present)
  26.     AttribOffsets    : array[0..31] of Cardinal; // relative offset to attribute data n (if present)
  27.     ElementOffset    : Cardinal;       // relative offset to octree elements
  28.     PVSOffset        : Cardinal;       // relative offset to visibility map table
  29.   end;


Theoretisch können Schnittpunktdaten mit sehr vielen Attributen geladen werden, eine Anwendung kann sich aber auch darauf beschränken, nachzusehen ob bestimmte Komponenten vorhanden sind (z.B. nur Texturkoordinaten für Textureinheit #1, über den Offset in der Datei dorthin springen und diese laden, ohne sich um das andere Zeugs kümmern zu müssen.

Der Minimale Octree besteht aus
* Positionsdaten
* Nodeinformationen
* PVS Informationen

alles andere kann beim Laden berücksichtigt werden, muss aber nicht (theoretisch braucht man auch die PVS-Informationen nicht zu laden - was in meinen Augen aber keinen Sinn macht).

Alle Informationen können "in einem Aufwasch" geladen werden, außer den Nodeinformationen, da in diesen noch die darin liegenden Dreiecke befindlich sind, die in einer Schleife geladen werden müssen.
Pro Node kann es beliebig viele Dreieckstabellen geben, die unterschiedlichen Shadern* zugeordnet sind, wobei die Shader selbst nicht in der Datei gespeichert werden, sondern zur Laufzeit dann den einzelnen Indizes zugeordnet werden (man weiß also, welche Dreiecke unterschiedlichen Shadern zugeordnet werden, und auch welchen Index diese Shader haben, wie diese konkret aussehen, weiß man nicht).
Alles andere würde bedeuten, dass eine Verwaltung von Texturen, Materialen und so weiter vorgegeben wird, was ja gerade nicht der Sinn der Sache ist.

*(Unter Shader verstehe ich nicht (nur) Vertex- und Fragmentprogramme, sondern auch Texturwechsel, Material, Ein- und Ausschalten von OpenGL Renderstates - kurz alles was nicht direkt mit dem Senden von Geometriedaten zu tun hat).

Die PVS Informationen sind Bittabellen über alle Nodes hinweg, sodass jeder Node sofort die Informationen hat, welche Nodes von ihm aus sichtbar sind und welche nicht. Diese Informationen als Bits anstelle von Booleans zu verwalten macht sinn, da ansonsten bereits bei 1000 Nodes 1000x1000 Bytes, also fast ein Megabyte, verbraten würde.

Ich denke mal, dass ich im Laufe der nächsten Tage eine funktionsfähige erste Version online stellen kann, die dann zeigen wird, inwiefern PVS Informationen in Octrees tatsächlich etwas bringen.
Autor:  Mars [ Di Feb 24, 2004 21:27 ]
Betreff des Beitrags: 
Einen letzten Screenshot gibt es noch, bevor ich das Ganze als eigenständiges Projekt zusammenstelle (damit man auch sieht, was das Ganze eigentlich soll :wink: ).
Die PVS Informationen werden sauber generiert, allerdings braucht die Berechnung ziemlich lange - einerseits ja verständlich, da als Eingabe völlig unstrukturierte Daten zulässig sind (jedenfalls kann ich mir jetzt gut vorstellen, warum die meisten Editoren nur geschlossene, konvexe Brushes als Elemente zulassen), andererseits hätte ich mir dank Hardware Occlusion Culling schon etwas mehr Performance erwartet - immerhin könnte es schlimmer sein, für komplexe Szenarien muss man halt Wartezeiten im Halbstunden / Stundenbereich einrechnen - berechnet werden müssen die Sichtbarkeitsinformationen zum Glück aber nur ein einziges Mal.

Die PVS Informationen werden generiert, indem die Szene von jedem Node aus an mehreren Punkten (Eckpunkte und Mittelpunkt) in alle Richtungen (gewonnen aus einer Geosphere um eine gleichmäßige Verteilung zu erhalten) in den DepthBuffer gerendert wird, der aktuelle Node und dessen Unternodes werden dabei nicht gezeichnet.

Im Anschluss daran werden Occlusion Queries für die Bounding Boxen der anderen Nodes durchgeführt, überschreiten die gezeichneten Pixel einen bestimmten Schwellwert, wird der jeweilige Node als sichtbar markiert.

Das Ganze sieht dann wie unten aus: der "Betrachter" (oder irgendwas anderes) befindet sich im roten Node, die gelben Nodes sind von diesem Node aus sichtbar, die blauen nicht.
Wenn man genau hinsieht, erkennt man, dass nicht nur die linke Kugel hinter dem offensichtlichen Occluder verdeckt wird, sondern auch einige kleinere Nodes hinter der rechten Kugel.

Dateianhänge:
Unbenannt.jpg
Unbenannt.jpg [ 37.02 KiB | 11214-mal betrachtet ]
Autor:  Mars [ Mo Okt 11, 2004 01:15 ]
Betreff des Beitrags: 
Totgeglaubte leben länger, oder so ähnlich heißt es - und tatsächlich hat der BaseLevelBaker nach über einem halben Jahr präsentierbare Formen angenommen.
Bild
http://www.basegraph.com/bg/blb/blb.zip.

Die Funktionsweise wurde ja schon in den bisherigen Posts erklärt, sodass ich hier eher auf die Oberfläche eingehen werde:

Load File lädt eine Datei, wobei es sich zur Zeit um ein VAD (Vertex Attribute Data, wird weiter unten erklärt) oder eine BaseGraph Datei, wie sie von Carad erzeugt wird handeln kann. Später werden noch BaseGraph Pascal Datendateien und 3DS hinzukommen, andere Formate können ja über Carad importiert, oder in eigenen Programmen als VAD exportiert werden.

Beim Laden einer Datei werden sämtliche Objekte darin automatisch in ein großes TriMesh (= Set aus Dreieckslisten, die verschiedenen Zusammenstellungen von Shadern zugeordnet sind) konvertiert, aus dieser "Dreieckssuppe" wird fürderhin der Octree generiert werden. Die Erstellung des selben wird über folgende Parameter gesteuert:

Threshold: maximale Anzahl von Dreiecken in einem Blatt
MinDepth: minimale Rekursionstiefe
MaxDepth: maximale Rekursionstiefe
Tolerance: Toleranzwert beim Zerschneiden der Polygone.
Über Threshold und MinDepth kann gesteuert werden, ob man sich rein auf die Anzahl der Polygon konzentrieren möchte, oder aber ob es wichtiger ist, dass alle Nodes eher gleich groß sind, was insbesondere dann wichtig ist, wenn der Octree nicht nur sich selbst, sondern auch andere Objekte darstellen soll, oder auch z.B. für Kollisionserkennung und Physik herangezogen wird.
Ich wollte, dass die Octreeklasse allgemeingültig ist, d.h. es sollte egal sein, ob die zugrundeliegende Polygonsuppe aus großen, kleinen, vielen oder wenigen Polygonen besteht. Was in jedem Fall vermieden werden sollte, war auch das mehrfache Rendern einzelner Polygone, aus diesem Grund werden Polygone an den Rändern eines Blattes zerschnitten, wobei aber sämtliche Vertexattribute an der Schnittstelle ebenfalls mitberechnet werden.
Das Zerschneiden einer Fläche hat aber den Nachteil, dass neue Schnittpunkte und Polygone entstehen - aus diesem Grund gibt es den Toleranz-Parameter, mit dem man einstellen kann, dass, wenn ein Polygon nur "ein wenig" über die Grenze eines Blattes ragt, das Blatt wächst, anstatt, dass das Polygon zerschnitten wird. Es ist in jedem Fall garantiert, dass ein Polygon nur in einem einzigen Blatt aufscheint, und dass die Box eines Nodes die Boxen sämtlicher untergeordneter Nodes inkludiert.
Ein zu kleiner Toleranzwert hat zur Folge, dass im schlechtesten Fall an den Rändern von Blättern viele sehr kleine Polygone entstehen (ungut), ein zu großer Toleranzwert lässt die Nodes unverhältnismäßig stark wachsen, was auch nicht im Sinne des Erfinders ist - sinnvolle Werte liegen zwischen 0.5 und 0.01.

Nach der Erstellung eines Octrees ist eingestellt, dass jeder Node von jedem anderen Node aus sichtbar ist - sogar jetzt kann er aber schneller gerendert werden (zumindest, wenn sich der Betrachter "darin" befindet), da Frustum Culling automatisch auf die Nodes angewandt wird. Ein Octree rendert auch eine sehr große Anzahl von Nodes performant, da Kindnodes automatisch verworfen werden, sobald ein Elternnode nicht gerendert werden muss.
Die Erstellung der PVS Informationen kann über folgende Parameter gesteuert werden:

GS Order: "GeoSphere Order", die Anzahl der Richtungen, in die von verschiedenen Punkten eines Blattes aus gerendert wird - bei 0 sind es 20, je höher die Ordnung, desto exakter die PVS Informationen, desto langsamer aber auch die Berechnung der PVS Informationen. Null reicht für das voreingestellte field of view von 60° aus, wenn man ein geringeres Field of View verwenden möchte, sollte eine GS Order von 1 verwendet werden - 2 oder mehr bringen nur bei sehr geringem FoV etwas.
Quick Query: Es wird nur von der Mitte eines Blattes aus gerendert - das beschleunigt die Sache erheblich, sollte aber nur bei kleinen Blättern (MinDepth relativ groß) verwendet werden. Zum Testen praktisch, da ansonsten die Berechnung der PVS Informationen besonders für komplexere Szenen recht lange dauert.
Samples: Maximale Anzahl von Pixeln, ab denen ein Node als "sichtbar" betrachtet wird, wenn er von einem anderen Node aus gesehen wird. Es macht eventuell keinen Sinn, Nodes zu rendern, wenn nur sehr wenige Pixel davon sichtbar sind, insbesondere als für die Sichtbarkeitsberechnung eines Nodes dessen Bounding Box und nicht dessen Inhalt herangezogen wird.

Wie gerade erwähnt, könnte ich für die Occlusion Queries theoretisch auch den Inhalt des Octrees heranziehen, anstatt die Bounding Boxes der einzelnen Nodes zu rendern - dies würde dann ein etwas exakteres (sprich weniger Nodes wären sichtbar) Ergebnis liefern. Ein statischer Octree alleine ist aber recht langweilig, und damit die PVS Informationen aber auch für externe Objekte herangezogen werden können, sobald festgestellt wurde, in welchen Blättern diese sich befinden, ist wichtig, von welchen Nodes aus die BoundingBox eines bestimmten Blattes sichtbar ist oder nicht.

Sonstige Einstellungen sind noch:
Draw Tree: Der Octree selbst wird mitgezeichnet, zusammen mit einigen weiteren statistischen Informationen
Display Lists: Die Dreiecksinformationen der einzelnen Blätter werden in Display Lists anstelle von Vertex Arrays gespeichert. Das bringt einen erheblichen Geschwindigkeitsschub, da der Octree ohnehin statisch ist, sehe ich auch keinen Vorteil darin, statische VBOs zu verwenden - und Display Lists laufen auch auf älteren OpenGL Implementationen (in der Tat benötigt nur die Octree Builder Klasse Occlusion Queries, die Octree Klasse selbst funzt bereits mit OpenGL 1.1). Wenn Display Lists vor dem berechnen der PVS Informationen eingeschaltet werden, wird die Berechnung derselben ebenfalls etwas beschleunigt.
Wireframe Rendering: Wie der Name sagt, die Darstellung des Meshes spiegelt aber ebenfalls den aktiven Node sowie die Sichtbarkeit vom aktiven Node aus wieder.
Viewer Node: anstatt über den Rollbalken wird der aktive Node über die Position des Betrachters gesetzt
Light From Viewer: Die OpenGL Lichtquelle 0 wird auf die aktuelle Position des Betrachters gesetzt (und verbleibt dort, auch wenn der Betrachter bewegt wird)

In der Klasse vorhanden, aber noch nicht ins Programm eingebaut sind:
* das Entfernen von Nodes ohne Dreiecke - hauptsächlich für die Darstellung interessant, bei der Einordnung externer Objekte ist eine größere Anzahl von Blättern hingegen eher günstig.
* das Freigeben von SPeicher nach der Erstellung von Displaylisten - für Applikationen wichtig, der Octree Builder verzichtet hingegen darauf, vor allem weil ich jederzeit Zugriff darauf haben möchte, wieviele Dreiecke eigentlich darin gespeichert sind.
* das Speichern von fertigen Octrees, weil ich noch nicht weiß, wie ich halbwegs elegant und ohne Einschränkungen Shader hineinbekomme, wenn ich nicht auf das Carad (*.bg) oder BaseGraph Pascal Exportformat (*.bgp) zurückgreifen kann - wahrscheinlich wird mir nichts anderes übrig bleiben, als halt Namen abzuspeichern, die ein Benutzer dann nach dem Laden selbst auswerten muss.

Zum Testen ist eine .bg Datei mit dabei, eigene Programme können hingegen VAD Dateien exportieren, die sehr einfach aufgebaut sind:
Die erste Zeile stellt die Vertexkomponenten dar, die im folgenden gespeichert werden. VAD ist sehr flexibel und kennt folgende Attribute:
V3 (Vector XYZ)
N3 (Normal XYZ)
C3 (Color RGB)
C4 (Color RGBA)
S3 (Secondary Color RGB)
F1 (Fog Coordinate)
T1 (Texture S)
T2 (Texture ST)
T3 (Texture STR)
T4 (Texture STRQ)
A1 (Attribute X)
A2 (Attribute XY)
A3 (Attribute XYZ)
A4 (Attribute XYZW)

Texturkoordinaten und Attribute können auch mehrfach angegeben werden, für Multitexturing macht etwa folgendes Sinn:
V3/T2/T3/
Bedeutet erst kommt eine Position, Textureinheit #1 bekommt ST, Textureinheit 2 bekommt STR Werte, die Reihenfolge, in der die Vertexkomponenten angegeben werden ist egal, nach dem Laden könnten den einzelnen Texturkoordinatensets beliebige Textureinheiten zugeordnet werden.

Nach den Vertexkomponenten folgt eine Leerzeile, danach kommen die Vertexdaten selbst, wobei die gespeicherten Floats der Reihenfolge in den Vertexkomponenten entsprechen müssen, zwischen den einzelnen Vertexkomponenten steht ein / nach jedem vollständig definierten Vertex kommt ein Zeilenumbruch.
Wenn mehrere Objekte in einer Datei gespeichert werden, genügt es, zwischen den einzelnen Objekten Leerzeilen zu lassen - nach dem Laden könnten diesen Objekten dann wieder Shader zugeordnet werden.
Prinzipiell weiß das VAD Format nichts von dem Polygon Primitive für das Daten gespeichert wurden (Dreiecke, Vierecke, u.s.w.), BLB geht aber davon aus, dass sämtliche Objekte aus Dreiecken bestehen, die jeweils als drei Punkte gespeichert werden.

Ein VAD für einen Würfel mit 2D Texturkoordinaten und Normalvektoren sieht etwa folgendermaßen aus:
Code:
  1. V3/N3/T2/
  2.  
  3. -0.5 -0.5 -0.5/0 0 -1/0 0/
  4. -0.5 0.5 -0.5/0 0 -1/1 0/
  5. 0.5 0.5 -0.5/0 0 -1/1 1/
  6. -0.5 -0.5 -0.5/0 0 -1/0 1/
  7. 0.5 0.5 -0.5/0 0 -1/0 0/
  8. 0.5 -0.5 -0.5/0 0 -1/0 0/
  9. 0.5 -0.5 0.5/0 0 1/0 0/
  10. 0.5 0.5 0.5/0 0 1/0 0/
  11. -0.5 0.5 0.5/0 0 1/0 0/
  12. 0.5 -0.5 0.5/0 0 1/0 0/
  13. -0.5 0.5 0.5/0 0 1/0 0/
  14. -0.5 -0.5 0.5/0 0 1/0 0/
  15. -0.5 -0.5 0.5/-1 0 0/0 0/
  16. -0.5 0.5 0.5/-1 0 0/0 0/
  17. -0.5 0.5 -0.5/-1 0 0/0 0/
  18. -0.5 -0.5 0.5/-1 0 0/0 0/
  19. -0.5 0.5 -0.5/-1 0 0/0 0/
  20. -0.5 -0.5 -0.5/-1 0 0/0 0/
  21. 0.5 -0.5 -0.5/1 0 0/0 0/
  22. 0.5 0.5 -0.5/1 0 0/0 0/
  23. 0.5 0.5 0.5/1 0 0/0 0/
  24. 0.5 -0.5 -0.5/1 0 0/0 0/
  25. 0.5 0.5 0.5/1 0 0/0 0/
  26. 0.5 -0.5 0.5/1 0 0/0 0/
  27. -0.5 -0.5 -0.5/0 -1 0/0 0/
  28. 0.5 -0.5 -0.5/0 -1 0/0 0/
  29. 0.5 -0.5 0.5/0 -1 0/0 0/
  30. -0.5 -0.5 -0.5/0 -1 0/0 0/
  31. 0.5 -0.5 0.5/0 -1 0/0 0/
  32. -0.5 -0.5 0.5/0 -1 0/0 0/
  33. -0.5 0.5 0.5/0 1 0/0 0/
  34. 0.5 0.5 0.5/0 1 0/0 0/
  35. 0.5 0.5 -0.5/0 1 0/0 0/
  36. -0.5 0.5 0.5/0 1 0/0 0/
  37. 0.5 0.5 -0.5/0 1 0/0 0/
  38. -0.5 0.5 -0.5/0 1 0/0 0/
  39.  
Autor:  Mars [ Di Okt 12, 2004 11:32 ]
Betreff des Beitrags: 
Der Export von Octrees ist nun ebenfalls eingebaut, der weiter oben angeführte Dateiheader ist immer noch aktuell. Die Shaderverwaltung wird jetzt einfach so gelöst: jeder Node enthält Dreieckstabellen, die einen Shaderindex enthalten. Eine Anwendung ist dann dafür verantwortlich, die entsprechenden Shader (z.B. Texturen) auch zu laden, und auch darzustellen, wenn die entsprechende Dreiecksliste gezeichnet wird. Als Hilfestellung erstellt BLB zusätzlich zum Octree Export noch eine .shd Datei, in der steht welche Shader welcher Shaderliste zugeordnet sind, und eine BaseGraph Datei, in der die tatsächlichen Shader gespeichert sind (hauptsächlich damit sie BLB selbst wieder laden kann, da es kaum Sinn machen dürfte, ohne BaseGraph Daten daraus laden zu wollen).

Mit dabei ist der vollständige Source einer Anwendung, in der eine Octreeklasse (ohne BaseGraph) den Octree lädt und darstellt, wobei die einzelnen Shaderlisten einfach durch eindeutige Farben dargestellt werden (der Code sollte halbwegs übersichtlich sein und relativ einfach für eigene Zwecke adaptiert werden können). Das Hauptprogramm basiert auf dem OpenGL15 Template von Sascha Willems und verwendet die dglOpenGL.pas. Der Importer verwendet absichtlich keine Streams.

Hier kann der Beispielimporter heruntergeladen werden:
http://www.basegraph.com/bg/blb/octreeloader.zip

Die neue Version des BaseLevelBaker ist immer noch hier:
http://www.basegraph.com/bg/blb/blb.zip

Damit ist das Projekt im Großen und Ganzen (bis eventuell noch die Unterstützung weiterer Formate) abgeschlossen, Feedback und Verbesserungsvorschläge werden gerne gesehen :wink: .
Autor:  Mars [ So Okt 24, 2004 19:11 ]
Betreff des Beitrags: 
Ausgehend von diesem Modell: http://www.cs.unc.edu/~geom/Powerplant/ habe ich mal getestet, inwieweit Octrees, respektive die Verwendung von PVS bei diesen auch unter realen (und in diesem Fall ziemlich harten) Bedingungen brauchbar sind.
Das Ergebnis war, dass man jedenfalls keine Chance hat, das komplexe Modell in einem Aufwasch zu Rendern - bis ein Frame gezeichnet ist, dauert es in jedem Fall mehrere Sekunden, es sei denn, das ganze Modell liegt außerhalb des Frustums. Aus diesem Grund auch die CheckBox "Idle Draw" mit der man das Neuzeichnen der Szene beim Idle Ereignis ausschalten kann - das Programm wird ansonsten beim Laden eines derart komplexen Modells unbrauchbar.

Sobald ein Octree erstellt wurde, sieht die Sache schon anders aus, man erreicht akzeptable Frameraten, solange nur ein Teil des Modells im Frustum liegt, unter ungünstigen Bedingungen (Viewer schaut vom Rand auf die Szene) bricht das Ganze jedoch gnadenlos ein. Die Leistung erhöht sich unter Verwendung von PVS spürbar, insbesondere als das Modell recht verschachtelt ist, soll heißen, hinter den sichtbaren Polygonen liegen noch mehrere "Schichten" Interiors (etwa Rohrsysteme), die so teilweise recht gut gecullt werden.

Hier eine Darstellung des Modells im BLB:
Bild
Und dasselbe als Drahtmodell mit Darstellung der gecullten Nodes (die Anzahl in der Titelleiste ist bedingt aussagekräftig, da Nodes die innerhalb eines durch PVS gecullten Nodes liegen, nicht als PVS gecullt gezählt werden).
Bild
Threshold wurde mit maximal 8192 Dreiecken pro Blatt gewählt, Tolerance hat bei TriBake (der Option die einen Octree zu erstellen ohne Dreiecke zu zerteilen) keine Auswirkung.

Aufgrund des komplexen Modells musste ich mehrere Teile des Codes zum Erstellen und Zeichnen von Octrees ändern: es gibt nun eine Möglichkeit Octrees aus TriMeshes zu erstellen, ohne dass Dreiecke zerteilt werden (sobald ein Dreieck teilweise in einem Node liegt, wird es diesem (und nur diesem) zugeordnet, am Ende wachsen die einzelnen Nodes einfach ein wenig) und die Blätter verwalten auch die Dreieckslisten nicht mehr selbst, sondern nur noch mehrere Shadertabellen mit Start- und Endindizes in eine globale Dreiecksliste, die den Nodes entsprechend sortiert wird. Dies ist natürlich nur möglich, weil ein Dreieck nur in genau einem Node aufscheinen kann. Die Erstellung des Octrees erfolgt also hauptsächlich InPlace, sodass das ständige Allozieren und Freigeben von Speicher nicht mehr nötig ist (dies war ein großes Problem beim ursprünglichen System, das bei dem komplexen Modell zu exzessiven Swapping und schlussendlich unerfüllbaren Speicher).
Leistungsmäßig ist das Ganze brauchbar, die Dreieckssuppe wird in einigen Sekunden in einen Octree umgewandelt, das Berechnen der PVS Informationen benötigte hingegen mehrere Stunden, obwohl ich ohnehin "Quick Query" angeschaltet hatte, das nur ein Neuntel der standardmäßigen Sichtbarkeitsüberprüfungen durchführt. Immerhin ist mein PC weder besonders schnell noch besonders gut ausgerüstet, sodass der BLB durchaus ein brauchbares Werkzeug ist, wenn man ihn über Nacht laufen lässt (die meisten Modelle sind ohnehin sehr viel weniger komplex).

Die Framerate bei der Darstellung war alles andere als konstant und sehr abhängig von Beobachterposition und -winkel, besser greifen würde der Octree, wenn man mit MinDepth kleinere Nodes "erzwingt", da von einem großen leeren Node aus relativ große Teile eines komplexen Modells sichtbar sind. Überhaupt scheinen mir die Standardeinstellungen viel zu vorsichtig gewählt worden zu sein, da auch die Verwaltung von sehr vielen Nodes durch die hierarchische Struktur leistungsmäßig bei der Darstellung überhaupt nicht ins Gewicht fällt (bei der Erstellung des Octrees und insbesondere der PVS Informationen allerdings sehr wohl), Culling hingegen besser greift.

Das Format der Octrees hat sich etwas verändert, da nun die Dreiecke in einer großen Liste liegen, auf die von den Nodes aus nur noch Start- und Endindices verweisen, weswegen ich die Tage auch den Beispielimporter überarbeiten und gemeinsam mit einer neuen BLB Version hochladen werde.
Seite 1 von 1 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/