Tach allerseits!

Gibt es eine Möglichkeit mit VBO's ein IndexArray mit




zu erzeugen?


Zuzeit habe ich das IndexArray im Hauptspeicher (RAM) und möchte das gerne auf der Grafikkarte haben, da gut und gerne 4 Mio. Indices sonst den fröhlichen Weg vom RAM zur Grafikkarte zum Monitor machen.



Die Methode glIndexPointer erschien mir zunächst als das richtige, doch alle Referenzen sprechen davon, dass diese nur auf den ColorPointer bezogen werden. Gibts denn das nicht auch für Vertices und Normals?

thx 4 any commenz.

erledigt

wieso übergibst du im befehl glBufferDataARB nicht die daten?
ich dachte genau dort sollen die daten "auf die grafikkarte" geschrieben werden.
bei dir steht dort aber NULL!

die sache mit GL_ELEMENT_ARRAY_BUFFER_ARB habe ich inzwischen auch gefunden.
ich übergebe die daten nun mit

glBufferDataARB( GL_ELEMENT_ARRAY_BUFFER_ARB, indexCount * sizeof(unsigned int), indices, GL_STATIC_DRAW_ARB );

wobei indices ein pointer auf die index-daten im ram ist.


im rendering code binde ich die daten:

glBindBufferARB( GL_ELEMENT_ARRAY_BUFFER_ARB, vboIndices );

merkwürdig finde ich nur, dass ich anschliessend nicht wie bei den colors und normals und vertices einen gl*Pointer erzeuge

anschliessend zeichne ich die daten mit

glDrawElements( GL_TRIANGLE_STRIP, indexCount, GL_UNSIGNED_INT, 0 );

das funktioniert zwar, gibt mir bei 3Mio. vertices aber immer noch eine beschissene framerate von 2.0!!!

worin besteht der unterschied zu deiner methode, wo du die daten mit dem befehl

glDrawRangeElements() zeichnest???

erledigt

gelöst schon - aber ohne performanceunterschied.

hätte eigentlich erwartet eine höhere framrate zu erreichen indem auch die inices auf der grafikkarte liegen.

der unterschied ist aber nicht erkennbar.

wäre ja möglich, dass die lösung nicht korrekt war und du mit glDrawRangeElements bessere resulatate erreichst.

übrigens hast du ja auch sehr schnell geantwortet - danke dafür

guss
asti

Was erwartest Du bei 3 Mio vertices denn für ne framerate? Wieviele Tris sind das denn? Was hast Du für ne Hardware?

mir ist schon klar, dass bei dieser anzahl vertices die framrate drastisch sinkt.

(P4 2.4GHz, 1.0GB RAM, GeForce 5900 Ultra)

was sind tris?
gerendert wird das ganze als triangle_strip.
wenn tris dreiecke bedeutet: #vertitices pro breite * 2 * # vertices pro höhe ~= 2 * die 3 Mio.

die applikation die ich schreibe stellt eine heightmap dar, die wie in einem CAD-programm gedreht, gezoomt und verschoben werden kann.
dazu wäre natürlich eine framerate von 25 wünschenswert - offensichtlich ist das jedoch nicht zu erreichen

ich würde gerne was mit frustum machen um nur die sichtbaren vertices zu rendern.
weisst du ob das möglich ist, wenn alle daten in einem vbo stecken? (bzw. ein vbo für vertices ein vbo für normals und ein vbo für colors)

4M vertices? Laut Nvidia sollte nur unsigned short als index verwendet werden (maximal 65536 vertices per batch). Dazu sollte der index so optimiert sein, das alle vertices möglichst linear aus dem speicher gelesen werden können (stat zufällige verteilung) und dabei möglichst viele vertices wiederverwerted werden können (die letzten 24 liegen garantiert im cache) ohne diese optimierungen kann ein iniziertes mesh deutlich langsamer sein als ein optimiertes.

Bei glDrawRangeElements kannst du einen Startindex und eine Anzahl übergeben. Damit kannst du beliebige Elemente zeichnen. Egal wie das VBO darunter aussieht.

Allerdings eine komplette Heightmap via einem triangle_strip ist eher nicht möglich (ohne zu schummeln). Du müsstest ja normal um die Ecken zeichnen. Also denke ich eher, dass du Zeilenweise renderst? Da du keine RangeElements benutzt würde das bedeuten, dass du bei jeder Zeile das VBO neu ansetzen müsstest. Von NVidia gibt es ein Dokument, welches so ein paar Flaschenhälse bescheibst. Dort ist so etwas unter anderem aufgeführt. Allerdings hatte Aya das vor einer Weile mal getestet und konnte keinen großen Unterschied feststellen.

