Wow, hört sich wirklich interessant und vor allem auch nützlich an...
denke mal du hast das primär für Carad geplant, aber wirds auch ne doku fürn eigenen Einsatz geben? *g*

_________________
. . .

er hat doch geschrieben, dasses nich nur für carad sein soll... interessant wären sicher 2 formate - ein binäres zum flotten einladen und ein textbasiertes, so dass man es gut einladen und debuggen kann, aber das nur als idee - ich weis, was es für gigabytes ergibt, wenn man aussenlandschaften versucht als textdateien abzulegen, ab einer bestimmten levelgrösse wäre dann sicherliuch eine kleine warnung angebracht

Ich verwende zwar BaseGraph für das Utility selbst - die Ausgabe soll aber gut dokumentiert (und leicht ladbar) sein, sodass der BaseLevelBaker ohne BaseGraph genützt werden kann (obwohl BaseGraph natürlich entsprechende Klassen zur Verfügung stellen wird).
Sobald alles steht, wirds noch beispielhafte Lade- und Darstellungsroutinen für Delphi und C geben mit reinem OpenGL geben.

Ein Binär- und Asciiformat sind eine gute Idee - an sich hatte ich eigentlich nur ein Asciiformat geplant, bei großen Datenmengen könnte sich ein Binärformat aber durchaus als nützlich erweisen.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Darauf hab ich gewartet
Juhu, jemand hat mein gebet erhört, octree und pvs

Ich kanns kaum abwartn, bis du ne version online stellst.

Mein versuch mit octree und pvs endete naja... im papierkorb

@FinalSpace
Bin grad mit dem Algorithmus fertig geworden . Mit der Performance des BLB beim Berechnen der PVS Informationen bin ich zwar noch nicht ganz zufrieden, gerade in komplexeren Szenen mit vielen potentiellen Occludern scheinen es PVS Informationen aber schon zu bringen - und das Schöne daran ist, dass es sehr leicht ist, herauszufinden, welchen Nodes ein "externes" Objekt zugeordnet wird - und dann w.eiß man auch schon gleich, ob es sichtbar ist, oder nicht.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Wollte mal nachfragen was der baselevelbaker macht

Mich interessiert das brennend wie du das mit dem octree + pvs gelöst hast.

matane,
Final

Eigentlich ganz einfach:

die Occludertabelle ist eine 2 Dimensionale Bitmatrix, in der die Sichtbarkeitsinformationen von jedem Node zu jedem Node gespeichert sind.
Die Sichtbarkeit wird dabei berechnet, in dem von jedem Eckpunkt und der Mitte eines Nodes in jede Richtung gerendert wird (anhand der Schnittpunkte einer GeoSphere definierbarer Auflösung bestimmt) und mittels Occlusion Queries festgestellt wird, welche Nodes nun sichtbar sind und welche nicht, wobei vom aktuell getesteten Node die Bounding Box verwendet wird, von den restlichen Nodes die tatsächliche Geometrie unter Weglassung "durchsichtiger" Flächen (was einfach ist, da die Dreieckslisten der einzelnen Nodes nach Renderstates sortiert sind, um sie einfach in VBOs packen zu können).

Bei der Darstellung wird dann der Octree ganz normal durchlaufen, und sobald anhand der Bitmatrix sichergestellt ist, dass ein Node verdeckt ist, kann man ihn (und alle seine Kindnodes) verwerfen, auch wenn er eigentlich im Frustum liegen würde.

[edit]
Der BLB ist übrigens schon noch aktuell - zur Zeit fasziniert mich BGP nur mehr, aber irgendwann in nicht allzuferner Zukunft konvergieren die beiden Projekte ohnehin, wenn die Octreeklasse in BaseGraph veröffentlicht wird .

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Seltsamerweise ist das Programm bei mir mit Occtree und PVS langsamer als ohne. Vor dem Erstellen sind es 200FPS und nach dem Erstellen des Occtrees mit und ohne PVS nur ca 50FPS. Die Kamera befand sich dabei direkt vor dem Kugelhaufen, also nicht in der Standardposition, so daß es eigentlich für das PVS recht günstiger ausfallen müßte.

