spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ach naja, Erfahrung ist nicht immer nur was positives. Tunnelblick und so

Na, man kann zum Beispiel vor dem Rendern alles nach Materialien sortieren, muss dann ein Material (inlusiv Textur) nur einmal setzen und kann dann alle Objekte die dieses Material benutzen hintereinander weg zeichnen.
Insgesamt ist Performance bei 3D Anwendungen ein sehr schweres Thema, es gibt sehr viele Faktoren, und vieles was vor ein paar Jahren als allgemeine Richtlinie galt, gilt heute schon längst nicht mehr.
Auf jeden Fall ist es falsch zu sagen "glGet ist das schlimmste was es gibt, das darf ich nie benutzen", oder ähnliches. Viele Richtlinien vereinfachen komplizierte Regeln, wenn man sie aber stur und ohne Verstand anwendet, schaden sie mehr, als sie bringen.

Ein 'Wrapper' für OpenGL ist zum Beispiel OpenSceneGraph, womit ich mich zufällig momentan beschäftige. Das löst das mit dem States und Texturen setzen recht elegant (wie ich finde), aber es ist natürlich auch ein riesiges Framework. Dort kann man ein State für ein Node setzen, er wird dann aktiviert, alle Objekte gezeichnet und dann deaktiviert, wodurch man also definiert "Dieser State gilt für diesen Node und alle Child Nodes".

Vor allem ist ein Scenegraph vielleicht für einige Aspekte des Scenemanagement von Vorteil, für andere dafür aber sehr ineffizient (Ständiges Traversieren von tiefen Baumstrukturen ist nicht gerade der Burner wenns um Performance geht). Für RAD sind solche Systeme vielleicht sehr angenehm, in ernsthaften Engines kommen aber wenn überhaupt, dann nur sehr flache Szenengraphen zum Einsatz. Schon rein prinzipiell kann es nicht die eine Datenstruktur geben, die sämtliche Probleme löst. Je nach Problem wird man auf verschiedenste Strukturen zurückgreifen. Schon in der Quake-Engine gabs verschiedenste Renderqueues, BSP Trees, PVS, ...

Ganz unabhängig davon, wie schnell glGet*() nun ist, ist der Einsatz wie im Anfangspost auf jeden Fall völliger Overkill.

Um ehrlich zu sein, hab ich das noch nie profiled. Wenn man bedenkt, dass die ganzen Bind Calls beträchtlichen Overhead erzeugen können, mag es durchaus sein, dass du, im Vergleich zu ständigen Binden, damit was sparen könntest. Der Punkt ist aber: Es gibt überhaupt keinen Grund dafür, ständig zu binden. Es ist dein Code, also muss dir rein theoretisch eigentlich schon zur Compiletime bekannt sein, wann es was zu binden gibt. Daher besser einfach von Haus aus nur binden wenn nötig, anstatt irgendwelche Laufzeitmechanismen zu bauen, die das für dich entscheiden. Die Tatsache dass du ständig binden willst, ist doch nur ein Symptom davon, dass das OpenGL Objektmodell einfach nicht gut auf herkömmliche OOP Konstrukte mapped. Anstatt OpenGL in ein OO Korsett zu zwingen und die Symptome zu bekämpfen, wäre es imo besser, OpenGL einfach OpenGL sein zu lassen. Die API hat eben ihre Schwächen und für OOP ist es auf dieser Ebene evtl. sowieso zu früh.

Zitat von »Architekt«

Benutzt ich jedoch eine Wrapper Klasse für solche OpenGL Konstrukte kann ich das natürlich nicht in feste Muster zwingen und brauch irgendwie eine Art und Weise damit umzugehen. Ich dachte ja auch schon an einen eigenen StateTracker

Genau darum gehts ja. Du bräuchtest das alles ausschließlich nur damit dein Wrapper funktioniert. Imo ein ziemlich deutliches Zeichen dafür, dass ein solcher Wrapper nicht die ideale Lösung ist.