Hi,

ich hab - mal wieder - nen kleines spielchen programmiert... und, in diesem sind manchmal bis zu 10.000 Polygone aufeinmal im Bild.

Nun meine frage... was ist die maximale Polygon zahl die man aufeinmal sehen sollte?? Weil, wenn die 10.000 Polys bei mir sichtbar sind, wird das Programm ziemlich langsam...

Das es an meinem PC liegt glaube ich nicht... (Dual 2x2GHz Athlon XP mit ner GeForce2 Pro) allerdings, wenn mich nicht alles täuscht hab ich mal ein Making of von einem Spiel gesehen, wo der Reporter meinte es seien 70.000 Polygone aufeinmal...

Au'revoir,
Aya

PS: Wenn 10.000 normalerweise noch flüssig gehen müßte... was kann man alles zur Performance steigerung tun??? GL_CULL_FACE hab ich schon an..

theoretisch ist Ende Gelände, wenn die Anzahl der Polygone nicht mehr in den Speicher passt. Bei heute üblichen 64 oder gar 128 MB und dem zusätzlich verfügbaren Hauptspeicher, ist das jede Menge.
Problem: Schleichtende Langsamkeit breitet sich über die szene aus.

Probier's mal mit VisibiliutyCulling, um nicht gezeigt Polygone (die hinter einem sind, von was anderem verdeckt werden oder aus sonstigen Gründen unsichtbar sind) einfach nicht mitzuberechnen.
Dann bietet es sich an, die Texturen zu komprimieren, um Bandbreite für Pixelberechnungen zu Schaffen (VRAM <=> GPU).
Ansonsten ist die Anzahl der Polygone nur durch die Grafikleistung beschränkt. 10.000 ist bei heutigen GraKas nicht besonders viel. Die alten Spezifikationen der GF2 kenne ich nicht.
Ansonsten ist es immer praktisch, die Anzahl der Polygone zu verringern, indem man die Texturen schon entsprechend schattiert, um so die Anzahl der Polygone bei Kugeln oder Röhren zu verringern. Immerhin soll das Programm ja ein möglichst breites Spektrum an Usern erreichen, und dazu gehören dann auch Leute, mit nicht so leistungsstarken GraKas.

P.S.: Au revoir schreibt man immer noch mit ohne Apostroph...

Viele Grafikkarten (unter anderem die GF2) stoßen bei 65.536 Vertices, die auf einmal gezeichnet werden, an ihre Grenzen. Wenn du die aber nacheinander zeichnest, wird das keine Probleme geben.
Unser Spiel hat zeitweise 131072 Dreiecke ohne jegliches Culling verwendet und lief damit flüssig auf meinen 1 GHz Athlon C mit Radeon 8500.

Hi,

Wie meinst du das "nacheinander zeichnen"???

Ich hab eben mal genau geschaut wann das alles genau langsamer wird und bin zu dem ergebniss gekommen das es langsamer wird, sobald man ca. 60.000-70.000 Vertices hat.

Dann ist es egal ob die objekte vor einem sind, hinter einem oder ob man nur eine wand aus 4 Vertices anschaut, es ist stetig gleich langsam.

Wenn ich dann aber die auflösung des fensters auf 160x120 runterstelle läuft es wieder schnell...

Als Texturen benutze ich BMPs mit der größe 64x128x32 (Die Textur wird auf über 500 Objekte gelegt)

Weiß jemand woran das ganze noch liegen könnte??

Au'revoir,
Aya

Es ist egal, ob Du nur 500 Vertices oder alle 60000 Vertices "siehst", es werden von OpenGL immer ALLE berechnet, daher würde ich Dir vorschlagen, dass Du den Sichtbereich in Deine Berechnungen mit einflißen lässt, so dass nur noch das gezeichnet wird, was man auch sieht, der Rest hat eh keinen Sinn *g*.

Frag mich jetzt aber nicht, wie man das macht, hab noch net viel Ahnung von OpenGL

Hi @tommie-lie, was ist den VisibiliutyCulling? Kenne ich nicht, kann mir aber was drunter vorstellen, und hört sich nützlich an. Gibt es dafür einen GL-Befehl/Extension oder muss man das selber implementieren?