Das liegt daran, dass der Code für das TriMesh Objekt ziemlich optimiert ist - für einfache bis mittelkomplexe Szenen (der Kugelhaufen ist ja recht klein) ist es also günstiger, diese direkt an die GraKa zu senden - insbesondere bei einer schnellen Grafikkarte.
Der Grund liegt auch daran, dass die Beispielszene OpenGL Materialien verwendet, deren Umschaltung insbesondere auf neueren Grafikkarten im Verhältnis ziemlich zeitaufwändig ist - das TriMesh wird bereits beim Erstellen nach Shadern sortiert, während der Octree zwar ebenfalls pro Blatt Dreieckslisten nach Shadern sortiert, das Sortieren der Dreieckslisten über alle tatsächlich gezeichneten Blätter hinweg aber noch nicht eingebaut ist (also viele an sich unnötige Statechanges pro Frame, da "Lazy Management" auch nur etwas bringt, wenn versucht wird, den aktuellen Shader eines bestimmten Typs durch sich selbst zu ersetzen). Außerdem hat es sich als recht ungünstig erwiesen, viele "kleine" Aufrufe von glDrawElements durchzuführen (die Vertex- und Parameterarrays werden einmal übergeben, danach erfolgt das Zeichnen der sichtbaren Blätter über die Übergabe der jeweiligen Dreiecksindizes - prinzipiell ist der Overhead also möglichst gering gehalten) - jedenfalls liefert die Verwendung von Displaylisten einen erheblichen Geschwindigkeitsschub.

Du hast völlig recht, dass der Octree mit PVS bei der Testszene eher suboptimal ist, wenn man nicht gerade mitten in den Kugeln steht - ich möchte das Ganze auch einmal an einer wirklich komplexen 3D-Szene(die etwas realistisch ist, und nicht nur so ein nichtssagender Kugelhaufen, der sowieso nirgends vorkommt ) und mit Sortierung der Dreieckslisten der gezeichneten Blättern probieren, habe aber noch kein geeignetes Testobjekt gefunden. Zum selber Zeichnen fehlt mir momentan die Zeit und die Lust - wenn jemand einen Link auf ein geeignetes Szenario (kann ja im Prinzip irgendwas sein, vielleicht ein Kraftwerk, eine Stadt oder sowas) weiß, wäre ich darob recht dankbar.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Bei Delphi3d.net war mal ein Link auf ein Kraftwerk. Die Datei hatte aber über 100 MB. Das wäre mal ein Extremtest.

@DisplayListen:
Auf Radeon Karten werden nur bestimmte Vertex Formate ohne benutzerdefinierte Attribute und einigen anderen Beschränkungen im Videospeicher abgelegt.

Ich hab mal ne Frage:

Was sind Octrees? Und was macht dein Programm eigentlich? Es hat doch irgendwas mit Level zu tun oder?

mfg, Sindwiller

Für solche Fragen wie "Was sind Octrees" gibts eine Top anlaufstelle hier: http://wiki.delphigl.com Da einfach mal Octree als suchbegriff und du hast den Überblick.

Was sein Programm macht? Ließ mal den Projektthread.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

@Sindwiller
Octrees werden hier erklärt:
http://wiki.delphigl.com/index.php/Octree
Der BaseLevelBaker ist ein Projekt, das ich hier eingehend behandelt habe (dies ist eigentlich das Kommentarforum zu diversen Projekten von Mitgliedern, ich würde mich freuen dort bald auch ein Projekt von dir zu sehen ):
http://www.delphigl.com/forum/viewtopic.php?t=2524

@Lars
Stimmt, nach einigem Stöbern habe ich sogar den Link auf delphi3d gefunden: http://www.cs.unc.edu/~geom/Powerplant/, mal schauen wie das Formaut aufgebaut ist und was außer einem qualmenden Prozessor dabei herauskommt

