Hallo Forum,

ich muss/möchte mal wieder nerven

Ich habe ein kleines Labyrinth erstellt (20 mal 20 OGL-Einheiten groß) und bewege mich da durch…

Wenn ich mich in den „Außenbereichen“, also an den „Rändern“ des Labyrinthes befinde, habe ich so ca. 75 FPS. Drehe ich mich jetzt an so einer recht schnellen Stelle und sehe Richtung Zentrum des Labyrinthes, so sinkt meine Framerate auf ca. 35.
Ich habe versucht die Framerate durch Verwendung von BackfaceCulling zu erhöhen, dies hat jedoch so gut wie gar nichts gebracht. (Ich zeichne nicht Standartkonform CounterClockWise, sonder ClockWise – ist das langsamer oder einfach nur nicht Standart?)

Welche Möglichkeiten habe ich jetzt noch das Rendern zu beschleunigen? Ich habe da von Raumunterteilungsmöglichkeiten gelesen, habe davon allerdings noch keine Ahnung. Welche der „vielen“ Unterteilungsmöglichkeiten sollte ich für ein recht simpel aufgebautes Indoor-Level benutzen? Gibt es Tutorials?

Wieso wird der Rendervorgang eigentlich langsamer wenn ich Richtung Zentrum sehe? Ich dachte der Tiefentest schmeißt alle Bildinformationen, die nicht sichtbar sind raus und berechnet sie nicht. Aber da liege ich wohl falsch 

Wieder mal Fragen über Fragen, sorry….

Nun, wenn ein Triangle gezeichnet werden soll, überprüft die Grafikkarte zuerst, ob es überhaupt sichtbar ist. Erst dann wird es gerastert. Schaust du nun zum Rand, fallen schonmal die meisten Triangles dabei raus. Schaust du dagegen zur Mitte, muss die Grafikkarte viele Triangles testen.

Auch wenn dieser Test recht schnell geht und auf jeden Fall schneller ist, als einfach jedes Triangle Brute Force zu rastern, ist er alles andere als optimal.

Bei einem Labyrinth, was eher 2D-mäßig aufgebaut ist, würde ich spontan zu Quadtrees greifen, da die da wohl am einfachsten und mit am effizientesten sind.

Der Tiefentest hat damit erstmal gar nichts zu tun. Der ist nur dafür da, dass deine Fragmente korrekt überzeichnet werden. Sonst würden auch Objekte, die hinter einer Mauer z.B. sind, sichtbar sein, obwohl sie eigentlich verdeckt werden müssten. Dafür ist der Tiefentest da. Aber auch das geht leider nicht immer. Probleme gibt's beim Alphablending... Aber der Workaround dafür ist auch nicht schwer. Nur etwas lästig

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

Mhhhh...danke erstmal für die schnelle Antwort!

Wie viel würden wohl DisplayListen bringen?
Mein Labyrinth besteht ja nur aus QUADS und haben den Aufbau:

Diese "Bausteine" habe ich in Prozeduren verpackt. Das Labyrinth besteht also aus Quadern mit logischerweise 6 QUADS pro Quader. Lohnt es sich jetzt wohl für jeden dieser "Bausteine" eine eigene Liste zu erstellen, oder sind die Listen dann zu "einfach" und bringen nicht wirklich eine Leistungssteigerung?

Displaylisten bringen ne Menge. Aber dann kannst du auch gleich VBOs verwenden. Etwas Treiber-Woodoo

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

Also ich glaube Display-listen müssten rein definitionsgemäß schneller sein als VBOs in gesetzt dem Fall du hast eine statische Geometrie(hast du ja). Weil OGL dann ja bei der compilierung alle Zeit der Welt zum optimieren jender Listen hat. Stört einen ja eh nich wenns nur einmal am Anfang passiert....
Andererseits, haben VBOs ja auch ne static-flag oder so, (grübel..) der würd dann sicher das selbe bedeuten... naja auch in dem Fall würd ich dann zu DisplayListen raten, da sie für Einsteiger intuitiver erscheinen... und da bei statischer Geometrie min. genauso performant wie VBOs sind...

Mfg

_________________
www.extrawurst.org

Generell gibt es 3 Möglichkeiten:

1. Vertexanzahl-gebunden:
Hierfür wäre es interessant zu wissen wieviele Quader du in etwa zeichnest. Wenn du sagst 20x20 Einheiten groß, meinst du dann 1 Quader ist 1x1 Einheiten groß? Und meinst du damit auch du hast maximal 20x20 Quader und nicht 20x20x20 Quader? Mit 20x20 (also max 400 Quadern) kann ich mir kaum vorstellen das du Vertexgebunden bist. Mit 20x20x20 wär das jedoch ggf. möglich, vor allem wenn du im immediate mode renderst (also das glBegin( GL_QUADS ) ).