In DirectX muss man es jedenfalls selbstmachen, und da DirectX eher mehr Hilfen zur Verfügung stellt als OpenGL, schätze ich, dass du das dort erst recht musst. Im Prinzip ist es ganz einfach. Es gibt einen Körper, der den Sichtbereich (Viewing Frustum) darstellt. Dabei handelt es sich um einen Pyramidenstumpf. Dieser besteht logischerweise aus sechs Ebenen. Jetzt musst du für jeden Punkt überprüfen, auf welcher Seite der Ebenen er liegt. Wenn er bei allen "innen" liegt, ist er im Sichtbereich. Anschließend musst du (und das ist nicht so einfach, ich empfehle das Viewing Frustum Culling Sample aus dem DirectX SDK) überprüfen, ob Dreiecke vielleicht teilweise sichtbar sind, das heißt ob eine der Dreiecksseiten die Ebenen so schneidet, dass sich ein Teil davon innerhalb des Pyramidenstumpfs befindet. Man macht das in zwei Schritten, weil die Prüfung für Punkte schneller ist als für die Geraden (wenn alle Punkte "außerhalb" aller sechs Ebenen liegen, ist das Dreieck definitiv nicht sichtbar, wenn alle "innerhalb" liegen, ist es definitiv sichtbar. Wenn einige Punkte "innerhalb" einiger, aber "außerhalb" anderer Ebenen liegen (und nur dann) muss man noch die Kantenprüfung machen).

Aha...
Nicht sehr viel verstanden, aber die SDK schau ich mir mal an. Danke!

Also, ich denke mal es liegt an der sache mit den 65.000 Vertices... nur, ich versteh nich so ganz was OregonGhost damit meint, das ich die nacheinander zeichnen soll...

@OregonGhost: Erklär mal bitte

Au'revoir,
Aya~

Ich weiß nicht wie du in OpenGL renderst.

In DirectX geht es jedenfalls so: Du definierst alle Vertices in einem Array (oder besser, besonders bei Hardware T&L) in Vertexbuffer. Diese übergibst du den Renderfunktionen in EINEM Aufruf. Wenn du jetzt einen Vertexbuffer mit 200000 Vertices hast und du Direct3D sagst, es soll alle auf einmal rendern, kommt es wahlweise zum beschriebenen Fehler oder zu teilweise ziemlich unerklärbaren Grafikfehlern. Stattdessen sagst du Direct3D also, es soll immer nur 65536 (besser noch weniger) Vertices zeichnen und gut ist. Die Geschwindigkeit erhöht sich und Fehler treten keine mehr auf.

Ich weiß halt nur nicht, wie genau das in OpenGL funktioniert. Wenn ich mich recht erinnere muss man da ohnehin jedes Dreieck einzeln rendern, weil es kein Vertexbuffer-ähnliches Konzept gibt. Vielleicht solltest du das mal probieren, falls du deine Zigtausend Vertices alle in einer Displaylist hast oder so, bzw. ich weiß auch nicht, wann OpenGL sich tatsächlich ans Rendern macht, also ob nach jeder Vertexdefinition oder erst ganz am Ende o.ä.

Ach ja, und letzten Endes kann es auch an der Grafikkarte und VOR ALLEM an den Treibern liegen. In unserem Projekt hatten wir eine GF2MX und es lief am Anfang mit ungefähr 0.2FPS. Dann haben wir ein Treiberupdate sowohl für die Grafikkarte als auch fürs Mainboard (Via 4in1) gemacht und erst dann lief es mit etwa 60 FPS.
Theoretisch kann es auch sein, dass deine GF2Pro schon am Ende ist, je nachdem, wie viele Effekte etc. du ihr zumutest ;c) Selbst wenn nicht, wenn du tatsächlich einen Dual Athlon XP 2000+ (woher?) ist GF2Pro auf jeden Fall zu langsam - da investier lieber mal in eine Radeon 9700 oder in eine GeForce FX, sobald diese erscheint...