Wie kommst du denn darauf?
Der einzige Unterscheid ist, dass man nicht in acht sondern nur in zwei kleinere Knoten aufteilt und die Teilungsebene freier gewählt werden kann, meistens eine Ebene aus den verwendeten Flächen.

Die StaticMeshes bei UT2003 hatten für die Kollisionsabfrage früher jeweils einen Occtree, aber in einer späteren Version wurde das in einen BSP Tree geändert.

Denke es kommt eine Referenz auf das Dreieck kommt in alle Boxen, die es berührt und beim Zeichnen wird dann speziell aufgepaßt, das man nichts doppelt zeichnet.
Es gibt wenige große Engines, die hauptsächlich auf einen Occtree setzen.
Bei Quake3 wird das aber so beim BSP Baum gemacht, denn da taucht das Problem ja genauso auf.

Das stammt von der Seite http://www.conitec.net/forecast.htm, die ich entdeckt hab, als ich bei Google nach Delphi und Octree gesucht hab.

Dieses StaticMeshes bei UT2004 sind mir nocht ganz geheuer. Bei einem Viertel von denen muss man erst noch eigene KollisionsVolumen erstellen, sonst bleibt man z.B. an Säulen hängen, die ein paar Meter entfernt erst anfangen...

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Das scheint wohl eine Einschränkung der Engine. Generell, unabhängig von Occtree oder Bsp Baum, sollte man aber direkt beim Level bauen darauf achten, das die Punkte halbwegs auf einem Gitter liegen, was ja meist automatisch durch den Editor geschieht. Denn die Gleitkommazahlen haben ja eine beschränkte Genauigkeit.

Diese Kollisionsvolumen werden nur zur Kollision mit den Spielern genutzt. Für die Waffen und so Linien Tests wird die tatsächliche Geometrie genutzt und da kann es sich schon lohnen. Durch die Gitter kann man ja auch durchschießen, obwohl die bei den meisten Objekten einfach eine Box drumherum gesetzt haben.

Ich hätte da auch noch eine frage bezüglich Octrees

Ich habe Vertex-Daten aus einer 3d-File geladen, da diese mehrere texturen haben, kommen alle Vertices mit gleicher Textur in eine Parent-Node, die dann später unterteilt werden, um so wenig texturwechsel wie möglich zu haben - klappt auch wunderbar soweit. Übrigens bleiben Vertices die zwischen zwei kinder-nodes hängen im parent node, was mehr oder weniger ein billiger Trick ist um das anfangs genannte Problem zu umgehen

Bei bestimmten 3d-daten können leider dadurch recht große nodes entstehen, die sich im Extremfall z.b. von der einen Ecke der Karte zur anderen ziehen. bei bestimmten kamera-einstellungen sind dann alle 8 eckpunkte ausserhalb des sichtbereichs, und die (eigentlich sichtbaren) nodes verschwinden - jedenfalls denke ich dass es so ist, es wird halt überprüft ob der parent-node sichtbar ist, wenn ja werden die kinder geprüft, dann deren kinder, etc... irgend eine idee wie man das am inteligentesten umgeht?

(ich hoffe ich habs halbwegs verständlich formuliert )

_________________
www.omfg.biz - aktuelles projekt

Was meinst du denn mit zwischen den kinder-nodes hängen ?

hrm.. na das was die ursprüngliche frage dieses posts war wenn ein polygon zwischen zwei nodes liegt und dann entweder gar nicht gezeichnet (wie in dem screenshot) oder doppelt gezeichnet(wie in dem tutorial) werden. ist eine komische formulierung, geb ich zu

_________________
www.omfg.biz - aktuelles projekt

Du kannst sie auch zu beiden Knoten hinzufügen und dann beim Rendern nur einmal zeichnen.

Also wenn du sie in den Parent-Node hängst dann musst du doch nur alle Polys die du auf auf deinem Weg zu den kind-Knoten findest zeichnen. Sollte es Polys geben die aufgrund ihrer Größe dadurch immer sichtbar sind geben, dann tut das wenig weh, da es wahrscheinlich nur recht wenige sind.

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

