Ich stehe im Moment vor dem Problem, Meshs und DrawCalls so zu repräsentiern, das verschiedene OpenGL Versionen damit arbeiten können.

Eine Möglichkeit wäre ein Mesh-Interface, welches pro OpenGL Version in der sich wichtiges geändert hat neu implementiert würde.

Bei DrawCalls fehlt mir Momentan die Vorstellung wie man das performant Lösen könnte.

Ideen, Pseudo-Code, Whitepaper, Irgendwelche bestehenden Implementierungen, eigentlich fast alles zum Thema würde mir weiterhelfen.

mfg FrenK

Halte die daten einfach wie in einem VBO. Wenn keine VBOs existieren, dann lädst du die Daten nicht auf die Grafikkarte hoch und renderst mit Vertex Arrays. Wenn die auch nicht existieren loopst du halt in Software über das Array und benutzt den Immediate Mode. Analog geht das auch mit Index Arrays.

grüße

_________________
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

Ich hätte villeicht erwähnen sollen, dass ich nur GL 4.x+ core verwende.

Die Probelatik ist folgende z.B nach dem Schema wie VAOs hinzugekommen sind ist nicht klar inwiefern weitere "Container-Konstrukte" hinzukommen, oder entsprechen wegfallen macht es also Sinn.
Eine Schicht zwischen Mesh und OpenGL Wrapper Klassen zu ziehen oder aber einen OGL420Mesh, OGL430Mesh die alle IMesh implementieren zu bauen.

Wenn ich das irgendwie geordnet bekäme bliebe noch das Problem mit den DrawCalls und ich könnte mich endlich dem Renderer zuwenden.

mfg FrenK

Erst hatte ich nen VBO, dann ne Mesh Klasse, welche verschiedene VBO unter ID's ablegen konnte.
Nun bin ich davon ganz weg, ich benutzte nun meine OpenGL Machine(OpenGL just in time interpreter), was für dein Bedarf wohl overdose wäre.

An deiner Stelle würde ich ein Collector bauen, welcher auf ein Abstraktes Interface sammelt und arbeitet, wie OnRegister, OnUnregister, OnExecute und Add, Remove, Execute.
Davon kannst du dann Buffer ableiten und in den Collector packen.
Der Collector wird dann für spezifische Implementierungen wie Model, Animated Model, Map abgeleitet.
Der Highlevel Code(Collector) weiß wie die Daten ausehen und verwenden muss und die Daten sollten möglichst nur, OGL object ID generieren, daten zuweisen, vernichten und binden beherschen.
Add kann die ogl object id generieren und die daten zuweisen, Remove freigeben und Execute das bind ausführen. Man kann bei Shader Objekten z.B. Uniforms setzten, also wäre ein Update sinnig.
Irgendwo sollten die Daten auch übergeben werden können und du willst ja nicht für verschiedene anzahl von Parametern und co neue Funktionen ins Interface bringen also wäre ein Öffentliches Register praktisch.
Eines wo du ein Key-Value Pair(Parameters) hinterlegst und wenn nicht anders möglich(z.B. C/C++ ohne RTTI) darauf vertraust dass der Highlevel Code kein scheiß baut und dieses wird vom Highlevel Code verwaltet.
Dann kann Update alle Registereinträge schreiben.
Es gibt natürlich auch Fälle, wo Daten zurück kommen, also wäre auch der andere Weg toll.
Ein Results Register müsste also auch her, welches nur lesbar ist und vom objekt verwaltet wird.

Da eine Gretsche zwischen Performant und generisch hin zu bekommen einfach unglaubwürdig ist.
Ich hab mich mehr für die Performance entschieden gehabt und ein abgeschächtes Konzept von gerade beschrieben benutzt.
Mein Framework ist ein Entwickler Framework und daher kann ich mich da nicht auf bestimmte API's festlegen.
Daher bin ich nun weg von OpenGL spezifischen Klassen(Shader, VBO, FBO) die ich für jede OGL Version pflegen musste. Sollte dein Ziel ein ähnliches sein, dann würde ich allerdings doch über mein aktuellen Ansatzt mit der OpenGL Machine( http://www.delphigl.com/forum/viewtopic.php?p=92183#p92183 ) nachdenken.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004