OpenGL-Buffer als Grundlage für Model-Rendering

[Eisflamme]

Hi,

Also ich möchte performancemäßig gerne gleich das Optimum rausholen und wollte mich darüber erkundigen, ob das so geht:

Ich möchte halt einen VertexBuffer und einen IndexBuffer (kA, ob man das in OpenGL so nennt) verwenden. Wie das funktioniert, habe ich jetzt bereits rausgefunden. Ich würde beides auch auf der GPU speichern über diese OpenGL-Buffer-Extensions.

Zur Zeit mache ich es halt so, dass ich einen VertexBuffer, einen ColorBuffer und einen TextureCoordinatesBuffer verwende (und den IndexBuffer würd ich halt hinzufügen; und wo ich's gerade überlege, bräuchte ich ja auch nochn NormalBuffer oder so was) und alles über diese Buffer gewährleiste. Das alles zusammengepackt in einer Klasse würde ich später gerne als Basis für 3D-Models verwenden und beim Laden der Datei würde ich alles füllen.

Denkt ihr, diese zig Buffer, bald noch zusammen mit dem IndexBuffer stellen einen guten Ansatz dar oder gibt es hier irgendwelche Stolperfallen bzw. sollte ich diese Buffer (liegen ja auf der GPU, oder?) nicht mit Allem belasten, weil das zu viel ist. Wenn ich halt hunderte Models habe, könnte das problematisch werden. Ich hab ehrlich gesagt keine große Ahnung, wie man Modelle überhaupt puffern sollte. Mache ich das bei größeren Abschnitten einer riesigen Welt (ich denk immer viel weiter, als ich müsste) einfach über die Festplatte, sodass ich dann Modelle nachlade, oder sollte ich auch zwischen Heapspeicher und GPU-Speicher herumschieben?

Viele Fragen, vielleicht hat jemand viele Antworten oder einen coolen Link bzw. irgendeine Buchempfehlung (falls das halt unbedingt nötig ist, ich bin Anfänger).

Viele Grüße

[Ingrater]

Also man verwendet in der Regel für OpenGL VBO's (vertex buffer objects) dabei hat man in der Regel 2 Buffer einen Buffer mit den Vertexdaten und einen mit den Indizies. Die Daten sind in der Regel ineinander verschachtelt also z.b.

Position1-Farbe1-Texturekoordinaten1-Position2-Farbe2-Texturekoordinaten2-...

OpenGL bietet allerdings im Gegensatz zu DirectX auch die möglichkeit die daten Blockweise abzulegen

Position1-Position2-...-Farbe1-Farbe2-...-Texturkoordinate1-Texturkoordinate2-...

Damit können die Grafikkarten allerdings schlechter Umgehen, wenn man allerdings nur regelmäßig die Positionen verändern muss spart es Zeit und Aufwand.
Das einzige tutorial das ich dafür kenne ist das hier: http://nehe.gamedev.net/data/lessons/le ... ?lesson=45 allerdings ist hier schlecht das er mehere Datenbuffer anlegt anstatt einen großen zu verwenden. Aber es zeigt die Prinziepelle Nutzung der Extension. Pack besser die Daten in nur einen Buffer wie bei der 1. von mir beschrieben Methode. Hierzu brauchst du bei den Pointer calls den Stride parameter.

MFG Ingrater

[Eisflamme]

Ahh, verstehe. Okay, wenn das geht, ist das natürlich super. Dann werd ich später meine Buffer auch in einen großen switchen.

Das Problem daran ist halt ein wenig, dass ich dem Benutzer meiner Klasse überlassen wollte, was er alles verwendet. Wenn man z.B. die Color-Komponente nicht braucht, würde ich sie jetzt ja immer mitschleppen... Es sei denn, ich baue mir einen großen untypisierten Buffer und befülle den selbst irgendwie. Aber ich glaube, diese Option hat gar nicht so viele Vorteile, oder?

Ach und noch was fällt mir ein: Wir haben ja mehr Indices als Vertices. Dann wären ja ganz viele Index-Einträge unbesetzt, weil es mehr Vertices gibt. Also ist das schon ein viel größerer Speicheraufwand. Ist das vernachlässigbar?

[Ingrater]

Also nur die Daten kommen in einen großen Buffer. Für die Indcies musst du dann schon einen separaten Buffer anlegen.
Ich habe mir eine Vertexbuffer klasse geschrieben die mitgeteilt bekommt welche Daten alle gehalten werden sollen. Sie managed dann das intern und verteilt die Daten richtig auf den Buffer. Ich kann also auch z.b. die Farbe weglassen. Im Normalfall brauchst du dann später sowieso immer die gleichen Daten. Position, Texcoords, Normale und Tangente. Es ist dann praktisch auch egal wenn in dem Buffer mehr Daten drin sind als du wirklich benutzt. Nur falls du dann Platzprobelme auf dem Vram kriegst musst du dich um solche Probleme kümmern.

[Eisflamme]

Hi,

Okay, cool. Dann hätte ich noch eine (hoffentlich) letzte Frage : Normalen haben wir doch auch nur je Fläche und nicht je Vertex. Also hätten wir hier doch wieder das gleiche Problem wie mit den Indizes, oder?

[Ingrater]

Naja man berechnet aus den Normalen pro Fläche die Normalen pro Vertex damit das gesamte Mesh rund und nicht Facetiert aussieht. Von daher hat man dann schon eine Normale pro Vertex. Aber das sollte im Normalfall das Meshloaderlib deiner Wahl tun (nimm Assimp )

[Eisflamme]

Hm, ja. Das ist jetzt ja eh doof, wenn wir z.B. 8 Vertices und 6 Flächen haben, dann habe ich ja pro Vertex ne Normale, die aber zu 2-3 Flächen gehört

(ASSIMP sieht super aus; ich werd erstmal versuchen, 3DS selbst zu laden, dann aber bestimmt das nochmal angucken)

[Krishty]

OpenGL bietet allerdings im Gegensatz zu DirectX auch die möglichkeit die daten Blockweise abzulegen

Bietet D3D auch, aber man erzähtl sich, das sei <D3D10 haarstreubend weil nicht alle Treiber mit klarkommen.

Gruß, Ky

[Ingrater]

Naja so funktioniert das nicht. Du berechnest erst die Normalen pro Fläche. Dann suchst für jedes Vertex alle Flächen in denen es Vorkommt und deren Glättungsgruppe (Smoothinggroup) die gleiche ist. Die Normalen dieser Flächen addierst du dann auf und normalisierst sie danach wieder. Dann hast du die Normale für diesen Vertex. Kommt ein Vertex in mehreren Glättungsgruppen vor musst du ihn duplizieren, da ein Vertex nicht mehere Normalen haben kann. Allein schon aus dem Grund die Normalen selber berechnen zu müssen ist 3DS ein richtiger Mist zum selber laden. Ich hab das damals auch selber gemacht. Fürs Verständnis vielleicht ganz hilfreich, im Endeffekt schmeißt du den kompletten Code dann aber weg und nimmst doch eine fertige Bibliothek.

@Krishty
Ich meine mal von jemandem gehört zu haben, dass das in DX nicht geht, aber ich glaube dir natürlich ^^

Btw: Ich hab mal einen Test gemacht Vertexbuffer vs. Display Listen. Komischerweise waren die Displaylisten um einiges schneller. Die Nvidia treiber machen mit den Daten wohl iregndwelche Optimierungsmagie und kostenloses Frustrum-Culling kriegt man auch noch oben drauf.

[Eisflamme]

Displayliste sind das, wo man bei glDrawArrays/glDrawElements als letzten Parameter nicht ne 0 sondern die Vertices übergibt? ;P

Ich weiß auch nicht. Ich hab das in meinem Fall jetzt umswitchbar gemacht. Dadurch kann man das halt als Benutzer einfach ausprobieren und gut ist.

Das mit der Normalenberechnung macht natürlich Sinn und ja, das klingt scheiße. Und ja, ich mach das auch nur zu Übungszwecken. ^^ Aber eigentlich kann ich Parsen schon, vielleicht nehme ich dann tatsächlich Assimp dafür (wobei der Name gewagt gewählt ist).

PS: Mal ne ganz doofe Frage, aber wo auf der ASSIMP-Seite kann ich mir das Gerät runterladen? Bin ich zu blöd oder ist die Seite einfach grauenhaft strukturiert?

[Aramis]

PS: Mal ne ganz doofe Frage, aber wo auf der ASSIMP-Seite kann ich mir das Gerät runterladen? Bin ich zu blöd oder ist die Seite einfach grauenhaft strukturiert?

Danke. Hier der Link auf die grauenhaft strukturierte Seite.

Developers can and should* directly obtain ASSIMP's source code via SVN. For anonymous checkout use:
$ svn co https://assimp.svn.sourceforge.net/svnroot/assimp/trunk assimp

We try to provide both source code and precompiled binary packages for most platforms.
Download page

[Eisflamme]

Das war eine Frage und keine Aussage, außerdem war ich ja offensichtlich zu blöd, was bedeutet, dass der zweite Teil der Frage getrost verneint werden kann.

Danke!

[Ingrater]

Zum Thema Display Listen: http://www.lighthouse3d.com/opengl/disp ... dex.php3?1

Sollte man aber eher nicht mehr verwenden. Für quick & dirty allerdings extrem cool ^^

[Eisflamme]

Mal unabhängig davon, dass ich den Link zum Download jetzt ja durch Dich habe... Aber wo auf assimp.sourceforge.net finde ich denn den Link dazu? Ich habe echt gesucht, aber hab den nicht gefunden.

[Aramis]

Naja, im Reiter `Downloads´, dort dann unten -- unter den ganzen SVN/Mercurial-Links. Bislang bin ich noch nicht auf die Idee gekommen dass der Link zu übersehen sein kann .. allerdings gibt es schon einen Grund dafür dass er nicht gerade auf der Startseite in Schriftgröße 32 zu finden ist: Eigentlich ist es uns lieber wenn User den aktuellen SVN-HEAD auschecken und selber kompilieren.