@red: Meinst du das Programm, was beim Tutorial dabei war, oder das Tutorial an sich?
Wenn sie im Tutorial-Programm doppelt gezeichnet würden, hätten wir ja das Problem nicht.

@lars: Was geht schneller? Ein Polygon einfach nochmal zeichnen, oder vorher überprüfen, ob es schon gezeichnet wurde?

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

auf aktuellen karten ist es definitiv schneller, das polygon doppelt zu zeichnen, statt einer pruefung, ob es nicht schon gezeichnet wird. auf hardware sollte man nur pruefen, ob viele polygone auf einmal nicht gezeichnet werden muessen. bei einzelnen bremst dies immer.

Wenn der DepthTest auf GL_LEQUAL steht und teure Shader an sind, weil das z.B. gerade so an der Stelle sein muß, dann ist das sicherlich nicht billiger und bringt auch falsche Ergebnisse.
Ansonsten sind natürlich polygonbasierte Verfahren generell schlecht. Deshalb kann man die Objekte auch gleich zusammenbehalten und die Objekte und nicht die Polygone einzeln in den Baum einfügen.

Ich hab gerade gemerkt, dass es quasi 2 Versionen von Shadows Octree gibt. Die ältere, die auch im Tutorial behandelt wurde, zeigt keine Löcher in der Landschaft, läuft aber wesentlich langsamer. Sowohl die Ladezeiten, als auch Performance beim Rendern ist nicht so gut wie bei der zweiten Version, von der auch der Screenshot am Anfang dieses Threads stammt.

Darn sieht man auch recht gut, dass der rote Hinweis von Shadow im Tutorial Gold Wert ist und es sich wohl lohnt, wenn man seine Polygone in VBOs ablegt. Hätte immer gedacht, das wäre schwerer.

Es werden wohl anscheinend im "alten" Octree, der sich hier bei DGL unter Files->VCL findet, einige Polygone doppelt gezeichnet, was jene Bodenlöcher verhindert. Es wäre sicherlich interresant, beide Versionen dazu zu bringen, die gleiche Geometrie zu verwenden und alles in VBOs abzulegen, um mal den direkten Performance-Vergleich zwischen Octress mit doppelt gezeichneten Polygonen und Octress mit Löchern im Boden festzustellen.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Wirkt sich die Einstellung des DepthTest auf die Performance aus oder hast du das gerade eben nur im Zusammenhang mit den Shadern gesagt? Bin ich froh, dass ich mich noch nicht an Shader rantraue Somit bleibt dieser Spaß erstmal erspart...
Und wieso sind polygonbasierte Verfahren generell schlecht? Was ist, wenn man z.B. ein Level in 3DS Max gemacht hat, bei dem einige wenige Objekte recht viele Polygone haben? Beispielsweise eine Mondlandschaft mit vielen Kratern. Die besteht aus einem einzigen Objekt, jedoch aus vielen Polygonen. Wenn man nur das Objekt (bzw. die BoundingBox) durchs Frustrum jagen würde, würde die meiste Zeit, die gesamte Landschaft gezeichnet, obwohl nur ein Teil sichtbar ist.

Ich lasse mich gern eines Besseren belehren, aber ich sehe gerade keinen wirklichen Vorteil darin...

EDIT: Die zweite Octree-Version stammt direkt von Shadows Homepage...

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

so dann einmal ein vorschlag des authors....

ich würde mich für die einfachste aller lösungen entscheiden und die Polygone mit Hilfe ihrer Bounding Box checken und falls diese in mehreren Nodes ist einfach öfter zeichenen, denke, dass der Verlust, des 2 oder 3 mal zeichen, locker durch die Vorteile des Octrees aufgeholt wird und dass dieser Fall sowieso nicht für so viele Polygone zu trifft.

Das Splitting fänd ich echt zu kompliziert(TexCoords neuberechen usw.)

wobei man sagen muss, dass man da für größere Projekte schon eine bessere lösung finden muss, da dieser kleine performace verlust dann schon nerven kann...

aber für kleinere Demos ist es, denke ich, vollkommen ausreichend, es wie beschrieben zu lösen

Peace Shadow

Ich würde die Lösung von Lars mit den ParentNodes favorisieren. Einfach, elegeant und kein overhead.

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