Zum Thema Frustrum. Möglich ist das sicherlich. Allerdings würde ich dir eher Empfehlen, dass du so etwas über einen Quadtree zu machst. Also auf keinen Fall auf Vertexebene sondern Blockebene. Also von 10 - 15 ist enthalten. Also Index xy bis yz. Sonst brauchst du mehr Zeit zum Herrausfinden ob ein Vertex sichtbar ist als wie wenn du es direkt zeichnen würdest.

erledigt

Na ja. Also TriangleStrip kannste unter Umständen nur bis zur anderen Seite machen um dann die nächste Zeile direkt rendern zu können müsste man evtl ein Dreieck so rendern, dass es es nicht sichtbar ist. Nur um die Punkte sinnvoll weitersetzen zu können.

aslo erst mal wegen den schummeleien:
um eine fläche mit einem einzigen triangle_strip zu rendern werden sogenannt 'degenerierte dreiecke' erzeugt.
wie das genau funkzt beschreibt euch enigma unter diesem link:
http://www.gamedev.net/community/forums/topic.asp?topic_id=208950

dies funkzt natürlich nur wenn
glPolygonMode() auf GL_FILL gestellt ist - mit GL_LINE werden hässliche querverbindungen von einer seite zur nächsten gezeichnet.


wenn ich versuche die methode gldrawrangeelements auszuführen mekert mir der compiler: identifier not found
nun habe ich gelesen, dass die extension eingunden werden muss. (http://www.gamedev.net/community/forums/topic.asp?topic_id=305795)
dazu wird empfohlen GLee oder GLEW zu verwenden - bleibt dabei alles schön platformunabhängig?
wie kann ich die methode aktivieren ohne solche loading librarys?


oc2k1: woher hast du die information, dass von nVidia aus nur unsigned shorts verwendet werden sollten? wie können die mesh-daten optimiert werden? ich kann mir das nur so vorstellen, dass vertices mehrfach im speicher liegen - dies führt jedoch bei der grossen anzahl zu speicherproblemen.

Lossy eX: 10-15 meinst du fps? das wäre schon genügend. und mit dem quadtree meinst du einen lod-algorythmus (bsp. roettger)?

elektrokrach: auf konstruktive vorschläge der art: haha du depp was bisn du für einer! kann dieses form gut verzichten. bereichere uns besser mit deinem wissen indem du einen vorschlag des maximal möglichen oder vertretbaren angibst. aber wenn du dich schon kaputt gelacht hast wirst du das wohl nicht mehr tun.

Degenerierte Dreiecke: Ich kann zwar derzeit (von hier) nicht auf die Seite allerdings klingt das in etwas so wie ich es gesagt hatte. Also Dreiecke die lediglich dazu dienen um die Position weiter zu setzen. Und das wiederspricht meiner schummeln Aussage ja nicht.

glDrawRangeElements: Schau dazu am Besten mal im "OpenGL® Extension Registry" nach. Dort findest du 3 Header. Und in diesem ist auch die Funktionsdeklaration. Du musst dir von dieser Methode aber vorher noch die Adresse geben lassen. Das ganze geschieht unter Windows mit wglGetProcAddress. Warum wgl, weil diese Methode nicht direkt von der OpenGL32.dll exportiert werden. Unter Linux musst du dazu die Methode glXGetProcAddr (glaube ich). Falls du SDL benutzt kannst du auch die entsprechende Methode von SDL benutzen. Allerdings weiß ich den Namen gerade nicht aber der ist auch so ähnlich.

Quadtree: Nein ich meinte keine FPS und auch keinen LOD Algorithmus. Denn ein LOD bei solchen Datenmengen dürfte sehr schnell zu größeren Berechnungen führen als es stumpf zu zeichnen. Ich meinte eher so etwas wie ein Octree nur eben ohne Höheaufteilung. Oder anders gesagt. Du packst deine Hightmap auf ein Schachbrett und zerteilst sie so in 8x8 Stücke. Aus der Sicht einer Figur müsstest du nun überprüfen ob solch ein bereich sichtbar ist und wenn nein kannst du ihn mit einer Abfrage ausschließen. Richtige Quadtrees würden die Flächen allerdings anders unterteilen. Also erst mal 2x2 die wiederrum in 2x2 unterteilen etc. Damit könntest du größere Blöcke noch schneller unterscheiden aber um das Beispiel einfacher zu machen habe ich es gelassen.

Evtl dürfte der Artikel über Geometrical Mipmapping auch noch interessant sein.

PS: Achtet bitte auf einen netten und freundlichen Umgangston.