2. Füllratengebunden:
Wenn du Füllratengebunden bist, dann müsste dir zwar das Backface Culling schon einiges bringen, aber dennoch würde ich diese Möglichkeit nicht von vorn herein ausschließen. Das nette daran ist, dass du das recht leicht überprüfen kannst:

Du setzt die Auflösung so niedrig wie möglich (320x200 (wenn das bei dir noch geht :-) ), und wenn du immer noch kaum mehr als 35 FPS hast, dann bist du offenbar nicht Füllratengebunden.

Du müsstest - wenn du Füllratengebunden bist - immer mehr FPS bekommen je weiter du von deinem Labyrinth weg bist. Erst wenn du es gar nicht mehr siehst (also es sich hinter der Far-Plane befindet) sollte es zu einer wirklich spürbaren Performance Steigerung kommen, wenn du Vertex gebunden wärst.

Spätestens wenn du diese beiden Sachen überprüft hast, kannst du dir sicher sein, dass die Füllrate in deinem Fall nicht ausschlaggebend ist.

3. Bandbreite des AGP / PCI Busses:
Diese ist (in deinem Fall) sehr Eng verbunden mit der Vertexanzahl und lässt sich auch nicht so ohne weiteres überprüfen, ist jedoch im Verhältnis zu 1. eher unwahrscheinlich. Da die Hilfsmittel dagegen jedoch sehr ähnlich sind wie bei 1., kann man mal so viel sagen: du hast zu viele und/oder zu unperformant gesendete Vertices die du rendern möchtest.

Nun zu den Lösungsmöglichkeiten:

Für 1. (Vertex-gebunden):
Hier helfen dir (wie bereits meine Vorgänger erwähnt haben) Display Listen und Vertex Arrays zumindest ein bisschen. Aber vor allem ist es hilfreich, wenn du die Anzahl der Quads die gerendert werden senken könntest. Da ich hier nicht mit Sichtbarkeitsalgorithmen anfangen möchte, beschränke ich mich auf das Offensichtliche:
Du sagst du möchtest ein Labyrinth haben und du sagst du renderst dieses mit Quadern / Würfeln. Wenn ich das richtig verstehe, dann hast du irgendwo einen 2D- oder 3D-Array wo die einzelnen Quader drinnen stehen im sinne von:
XXXX
X000
X0XX
X0XX
Wobei ein X einen Quader dar stellt und die 0er keinen Quader (also begehbar sind).
Nun benötigst du jedoch nicht für jeden Quader 6 Seiten, sondern kannst einige Seiten einfach weg lassen (die wo der Nachbar ebenfalls ein Quader ist). Dadurch solltest du schon einiges an Quads einsparen können. Wenn du nun noch nebeneinander liegende Quader zu einem größeren Quader verbindest, so kannst du noch mal einiges einsparen.

Für 2. (Füllraten-gebunden):
Hier hättest du leider kaum Alternativen zur Sichtbarkeitsabfrage. Weniger Texturen, weniger Beleuchtungseffekte, geringere Auflösung und dergleichen würden allerdings auch einiges bringen falls das in Frage kommt und falls du überhaupt wirklich aufwändige Berechnungen diesbezüglich durchführst.

Für 3. (Bandbreiten-gebunden):
Vor allem hier helfen Display Listen und Vertex Arrays. Aber natürlich würden auch weniger Dreiecke kein Nachteil sein :-). Also dies ist wie bereits erwähnt sehr eng verbunden mit 1. .


Zu den Display Listen wäre noch zu sagen:
Es würde sich wahrscheinlich um _einiges_ mehr lohnen wenn du das gesamte Labyrinth (oder wenn es sehr groß ist, größere Teile davon) in jeweils eine Display Liste gibst. Einen Quader in eine Display Liste zu werfen macht hier zwar auch Sinn, aber dadurch würdest du dir halt die unter 1. erwähnten Optimierungen ziemlich vertun.

Ach ja, und wenn dein Labyrinth wirklich so dynamisch ist, dass du keine größeren Teile davon in eine Display Liste packen möchtest, dann würde es sich höchst wahrscheinlich empfehlen nur einen Würfel (oder Quader) als Display Liste zu verwenden und diesen entsprechend zu transformieren bzw. zu skalieren. Jeder Quader einzeln als Display Liste wäre dann wahrscheinlich doch etwas zu viel des Guten ...

Nochwas zur theorie. Eventuell könntest du die Framezahl auch noch erhöhen, wenn du erst sehr Nahe flächen zeichnest und erst später die weit entfernten. Dadurch kommt der Tiefentest besser zum Tragen. Um nicht jedesmal alles durchsortieren zu müssen verwendet man die angesprochenen Raumunterteilungstechniken. (Stehen im Wiki.) Sascha hat auf DelphiGL.de glaub ich ein Tutorial zu Frustums, dass ist auch noch interessant (weil schneller als der OpenGL intere Weg). Und wie gesagt... Quadtrees wären das richtige für dich (Wenn dein level plötzlich auch höhenetagen bekommt, dann Quadtree). Wenn du Türen und Fahrstühle hast sind Portale auch noch möglich.

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

