Mh also mit deinen Argumenten bin ich einverstanden ausser mit einem dem mit dem Vis Tree.
Also ich möchte sehen das OQ system schneller ist als die variante mit dem Vis Tree.
Ein denkfehler ist das geschwindigkeit nicht immer durch das rendern von mehr Polys kommt sondern durch mehmaliges rendern warten auf CPU berechnungen und so weiter.
Ich denke in ein echten test wird OQ schlechter abschneiden gerade bei Komplexen riesen arealen.

Polygonbasis:
Ein grund wäre dafür z.B. das bei einem Vis nichts weiter passiert als das er die liste der sichtbaren möglichkeiten mal kurz und schmerzlos abarbeitet(polys testen ob im sichtfeld sind). <-einige Polys werden trotzdem gerendert

OQ muss ich,daten rauswerfen,dann sortieren, ein Query für jedes übrige Poly starten, sichtbare teile rendern. Nicht nur das das mehr cpu und speicherbeanspruchung, glaube ich ist auch der code viel aufwendiger ist. <-nur notwendige polys werden gerendert

Objektbasis:
Beim Vis wird eine liste von Objekten durchlaufen ob diese per Frustum Culling sichtbar sind(sehr wenig CPU leistung). <-einige Polys werden trotzdem gerendert

OQ auch gleiche schritte, objekte aus der liste entfernen die per Frustum culling rausfallen,sortieren,query für objekte und nett rendern <- einige Polys werden Trotzdem gerendert

Die polyvariante können wir ja mal getrost weg lassen, ne umgebung ohne DL oder VBO ist schon sehr unangebracht und diese sind so schnell das ein paar polys mehr nichts mehr ausmachen.

Naja meine Meinung ist praxis geht über Theorie.

MfG TAK2k4

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hier ist eine mehrere Jahre alte Demo, die die Occlusion Queries in Action zeigt:
http://www.inf.bme.hu/~kenez/occldemo.zip

Es ist zwar nicht das typische Level aber eine schwer zu auzuteilende Umgebung, weil es dort keine Strukturen gibt, die die Sichtbarkeit eindeutig einschränken würden.

Occtree und PVS ist keine gute Idee wie die Sache mit dem Base Level Baker zeigt, weil die Schnitte in unnatürlicherweise eben regelmäßig gemacht werden, und damit auch Bereiche in einer Sichtbarkeitszelle landen, die überhaupt nicht zusammengehören, wie z.B. wenn eine Wand direkt durch einen Knoten geht. Beim BSP Baum ist das im Zusammenhang mit PVS nicht der Fall, weil die Welt da in konvexe Bereiche eingeteilt wird, was aber auch nicht immer praktisch ist. Die einzige wirklich allgemeine Lösung sind die Occlusion Queries.