Hallo,

Wie würdet ihr denn per modern opengl eine große Anzahl von Dreiecken zeichnen?

Es sollten 1 mio bis 10 mio (oder gar mehr) Dreiecke auch auf einfachen (auch integrierten Graphikkarten) darstellbar sein. Textures brauch ich zum Glück nicht.
Ich brauch dabei vertex normalen und eine farbe pro triangle (kann man das mit dem color per facet in modern opengl irgendwie speichereffizient hintricksen, da ja alles vertex Attribute sind und es so viel mehr Speicher kostet?) Hinzu kommt, dass ich aus diversen gründen die die vertexe nur per Position und vertex normal als unique speichere ( also ohne Berücksichtigung der Farben). Somit funktioniert ein vertex index nicht mehr, wenn verschiedene Farben ins Spiel kommen. Und wenn ich 3 vertexe pro Triangle hochlade, ist schnell ne menge Speicher weg – und den gibts auf einfachen. Graphikkarten auch nicht so massiv.

Wenn ich per VBA arbeite kommt da sehr schnell ne menge OPenGLspeicher zusammen – ich denk bei 10 mio triangles und jeweils 3 vertexe schon zu viel für einfache Graphikkarten. Dort wird ja auch alles als float gespeichert. Ich kann also nicht mal uByte typen verwenden, beim hochladen wird daraus ja auch float.

Was würdet ihr da machen?

Grüße
User69

Raumunterteilungstechnologien und entfernungsabhängiges Level-Of-Detail sowie Culling, welches schon auf der CPU durchgeführt wird, können hier helfen.

Dann würde ich die VBOs noch unterteilen in chunks von z.B. 50k oder 5k triangles (da wirst du anhand des Tradeoffs "Anzahl Drawcalls" vs. "Flexibilität" entscheiden müssen) aufteilen, sodass du nicht immer das große VBO anfassen musst, wenn du irgendwo etwas an der Geometrie ändern musst (wegen LOD oder Farbänderungen).

Ich habe aber noch ein paar Fragen:

• Was für Geometrie ist das? Hund, Haus, Katze, Wald, Planet, Abstrakte Kunst?
• Wie interagiert der User mit dem Mesh?
• Welche Änderungen werden zur Laufzeit an dem Mesh vorgenommen?
• Ist das Mesh zusammenhängend?

viele Grüße,
Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

- es handelt sich um technische Objekte oder auch scans, wie sie bei 3D Drucken verwendet werden. Diese könne leider recht groß werden.

- das mesh ist zusammenhängend (ich kenne die Verbindungen)

- der user kann Farben ändern, Objekte löschen und hinzuladen, Objekte in der Position transformieren

- noch ein info: es muss nicht unbedingt mit 25fps laufen, ein rucklen oder auch fps von ca. 5 bei großen meshs, wäre erlaubt.

Das vorgschlagene prozessing auf der CPU erscheint mir recht kompliziert und das würde ich lieber umgehen. Die Unterteilung in chunks kann Vorteile bei Änderungen bringen, aber bei Änderungen wäre die Uploadzeit nicht mal das Kritische.

Ich habe vor allem Angst vor Speicherproblemen insbesondere auf OpenGl Seite, das macht mir die größten Sorgen.

BTW: mit altem glBegin glEnd geht das eigentlich ganz gut (natürlich mit Performanceproblemen bei einigen mio Triangles) da gibts keine Speicherprobleme. Aber das wollt ich ja nicht nutzen und es gleichzeitig beschleunigen.

Vielen Dank schon mal
user69

Hallo,

die Anzahl der Vertices lässt sich mit Triangle Strips schon mal fast auf ein Drittel reduzieren.

