Unser Forenmember Shadow, der Seit kurzem auch von DGL gehostet wird (http://shadow3d.delphigl.com) hat sich mal etwas intensiver mit dem Thema Octrees auseinandergesetzt und die Tage für die DGL ein Tutorial zu diesem Thema verfasst, dass sich mit der Implementation eines solchen Octrees zum Rendern eines Terrains auseinandersetzt.

Für alle die sich schon immer mal mit Octrees beschäftigen wollten ist das nun dank dieses Tutorials die perfekte Gelegenheit, und eine Beispielanwendung+Quellcode gibts hier zum Download.

P.S. : Wie schon beim letzten teamexternen Tutorial sei auch diesmal gesagt : Wir nehmen natürlich (wie bereits einige Male geschehen) auch Tutorials von Personen die nicht direkt zum Kernteam gehören und veröffentlichen diese hier. Wer also gerne ein Tutorial schreiben will, soll sich also mit dem DGL-Team in Verbindung setzen, und wir regeln das dann.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Jo, also ichn finde das Tut ziemlich cool ... entlich ralle ich das mal, wie man das mit der Einteilung, usw machen kann ^^ Großes Lob an den Autor
Allerdings bleibt mir eine kleine Frage: kann man den Octree wirklich nur dazu nutzen, den Frustrum-Test schneller zu machen? Weil für mich bietet der Frustrum-Test noch etwas zu wenig... ein Beispiel:
Angenommen ich stehe am Rande meioner Karte mit Blick richtung Kartenzentrum. Dort stehe ich vor einem Berg / Wand, meint: Ich sehe echt nicht viel von der Map. Dennoch liegen sehr viele Nodes in meinem Frustrum, da dieses ja nicht auf Sichtbarkeit testet. Folge: sehr viele Nodes werden gezeichnet und hier ist denn sogar die FPS-Zahl niedriger, als bei normalem FC, da ja wirklich fast alles (unnötigerweise) gezeichnet wird. Kann man sowas irgendwie umgehen bzw. kann man den Octree noch irgendwie so modifizieren, dass dieses verhindert wird?

Ansonsten: Super Tut

_________________
Es sind immer die guten,
welche zu früh von uns gehen müssen...
Meine bislang 13 Open Gl - Tuts findet ihr auf www.dcw-group.net
Neu! Ein großer Teil der Demos nach Kylix übersetzt!

Ja, das kann man mit Occlusion Queries umgehene. Dazu hat Lars ja hier auch ein Tutorial veröffentlicht (NV_Occlusion_Query). Bei den Occlusion Queryies rendert man die Boundingboxen der Geometrie (bei einem Octree ist das Ideal, da man diese ja schon in Form der Node-BBs hat) und bekommt dann als Ergebnis zurück ob bzw. wie stark (je nach Extension) diese sichtbar sind. Also rendert man zuerst nen Occlusion-Query-Pass, speichert dort ob eine Node sichtbar ist oder nicht und rendert diese dann im zweiten Pass nur wenn dem so ist. Und wie der Begriff Occlusion erahnen lässt, gehts hier um wirkliche Verdeckung. Wenn ein Knoten also hinter ner Wand liegt, wird dies durch den Occlusion-Test ermittelt.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Wie schnell ist das denn? Ich mein, dazu muss man ja den auch erstmal wieder alels zeichnen + die Boxen ... oder verstehe ich da was falsch? (Man müsste ja immernoch alles Rendern, den Test machen und denn wieder alles sichtbare Rendern, oder ?!?)

_________________
Es sind immer die guten,
welche zu früh von uns gehen müssen...
Meine bislang 13 Open Gl - Tuts findet ihr auf www.dcw-group.net
Neu! Ein großer Teil der Demos nach Kylix übersetzt!

Nein, man rendert wie gesagt nur die Boundingboxen. Also nicht dein Terrain, sondern nur die Octree-Boxen werden beim Occlusion-Pass gerendert. Wenn eine Box sichtbar ist, dann ist ja auch der Teil der Szene der sich darin befindet sichtbar.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Das verstehe ich auch nicht.
Ich kann doch erst wissen, ob Polygone verdeckt werden, wenn ich die Geometrie gezeichnet habe. Anhand der Bounding Boxen meiner Knoten würde ich nur falsche Ergebnisse erhalten, da die BB des Knoten, indem sich der Betrachter befindet alle anderen Knoten verdecken würde. Oder habe ich das total falsch verstanden?

An sich ist die Idee jedoch gar nicht schlecht.
Ich würde das ganze so anwenden:

Zuerst zeichne ich meine feste, statische Geometrie (d.h. den Boden und die Wände meiner Szene). Anschließend kann ich zumindest Objekte wie z.B. Regale, Bäume oder Schränke, die nicht direkt zu meiner Geometrie gehören ausschließen.
Wenn der Knoten des Octrees, in dem sie sich befinden nicht sichtbar ist, sind auch alle Objekte in ihm nicht sichtbar.

Damit ließen sich eine Menge Objekte ausschließen zumal diese Objekte in der Regel viel mehr Polygone besitzen als die eigentliche Geometrie.
Oder meintest du genau das?
Der einzige Nachteil dieser Methode ist, dass sie auf nVidia-karten beschränkt ist. Gibt es vielleicht eine ähnliche Variante der Extension, die auf allen Karten verfügbar ist?

_________________
Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jederman ist überzeugt, dass er genug davon habe.
Rene Descartes, frz. Mathematiker u. Philosoph, 1596-1650

Kann man ein PVS auch in Octrees einbinden oder geht das nur mit BSP-Trees?

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Mit einem Occtree oder einem anderen Baum kann man die Sichtbarkeit völlig ohne PVS berechnen. Da die Occlusion Queries Zeit kosten berechnet man sie eben nur z.B. alle 50 Frames. Dann kostet es fast gar nichts mehr und man bekommt die Sichtbarkeitsinformationen fast umsonst.

Ich meinte das ja auch auf die Sache mit der Mauer. Du prüfst also nicht ob Knoten X von Knoten Y verdeckt wird, sondern nur das Knoten von Occludern wie der oben angesprochen verdeckt werden können.


Das ist dank GL_ARB_occlusion_query schon seit ein paar Monaten herstellerunabhängiger Bestandteil von OpenGL (aber die NV-Extension wird auch z.B. auf ATI-Karten unterstützt).

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Die Knoten in denen sich der Betrachter befindet prüft man natürlich nicht. Denn da weiß man ja schon das sie sichtbar sind.