Erstmal vielen Dank für die sehr ausführlichen Beiträge!

@Lyr:
Also erstes mal, deine Annahmen bezüglich der 20*20 OGL-Einheiten waren alle richtig. Jeder Quader hat die Größe 1*1*1, es sind insgesamt 20*20 Quader und nicht 20*20*20.

Ich glaube bei mir trifft tatsächlich Fall 2 zu (Füllratengebunden). Allerdings hat das Culling so gut wie nichts gebracht.
Bei niedrigen Auflösungen habe ich konstant meine ca. 80 Frames. Bei einer hohen Auflösung (1024*768) hingegen sinkt die Framerate wenn ich Richtung Zentrum sehe.

Bei dieser Funktion habe ich bei der hohen Auflösung immer konstant meine 75-80 Frames, weil er sich ja die Texturen sparen kann. Kannst du mir Links nennen, auf denen ich mehr über Sichtbarkeitsabfragen erfahren kann? Du hattest ja davon geschrieben...
Texturen habe ich übrigens zur Zeit nur drei verschiedene. Alles .jpg und jeweils 256*256 Pixel groß. Das sollte also kein Problem sein. OGL-Licht habe ich keine. Es ist also ein absolut simpler Raum!
Ich habe übrigens einen AMD 1000MHz, 256 MB Ram und eine Elsa Gladiac GeForce II GTS. Spiele wie Unreal Tournament 2003 laufen ohne Probleme und die sind ja nun wirklich um einiges Aufwändiger als meine paar Wände

Ich werde auf jeden Fall die Sache mit den Displaylisten probieren. Eigentlich müsste ich das ganze Level in eine Liste bekommen...

Die Anzahl meiner Quads kann ich auch noch verringern, (darüber habe ich Idiot noch gar nicht nachgedacht.) wenn ich zwei oder mehr nebeneinander liegende Quads nicht einzeln zeichne, sonder als ein großes Quad und entsprechend dann die Textur kachele...

Also, vielen Dank nochmal für alle Hinweise! Ich werde es mal probieren...

Display Listen werden dir im Fall Füllratengebunden kaum was helfen ... spricht allerdings nicht dagegen das ned trotzdem zu machen :-).

Die Reduzierung der Anzahl der Quads sollte übrigens auch bei der Füllrate einiges helfen, also zumindest das weg lassen von Quads. Ob du mehrere kleinere oder einen größeren hast dürfte da jedoch eher egal sein.

Eine recht einfache Möglichkeit hast du noch um die Grafikkarte bzgl. Füllrate etwas zu entlasten:
Zeichne dein Labyrinth so gut als möglich von vorne nach hinten. Soll heißen die Quads die am nähesten zu dir sind in etwa als erstes rendern. Dadurch wird ein Fragment beim Tiefentest recht schnell verworfen. Hierfür empfiehlt sich beispielsweise ein Octree bzw. Quadtree wo du im Wiki sogar ein Tutorial findest, ansonnsten -> Google. Ein BSP-Baum wäre dafür sogar noch etwas besser geeignet aber für das was er dir bringt dürfte er zu viel Aufwand bedeuten. Auch schon die einfache Variante würde in deinem Fall wahrscheinlich schon fast Ideal sein (Pseudocode):


Ich denke wenn du diese beiden Optimierungen eingebaut hast (unnötige Quads raus und von vorn nach hinten) wirst du schon wieder auf eine ganz akzeptable Framerate kommen. Ansonnsten musst du wohl oder übel auf Techniken wie Portale oder Potentially Visible Sets (PVS) zurück greifen. Wenn du auf neue Hardware abzielst, und dein Labyrinth sehr sehr selten von oben (oder von unten) betrachtet wird, dann könntest du über Hardware-Occlusion Querys (gibts ne Extension dafür) auch noch einiges raus holen, vor allem wenn du sie als Alternative zu Software-Sichtbarkeitsabfragen verwendest.

Abschließend solltest du immer im Hinterkopf haben, dass alles über 30 Frames noch flüssig ist. Erst wenns da drunter fällt musst du dir ernsthaft gedanken machen. 80Frames sind durchaus spielbar.

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

@Flash: Nein 30 FPS ist nicht flüssig, es sei denn du hast sehr sehr gutes Motion Blur, wobei Motion Blur häufig nur als cooler Effekt implementiert wird, also meist weniger realitätsnah. Perfektes Motion Blur erreichst du natürlich wenn du etwas mit einer Kamera auf nimmst, da reichen dann 25 FPS. Bei Spielen sollte man schon schauen das es so um die 60 sind, obwohls mit 30 sicher noch spielbar ist aber man merkt es schon. Aber 30 FPS heute => mit etwas Glück 60 FPS in einem Jahr :-).