Ansonsten würde ich über ein gutes Verfahren zur Dreiecksdezimierung nachdenken, ich vermute mal, dass sich viele der Dreiecke auf ein und derselben Ebene befinden und sich gut zusammenfassen lassen. Blender verfügt über einen guten Dezimierer. Du könntest versuchen, das Model dort reinzuladen (es gibt Importer für .obj und .stl), zu dezimieren und dann wieder zu exportieren.

Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Du kannst die Normalen und Farben auch als "half float" (https://www.opengl.org/wiki/Small_Float ... alf_floats) speichern. Dadurch würdest du entsprechend die Hälfte an Speicherplatz für Normalen und Farben spaaren.

Das ergäbe dann für 10mio naiv gespeicherte dreiecke bei 3 components pro attribute (position, normal, color):
floats: 3 * 10.000.000 * (3 + 3 + 3) * 4 = 1.080.000.000B ~ 1GB
half floats: 3 * 10.000.000 * 3 * 4 + (3 + 3) * 2 = 720.000.000B ~ 700MB

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

5 oder 25 frames pro Sekunde ist ja kein wirklich wesentlicher Unterschied(nur Faktor 5), für Physiker fällt das sogar in dieselbe Größenordnung ^^

Benutzt du Lichtquellen?
Benutzt du flat shading oder smooth shading?
Bei flat shading würde ich die unveränderte Flächennormale verwenden, wobei dann aber bei "Rundungen" in einer Oberfläche die Dreieckskanten bei ganz genauem Hingucken sichtbar sind(1 Normale pro Dreieck).
Bei smooth shading kannst du den Vektoren die normalisierte Summe der Oberflächennormalen der 6 angrenzenden Dreiecke zuordnen(Normale pro 2 Dreicke). Der Farbverlauf zwischen zwei Dreiecken wird allgemein abgerundet; dabei sieht alles optisch etwas abgerundeter aus, allerdings sind die Farbverläufe an scharfen Kanten auch abgerundet. Willst du eckige Rundungen oder weiche Kanten? Muss man zwischen zwei Übeln wählen...

Je nachdem wofür es eingesetzt wird würde ich was anderes nehmen. Primär hängt das Aussehen der Rundungen und Kanten von obigem ab, die Wahl der Zeichenmethode(VBOs, ArrayLists, DisplayLists usw) kommt danach.
Da es dir eher auf Grafikkarten-Speicherplatz ankommt und die Rechenperformance sekundär ist, würde ich es mal mit Smooth Shading probieren und dafür dann die Anzahl der Polygone vierteln.
Smooth Shading berechnet die Pixelfarben zwischen zwei Vektoren. Das ist rechenintensiver, spart aber Speicherplatz.

->Die Frage ist, ob du die Farben zwischen Vektoren gemittelt berechnen lassen möchtest oder diese über Extravektoren angeben möchtest. Ist ein Trade-Off zwischen Speicher und Rechenbedarf.
Bei halbierter horizontaler und vertikaler Auflösung viertelt sich dann eben dein Speicherbedarf. Wenn deine Grafikkarte rechentechnisch nicht ausgelastet ist, nimm lieber diese Methode.

TriagleStrips:
Die sind super um das Ganze zu beschleunigen und sparen allgemein auch in der Anzahl der Vetexe. Leider aber nicht immer - wenn z.B. Viele Farben da sind schräkt das die Strips stark ein, da ich ja nur eine Farbe per Strip nutzen kann (ColorPerFacet brauch ich - verwaschene farben helfen mir nicht). Teils ist sogar zeichen ohne Strips besser (aber das ist durchaus selten). Externe Dezimierung ist keine Option.

HalfFloat:
Das hilft im Grafikkartenspeicher garnicht, da beim upload alles zu float konvertiert wird.
Ich denk da aber in deine Richtung: glVertexAttribIPointer wäre eine Lösung die Farbe und vertex Nomalen per einem gepackten integer zu übergeben. Das spart memory, geht aber zu lasten der Performance, da diese Integer immer im Shader dekodiert werden müssen. Wie viel Performance das kostet weiß ich noch nicht. Das gilt es noch herauszufinden.

Smooth Shading:
Ich nutze nur ambient, diffuse und specular Licht. Dann nutze ich noch die Vertex nomalen (z.B berechnet aus den angrenzenden Dreiecken) um ein smoothes Aussehen zu bekommen. Also eher wenig Kanten. Ein verwaschen der Farben ist nicht erlaubt - die müssen per Facet sein.
Sparen würde, wenn ich nur eine Farbe pro Facet hochladen könnte, aber da habe ich per VBA keine idee, wie das gehen sollte.
Wie könnt ich denn mit Smooth schading Speicher sparen? Das erschließt sich mir nicht ganz. Kannst du das noch mal detaillieren?
DisplayLists sind ja auch nur altes OpenGl, was ich ja nicht verweden wollte.
Oder wäre das alte OpenGl hiefür doch zu bevorzugen?

grüße
User69

Also zwei Sachen... zum Einen geht es dir doch um Speicheroptimierungen. Und dort SIND Triangle Strips vorteilhaft, wenn du nicht gerade nur einzelne Dreiecke im Raum zeichnen willst. In der Regel sollten sie auch schneller sein, weil Bandbreite die größte praktische Limitierung darstellt.
Dein Argument mit den Farben ist leider auch nicht zutreffend. Mit Flat Shading, was du vermutlich mit dem Begriff "ColorPerFacet" meinst, kannst du sogar jedem Dreieck eine eigene Farbe geben. Ein Dreieck wird mit Flat Shading mit der Farbe seines ersten Vertices eingefärbt. Da im Triangle Strip, jedes Dreieck mit einem anderen Vertex beginnt, lässt sich jedem Dreieck eine eigene Farbe zuweisen.
In der Praxis sind außerdem bei interpolierten Farbwerten sehr häufig anzutreffen, dass angrenzende Dreiecke die gleiche Farbe besitzen. Somit besteht auch mit Triangle Strips die Möglichkeit der Reduktion der Datenmenge.
Mehrere Strips lassen sich mit dem Primitive Restart Index bilden, wenn du einen Indexbuffer verwendest. Mit einem einzellnen Strip kommt man fast nie aus. Aber fast immer kann man einige Polygone zusammenschließen.


Das stimmt aber gar nicht. Schon allein durch das Design von VBOs wäre das für den Treiber nahezu unmöglich transparent zum Nutzer zu erledigen. Buffer-Objekte sind im Prinzip ja bloß Speicherbereiche auf der GPU die beliebige Daten (zu nahezu) beliebigen Zweck enthalten können. Er kann dort nicht so einfach selbstständig umkonvertieren, weil für ihm im Buffer nur Bytes sind. Irgendwelche Bytes. Welchen Daten(und Datentypen wie zb. Half Floats) dort drin steht, bekommt er erst beim Rendern über das VAO mit.
Wenn es die Anwendung anbietet, wäre es in der Tat besser Integer als Positionen zu verwenden. Möglicherweise lässt sich die Datenmenge in mehrere Blöcke aufteilen, die jeweils nur einen bestimmten Bereich umspannen und somit mit kleineren Integerwerten auskommen.
Performance sollte das beides nicht kosten sondern eher bringen: Durch die reduzierte Bandbreite. Das größte Problem ist normalerweise der Datentransfer. Kleinere Datentypen sind damit auch zur Geschwindigkeitsoptimierung beliebt.


Nein.
Ernsthaft, gerade wenn du genaue Kontrolle über Speicherverbrauch und Leistung haben willst, ist modernes OpenGL mit VBOs und Shadern wesentlich transparenter und flexibler.

Wenn du zur Laufzeit Lichtberechnungen machst, wäre eine Kompression der Oberflächennormalen auf jeden Fall eine gute Idee. Es gibt verschiedene Ideen, die speziell hier besonders optimieren wollen. 16Bit für den gesamten Normalvektor ist auf jeden Fall möglich.

DatenTypen in VBO:
Ok, du hast da wohl recht, die Konvertierung kommt dann wohl erst, bevor die Daten in dem shader übergeben werden. Ich dachte, OpenGL konvertiert das schon beim upload.
Siehe OpenGl programming guide:
Note that while integer types such as GL_SHORT or GL_UNSIGNED_INT can be passed to the type argument, this tells OpenGL only what data type is stored in memory in the buffer object. OpenGL will convert this data to floating point in order to load it into floating-point vertex attributes.

Flat Shading:
Ich benötige schon Gourand Shading. Aber die Farben sollen nicht interpoliert werden. Wie kann das in einem strip gemacht werden, wenn z.b triangle n-2 und n-1 (z.b. grün) eine andere Farbe haben, als triangle n (z.b. rot). Das facet soll jetzt rot sein und nicht von grün nach rot blenden. Aber es soll smooth erscheinen (per vertex normals).

user69

Mit Shadern ist die Interpolation eigentlich eine ganz einfache Sache.
Wenn du Farben nicht interpolieren willst, gibst einfach "flat" an. Wenn du Lichteffekteinterpolieren willst, gibst du bei diesem dort "smooth" an.
https://www.opengl.org/wiki/Type_Qualifier_(GLSL)#Interpolation_qualifiers

Wahrscheinlich wäre es aber auch vorteilhaft, die Lichtberechnungen im Fragment Shader durchzuführen. Das führt zu besseren Ergebnissen bei Spiegelungen(Specular) und ist gar nicht so teuer wie man denken könnte.

Man könnte es auch so sehen, wenn du 10 Millionen Polygone rendern willst, hast du wahrscheinlich viel mehr Vertices als Fragmente.

Exakt. Wenn man mal von einer HD Auflösung ausgeht....1920x1080=2073600 Pixel, merkt man schon, dass bei dem Versuch 10 Mio Dreiecke zu zeichnen irgendwas falsch läuft....

Bzgl. Triangle_strips: Wenn man hart von grün nach rot wechseln will, könnte man auch an der Stelle 2 zusätzliche Dreiecke zeichnen deren Position der letzten beiden Dreiecke entspricht, und nur die Farbe wechseln. Könnte aber im schlimmsten Fall für 20 Mio Dreiecke sorgen

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Nun, das hängt halt direkt zusammen. Wenn du Technologien auf der CPU verwendest, um Geometrie zu vereinfachen (wie andere auch schon vorgeschlagen haben), dann musst du Chunks verändern. Damit sparst du potentiell sehr viel Speicher auf der Grafikkarte ein. Eine Raumunterteilungstechnologie hilft dir, schnell herauszufinden, wie weit ein Block vom Betrachter weg ist und daran kann man dann entscheiden, welche Detailversion davon auf die GPU muss. Die kann man vorberechnen oder on-demand bereitstellen und in einer art LRU-Cache halten. Natürlich sollte nur die jeweils benutzte Geometrie auf der GPU liegen.

viele Grüße,
Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Wenn ich das richtig sehe, ist das nicht ein Objekt mit 10 Millionen Dreiecken, sondern es sind mehrere Objekte, bei denen sich die Dreieckszahl dann summiert. Man könnte es ja auch so verwalten, dass man nur das zu bearbeitende Objekt in vollem Umfang in den Grafikspeicher lädt, während man die anderen ausblendet oder eine Low-Poly-Version anzeigt.

Du musst auf jeden Fall mit Einschränkungen rechnen, denn der Speicher von integrierten Grafikchips ist wirklich sehr beschränkt und für solche Anforderungen nicht ausgelegt.

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Vielen Dank für eure Hilfen. Da waren schon viele hilfestellungen und Anregungen drin.

Leider ist mein Einfulss auf die Datenmenge aber begrenzt. Die werden beim Endanwender individuell geladen. Es handelt sich leider nicht um eine Spieleengine.
Natütlich wäre LOD ein Weg, jedoch bedarf der einiger Vorarbeit. Ich habe noch keine LOD engine und muss dann auch das Programm dafür umstellen.

Ich werde aber mal aus euren Anregungen einige Speedtest machen, um zu sehen, was so geht.

Ein paar Antworten würden mir aber noch helfen:
1. Wenn ich die Daten in chunks unterteile, was wäre dann eine gute Größe um das VBO optimal zu bedienen und auch nicht so leicht in Speicherprobleme mit großen Blöcken beim OpenGl upload zu geraten? Ich dacht so an 65.000 also unter 16 bit integer um auch im ElementArray nur 2 bytes zu nutzen.
2. Wäre es speedtechnisch vertretbar (also zumindest so schnell, wie GlBegin), wenn ich jedes Frame die Daten hochlade, zeichne und wieder freigebe?
3. Ist derzeit schon abzusehen, dass in absehbarer Zukunft die depricated Funktionen aus den OpenGL Treibern entfert werden?
4. Wäre es aus OpenGL speicher Sicht nicht evtl. doch sinvoll ab z.B. 2 mio Triangles auf das alte OpenGL zurückzufallen? Da habe ich solche Speicherprobleme ja nicht. (Ich weiß, das zumindest einmal mir davon abegeraten wurde, aber ich sehe im alten OpenGL duchaus Speichervorteile.)
5. Kann man mit modern OpenGl irgendwie zumindest den speed des alten glBegin erreichen, ohne für x mio triangles massiv speicher zu gebrauchen? Der Treiber tuts ja auch wenn ich im depricated glBegin zeichne (ok, ich nehme an der Vergleich hinkt etwas, da der Treiber mehr Möglichkeiten hat. Aber vielleicht gibts doch Ideen).

Grüße
user69

NeinNeinNeinNeinNeinNeinNein.

Da kannst du gleich bei glBegin bleiben. Du erstellst einmal das VBO, füllst es einmal und veränderst dann nur die Teile, die verändert werden müssen. Freigeben tust du so spät wie möglich, weil die Mem Allocation das ist, was sehr viel Speed kostet.



Das wäre sinnlos. Wenn du einmal VBOs einbaust, bleib auch dabei. Sie sind nämlich schneller.


Es gibt Vertex Arrays, mit denen du schneller rendern kannst. Wenn dir *wirklich* so viel Speicher auf der Grafikkarte fehlt, dann render halt mit Vertex Arrays.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)