[edit]
@Sindwiller: ich sehe gerade, dass du schon ein Projekt gepostet hast - dann werde ich auch gleich mal etwas Feedback geben
[/edit]

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Ich habe gestern noch ein Utility geschrieben, welches das verwendete PLY Format des Kraftwerks (leider die binäre Version - und noch dazu Big Endian) als ein BaseGraph TriMesh abspeichert: bei diesen Dimensionen (Über 11 Millionen Schnittpunkte mit Farben und Normalvektoren und über 12 Millionen Dreiecke) tun sich ungeahnte Probleme auf - insbesondere als das resultierende File dann 525 MB groß ist, was ein ziemlicher Brocken für das halbe Gigabyte RAM meines Rechners ist.
So muss ich den Speicher im Voraus allozieren (dynamisches Vergrößern fragmentiert den Speicher trotz Auslagerungsdatei zu sehr) und nach dem Beenden des Konverters (die Konvertierung selbst geht halbwegs flott von der Hand) braucht der Rechner eine Weile bis er wieder brauchbar ist, da nun anscheinend alle anderen Applikationen "ihre" Speicherbereiche wieder von der Auslagerungsdatei bekommen.

Das Laden im Octreebuilder wird dann auch noch lustig, als ich dort mindestens das Doppelte an Speicher benötige (sollte aber klappen) - und für die PVS Informationen dürfte es sich als praktisch erweisen, eine Abbruch- und Fortsetzen Funktion einzubauen, damit man die Berechnung nicht in einem Rutsch durchführen muss, sondern in Stücken, wenn man den Rechner eine Weile nicht braucht.

Ich poste dann auf jeden Fall die Ergebnisse und den Konverter, da es durchaus interessant sein dürfte, das Verhalten von OpenGL bei solchen Datenmengen zu beobachten (ich vermute z.B. dass Displaylisten oder VBOs dann sogar eher suboptimal sind, da der Grafikspeicher auf gebräuchlichen Grafikkarten (meine haben z.B. 64 bzw. 128 MB) hierfür einfach zu klein ist). Zumindest ist es auch ein netter Stresstest für CPU und Speicher .

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

BLB lädt das TriMesh Objekt, auch die Konversion in einen Octree würde theoretisch funktionieren: Die Vertexdaten und -Komponenten des TriMeshes werden in diesem Fall direkt übernommen, nur die Dreiecke werden auf die Blätter aufgeteilt, das Ganze dauert aber viel zu lange, um praktikabel zu sein (nach einer halben Stunde, in denen nur im Taskmanager zu beobachten war, dass der Speicher ganz langsam abnahm, habe ich den Prozess abgebrochen).
Aus diesem Grund habe ich mir mal Nuydens Demo heruntergeladen - er liest die Dreiecke einfach ein, wie sie kommen, und teilt sie in Gruppen von 20000 Stück ein. Interessanterweise schreibt auch er Folgendes in der Readme:

Es würde mich schon motivieren, genau das zu machen - effektiv werde ich in den nächsten Tagen eine weitere Methode ausprobieren, um Octrees zu erstellen: in diesem Fall mit der Garantie, dass kein einziges Dreieck aufgesplittet wird (bei kleinen Dreiecken ist das ja ohnehin egal) und einer entsprechend schnelleren Zuordnung zu den einzelnen Leafs mit Vorberechneten MinMax Koordinaten der einzelnen Dreiecke (ich habe im Verdacht, dass der etwas aufwändige Test, ob Splitting nötig ist, gemeinsam mit den Toleranzparametern, bei der Datenmenge für die langsame Bearbeitung sorgt).

Interessanterweise dauert die Darstellung des gesamten TriMeshes auf meinem Laptop (ATI 9000 64 MB, 512 MB Hauptspeicher, Centrino 1.3 Ghz) extrem viel länger als auf meinem Desktop (P4 2133, GFFX 5600pro 128MB, 768 MB Hauptspeicher) - ungefähr 12 Sekunden pro Frame im einen Fall, 2-3 Sekunden pro Frame im anderen Fall.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/