Schnellstes Anzeigen von Terrain über OGL

[remi_meier]

Ich will wieder ein Theorie & Konzeption - Forum!

Also ich habe im Moment eine HeightMap, die sich auf Tastendruck ändern kann. Dann habe ich noch eine Procedure, die die neuen Normalen berechnet und sie in ein Array schreibt.
Im Moment erstelle ich eine GLList wo ich das Terrain drin speichere. Nun ist aber das Compilieren (#GL_COMPILE) der Liste etwas langsam (vermute ich). Ich habe es jetzt noch nicht ausprobiert, aber ich denke, dass auch das Anzeigen des Terrains ohne vorkompilieren zu langsam wäre.
Mit Vertex-Arrays habe ich es noch nicht probiert und habe auch keine Ahnung, wie schnell das wäre.
Welche Methode ist die schnellste? Gibt es noch weitere?

Danke schonmal im Vorraus!
remi

[DarkDragon]

VertexArrays, VertexBufferObjekte und GLLists(man kanns kombinieren). Außerdem sollte man #TRIANGLE_STRIPS benutzen.

Für mich sehe ich durch einer Änderung zu 'nur' VertexArrays selbst keine Geschwindigkeitsänderung . Wenns nach allen änderungen immernoch zu langsam ist solltest du dir mal deine OpenGL Version nachschlagen.

[remi_meier]

Der Hauptteil ist im Moment so:

Code: Alles auswählen

startW = #AREA_SIZE / 2.0 - #AREA_SIZE
  startL = -#AREA_SIZE / 2.0 + #AREA_SIZE
  
  listid = glGenLists_(1)
  
  If glIsList_(listid) = #GL_TRUE
    Debug "Fehler: Liste existiert schon"
  EndIf
  
  
  glNewList_(listid, #GL_COMPILE) ;>
    
    For i = 0 To #AREA_SIZE - 2 ;z
      glBegin_(#GL_TRIANGLE_STRIP)
      For j = #AREA_SIZE - 1 To 0 Step -1  ;x
        p1\x = startW + j + xpos
        p1\y = -height_field(j, i+1) * #EXTRUDE + ypos
        p1\z = startL - (i + 1) + zpos
        
        p2\x = startW + j + xpos
        p2\y = -height_field(j, i) * #EXTRUDE + ypos
        p2\z = startL - i + zpos
        
        
        aux = 3 * ((i + 1) * #AREA_SIZE + j)
        glColor3f_(height_field(j, i+1) + 0.3, 0.0, 0.0)
        glNormal3fv_(@TerrainNormals(aux))
        glVertex3fv_(@p1)
        
        aux = 3 * (i * #AREA_SIZE + j)
        glColor3f_(height_field(j, i) + 0.3, 0.0, 0.0)
        glNormal3fv_(@TerrainNormals(aux))
        glVertex3fv_(@p2)
        
      Next
      glEnd_()
    Next 
  glEndList_() ;<

Natürlich kommt da noch die Normalenberechnung dazu. Was könnte man den hier noch ändern?
Die Anzeigegeschwindigkeit ist eigentlich nicht zu langsam, nur möchte ich die Vorbereitungsphase (d.h. das Compilieren zur GLList) möglichst beschleunigen, da das bei mehrfacher Terrainveränderung sehr lansam werden kann. Ich suche also eine Echtzeitmöglichkeit um das Terrain dynamisch zu verändern!

greetz
remi

EDIT:
Im Moment scheints schneller zu sein, jedesmal diesen Hauptteil (Code oben), einfach ohne zur GLList zu kompilieren, an OGL zu "senden".

[DarkDragon]

Ich suche also eine Echtzeitmöglichkeit um das Terrain dynamisch zu verändern!

Dann speicher es in einen Array und nutze VertexArrays. Achja: Listen kompillieren sollte man nicht andauernd(also nur vor dem anzeigen ein mal, dann nimmer)! Bei VertexArrays zeigste einfach auf den Array in dem die entsprechenden Daten sind(siehe http://www.ultimategameprogramming.com/ ... nGL&page=8 )


BTW.: Es kommen neue UltimateGameProgrammingTutorials(Yai)

[EDIT]
:P man kompilliert auch nicht jede millisekunde mal ne GLList!

[remi_meier]

Habs mal ausprobiert, aber das direkte Zeichnen ist schneller als die VertexArrays...
Falls es noch mehr Möglichkeiten gibt, lasst es mich wissen!
Danke trotzdem DarkDragon!

greetz
remi

[traumatic]

Im Moment erstelle ich eine GLList wo ich das Terrain drin speichere. Nun ist aber das Compilieren (#GL_COMPILE) der Liste etwas langsam (vermute ich).

Vorkompilierte Listen machen bei nicht-statischen Objekten auch irgendwie
keinen Sinn, oder? Das Ganze ist ja dazu da, um eben nicht alles in jedem
Durchlauf neu berechnen zu müssen - fällt bei Deiner Idee, das Terrain auf
Knopfdruck ändern zu wollen, allerdings flach. Je nach GraKa ist das Kompilieren
von Displaylisten langsamer als das einfache Rausrendern - wie Du bereits
bemerkt hast.

Wie DarkDragon schon meinte, auf jeden Fall Quad-Stips oder Triangle-Strips
benutzen, so müssen nur die hälfte der Vertices durch die Pipeline geschickt werden.

Ein weiterer Gedanke:
Je gröber die Unterteilung, desto schneller die Ausgabe. Du solltest Dir also
möglicherweise Gedanken über eine "Level Of Detail"-Implementation machen
(Quadtrees). Die Teile Deines Terrain, die sehr weit weg vom Betrachter sind,
müssen ja nicht unnötig Detailreich ausfallen.

HTH

[DarkDragon]

Ein weiterer Gedanke:
Je gröber die Unterteilung, desto schneller die Ausgabe. Du solltest Dir also
möglicherweise Gedanken über eine "Level Of Detail"-Implementation machen
(Quadtrees). Die Teile Deines Terrain, die sehr weit weg vom Betrachter sind,
müssen ja nicht unnötig Detailreich ausfallen.

HTH

Also das mit dem LOD find ich nun doch ein wenig übertrieben. Ein gutes Frustumculling reicht erstmal.

Außerdem: Wie willste das bei nem Terrain machen? Sind doch eigentlich vierecke von oben. Wenn du dann nach vorne siehst kannste doch nicht einfach ein paar Vierecke in Dreiecke umwandeln. Sieht doch scheiße aus, wenn das Terrain mit einem Dreieck endet. :P

[traumatic]

Also das mit dem LOD find ich nun doch ein wenig übertrieben. Ein gutes Frustumculling reicht erstmal.

Soso...

Außerdem: Wie willste das bei nem Terrain machen?

http://www.vterrain.org/LOD/Papers/

[DarkDragon]

Hmm... stimmt, ich kanns mir bildlich vorstellen. Weit weg von der Kamera werden einfach die Quads gruppiert(meinetwegen werden 4 dann zu 1) und ganz nach werden sie sogar noch unterteilt.

[remi_meier]

Wenn ich keine Textur drüberlege, könnte es dann sein, dass NURBS vielleicht noch eine Variante wären?
LOD werde ich wahrscheinlich nicht brauchen, ich glabe kaum, dass das bei 256 * 256 Map-Punkten schon viel Geschwindigkeit bringt...