Na ich ging davon aus, dass er das Vermischen mehrere Texturen miteinander meint und nicht das Darstellen transparenter Objekte. Denn dann stimmt die Aussage

Nur ne kleine frage am rande... wie schaut denn das aus wenn man einfach mal nur kurz nen quad oder triangle zeichnen mag..?

Ich hab es z.B. recht häufig das in in ner Ortho-View einfach nen Quad mit ner textur zeichne, soll man sowas dann auch mit VBO machen?
Früher wurde immer noch gepredigt das VBOs sich nur für größere mengen an vertices lohnen, aber für nen simples einzelnes triangle...?

Aya~

Ob du jetzt die Vertexdaten via glVertex angibst, oder einfach ein festes Array anlegst in dem sich diese befinden dass dann via VA, VBO (oder was kommen wird) ist vom Aufwand her ja nicht wirklich viel anders. Eher im Gegenteil, ich finde sowas übersichtlicher, man hat ein Array in dem dann Texturkoordinaten und Vertexdaten direkt hintereinander stehn und übergibt es an die Grafikkarte. Weniger Tipparbeit als der direkte Modus und auch übersichtlicher. Kann man ja heute auch schon so machen, wenn mans sich jetzt also angewöhnt fällt der Umstieg leichter.

Aber nur mal so als Denkanstoß :
OpenGL 3.0 wird eine fortgeschrittene API, und wendet sich damit dann auch an fortgeschrittene Nutzer. Also zu sagen dass weglassen des direkten Modus wäre eine schlechte Idee ist wohl fehl am Platze. Mit 3.0 wird z.B. alles was in 2.1 auch via Shader lösbar ist aus der festen Pipeline wegfallen, von daher dürften Anfänger wohl kaum mit OpenGL 3.0 einsteigen.

Ich persönlich finde den Ansatz, die API mit OpenGL 3.0 fast komplett neu zu erfinden als sehr gut. Wer viel mit OpenGL macht, und v.a. Anwendungen die auf verschiedensten Konfigurationen laufen sollen wird erkennen was ich meine, denn dass ist mit der aktuellen Implemenation ein Graus. Aber es bleibt abzuwarten, 3.0 ist ja schon mehr als ein halbes Jahr überfällig.

In Sachen Treiberentwicklung sehe ich übrigens keine Probleme, die aktuellen OpenGL-Treiber der wichtigen Hersteller sind sehr ausgereift (ich entwickle auf ATI, und selbst deren Treiber ist mehr als brauchbar), und in Zukunft werden die alten Pfade für GL 1.x und 2.x halt einfach von Treiberrelease zu Release mitgeschleppt und nur noch der 3.0er Teil aktualisiert.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Richtig, das Aktivieren eines anderen VBOs braucht auch seine Zeit.
Tauscht man jedoch den gängigen Denkansatz: "Ein VBO ist eine Sammlung von Vertexinformationen eines 3D-Objekts." durch: "Ein VBO ist ein vom Grafiktreiber verwalteter Speicherblock" kann man sich überlegen nur ein einziges großes VBO zu erstellen und dort alles mögliche abzulegen. Die eigene Anwendung verwaltet dann einfach nicht mehr 10 VBOs, sondern 10 Offsets in ein VBO. Dadurch entfällt das ständige Wechseln des VBO. Da dieser Hinweis von einem Boardmitglied stammt, nehme ich an dass er völlig unbedenklich ist.
Wenn man dann noch mit glDrawRangeElements arbeitet, ist die Optimierung komplett

Hmm.... Da kommt mir glatt die Idee einen Speichermanager für den GRAM über VBOs zu schreiben. In vielen Hochsprachen (ich hoffe doch allen ) kann man sich ja ohne weiteres nen Memory Manager schreiben. Das hätte doch was: Allozier ich mir mal 32 MB VBO und den rest übernimmt nem Memory Manager...

Gruß Lord 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

Genau das ist die letztlich die Idee!
Mir fällt was lustiges ein: Wenn der Arbeitsspeicher mal voll ist kann man ja einfach Video-Speicher verwenden. Durch glMapBuffer wird der ja in den Adressraum der Anwendung gespiegelt. ^^

Hi,

das mit dem einen riesen VBO hatte ich mal vor einiger zeit ausprobiert, ich konnte da keinen geschwindigkeits vorteil feststellen..

Also ich habbe 400 kugeln á ca. 800 Triangles oder so, es hat keinen spürbaren unterschied gemacht ob ich da jetzt 400 VBOs oder nur einen einzigen hatte (wobei es bei dem einen eizigen glaub ich sogar noch irgendein ziemliches problem gab weil er zu groß wurde oder so, weiß nivhtmehr genau.. hatte ich damals aber hier auch irgendwo geschrieben)

Aya~

Wobei ich persönlich für ein riesen VBOs noch etwas anderes in den Raum werfen möchte.

Die GPU ist eine PU wie die CPU. Also ein seperater Chip. Die Treiber arbeiten teilweise, und besonders bei VBOs, asynchron! Der Aufruf zeichne mal folgendes VBO geht innerhalb von recht kurzer Zeit von statten. Aber wer sagt, dass die GPU nach dem Rückkehren der OpenGL Methode auch fertig sein muss? Niemand. Wenn man also ein VBO hat und dieses immer wieder mappen oder blockieren muss, dann bremmst man im Endeffekt sowohl CPU als auch GPU aus. Welche Kombinationen jetzt genau dazu führen, dass blockiert wird entzieht sich meiner Kenntniss und denke ich hängt auch wie immer am Treiber.

Jemand aus dem Delphi-forum hatte eine DL (im Treiber werden VBOs benutzt) die ziemlich viele primitive zeichnete. Das Zeichnen war in wenigen Millisekunden fertig. SwapBuffers direkt im Anschluss hingegen hatte ziemlich lange gebraucht.

PS:

Niemand ist perfekt! Und so etwas muss man immer im Zusammenhang sehen. Sind alle 10 Bereiche statisch mag die Aussage stimmen. Ist ein einer dynamisch kann das schon wieder anders aussehen.

Hallo,

also einerseits macht der objektorientierte Ansatz in einigen Bereichen schon Sinn, z.B. bei Texturobjekten, wo man bisher eine Objekt-Id generiert und die Eigenschaften dann mit verschiedenen Funktionsaufrufen gesetzt hat, das war bisher schon etwas aufwändig.

Andererseits fand ich den Ansatz 'OpenGL als State-Machine' auch nicht so schlecht, wenn man mal z.B. mit glColor auf die schnelle die aktuelle Farbe für die darauffolgenden Vertices setzen will, ist das schon sehr angenehm.

Wie soll das dann objektorientiert aussehen? Ist dann jedes Vertex ein Objekt, bei dem man die Farbe, die Normale und die Texturkoordinate mit angeben muss?

Das hatte mich bei Vertex-Arrays schon sehr genervt, dass man alle Daten extra angeben musste, auch wenn sich die Eigenschaften kaum verändert hatten.
Übergibt man ein Array mit 1000 Vertices, braucht man auch ein Array mit 1000 Colors oder 1000 Normalen ( oder zumindestens 1000 Indizes ).
Alles in allem also ziemlich speicherhungrig ( was die Grafikkartenhersteller sicherlich sehr freuen wird )

Viele Grüße
dj3hut1

Wie ich oben geschrieben hab wird in OpenGL 3.0 fast alles über Shader laufen, und in einem Shader kannst du die Farbe ja einfach nach Belieben z.B. anhand einer selber gestellten Kondition über Parameter oder Vertexattribute übergeben. Ausserdem benutzt man heute ja eher selten Farben, und Texturkoordinaten werden eigentlich immer übergeben. Bei nur gefärbten Objekten übergibt man in diesen dann halt die Farben bzw. auf einer anderen TMU, Speicherverbrauch steigt dadurch also entweder kaum oder nur leicht.

Wenn man GL3.0 betrachtet sollte man am besten einfach vergessen was GL1.x/2.2 können, und v.a. wie sie aufgebaut sind. Das sind dann veraltete Konzepte (u.a. die Statemachine), von denen man sich verabschieden muss.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ja ich meinte das blenden von Texturen,farben,FBO und nicht alphablending(könnte man aber mit einer kleinen erweiterung in GLSL implementieren).

Wie die Objekte aussehen werden ist noch nicht bekannt, es gibt ein kleines Beispiel, finde den link leider ned.
http://www.opengl.org/pipeline/article/vol002_3/ dort gibs noch ein paar Infos.
Im prinzip läuft das so ab.
glGenBla(1,&blaID);
glSetBlaIrgendwas(blaID,...);
glBindBla(blaID);
...
glUnbindBla(blaID);
glDestroyBla(&blaID);

Nur weil man etwas hat, muss man es nicht nutzen.

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

Projekte: https://github.com/tak2004

Hallöchen

ich muss ehrlich sagen, dass ich mich über OGL 3.0 noch nicht wirklich informiert habe, finde die Diskussion aber sehr interessant und macht irgendwie lust auf mehr.

Was mich z.B. interessieren würde:
Wie schaut es eigentlich mit den Extensions und den "Hardware-Kompatibiltät" aus? Was ich damit meine: Mit einer TNT2 und einem aktuellen Treiber gaukelt einem der Treiber ja vor, dass OpenGL 2.0 unterstützt wird wobei dann alle fehlenden Funktionen vom Treiber per Software ausgeführt werden. Wird es in OpenGL sowas wie einen Flag geben, ob eine gewissen Funktion wirklich von der Hardware unterstützt wird oder wird der Programmierer weiterhin "belogen"?

Was ich mich auch noch interessieren würde:
Sagen wir mal, ich will ein Spiel oder sonst was programmieren, dass auf OpenGL 3.0 aufbaut - zwecks Kompatibität auch einen Renderpfad für, sagen wir mal OGL 1.5, bekommen soll. Jetzt hab ich ja erstens zwei Probleme: ich müsste erst einen OGL 3.0 - Renderkontext erstellen und wenn der unterstützt würde, müsst nich noch einen OGL 1.x/2.x erstellen. Das Problem ist dabei doch, dass ich für jedes Fenster nur einmal die Funktion SetPixelFormat aufrufen kann. Dann müsst ich doch schon VOR dem erstellen wissen, ob OGL 3.0 funkionierten würde - wird sowas vorhanden sein?
Aber sagen wir mal, das macht kein Problem. Wenn ich jetzt die angesprochene Kompatibilität einbauen wollte, müsst ich doch eigentlich fast zwei unterschiedliche Engines programmieren, da, so wie es jetzt für mich aussieht, OGL 3.0 nicht mehr wirklich abwärtskompatibel ist - soll ja keine State-Machine mehr sein.

Versteh ich das richtig oder bin ich total auf dem Holzweg?

Grüße

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

Im prinzip braucht opengl 2.0 schon eine DX9 karte, da sonst die GLSL shader kaum lauffähig sind. Ansonsten ist die emulation so was von lahm, das man die render ergebisse gleich an den drucker schicken kann....

Die state maschie in OpenGL bringt gerade bei größeren projekten große nachteile, z.B. muss man sich entscheiden ob jedes objekt die default werte zurücksetzt oder ob jedes objeckt alle zustände überschreibt, die es selbst beeinfluss könnte. Es reicht schon aus wenn man einen fremden texturloader benutz der ein packodffset ändert, damit der eigene code crasht.

Der imediate mode war sinvoll, als die grafikkarten noch keine T&L bzw vertex shader und somit auch keine geometry im eigenem Speicher ablegen musste (Transformiert werden musste ja noch mit der CPU) Da war es auch sinvoll schnell zwischen Fans und Stripes hinunherschalten zu können, aber heute ist das völlig fehl am plaz, weil erst die ganzen daten wieder zusammen gepuzzelt werden müssendann in einem stück zur graka gesendet werden müssen, obwohl ein großtweil der daten im letzem frame den gleichen inhalt hatte. Ansten verursacht hie die Statemaschine auch das übliche caos, wenn man mit glColor die farbe ändert, und diese für das nächste objekt nicht zurück setzt, dann beinflussen sich wieder unabängige (selbst VBO basierende) objekte....

Zum selection modus: Der hat noch nie wirklich mit hardware unterstützung gearbeitet. Die einfachste variante ist, jedes objekt in einer anderen farbe zu rendern. Es ist deutlich schneller und vorallem funktioniert es auf allen karten, die einen 32bit framebuffer unterstutzen. Wer auch noch die anderen d.H. alle primitive auf dem Strahl fangen will, wird unter OGL3.0 mit geometryshader und streamout wesendlich besser besser beraten sein. Dieser kann dann alle primitive in den stream out buffer schreiben die man auswählt.

Das argument, das diese dinge von anfängern gebraucht werden zählt irgend wie nicht, da all diese sachen in eine bibliotek auf höhrem level ausgelagert werden können, welche dann texturen, meshes und beleuchtung übernimmt, ohne das shader code geschrieben werden muss. Das hat dann sogar den vorteil, das anfänger nicht mehr auf die beleuchtung, die mit opengl 1.0 eingeführt wurden limitiert sind.

_________________
Lumina plattform unabhängige GLSL IDE

oc2k1 schrieb:

Das ist eine gute Idee: ein Zweischichten-Modell, das man benutzen kann, aber nicht muss. Leute, die sich mehr zutrauen können dann einen Level höher gehen - oder eigentlich einen Level tiefer.

Wenn man seine Engine auf mehere Pipelines aufbaut, weil man DX,OGL,.. supporten will, dann hast ein try and error prinzip.
Stelle DX oder OpenGL in den configs ein und er sollte dann durchgehen minimum z.B. OpenGL 1.5, normales feature Set OpenGL 2.1 und dann maximale Features OpenGL 3.0(oder andersrum). Bei DX ist es genaus, siehe HL² und HDR Feature.
Da es ein neuen RenderContext für OpenGL 3.0 geben soll, musst du also ein OGL<3 Context erstellen und die Version abfragen und dann ein OpenGL3 Context erstellen und gucken ob er ihn erstellen kann(eventuell noch extensions,arbs prüfen).
DX hat meines Wissens für alle Versionen einen eigenen Context und nur die Subversion werden im Context unterschieden.

Mehere Pipelines hat man in der Regel bei Projekten, die über Pong hinaus gehen.
Deswegen sollte man sich viel Zeit nehmen, wenn man die Contextklasse für das Framework konzipiert.
Da man weiss, was man braucht z.B. Shader, Meshes, Materials kann man die abstrakte Context Klasse einfach definieren und sehr einfach weitere Pipelines hinzufügen.

Die Manager sind keine abstrakten Klassen, sondern implementieren schon einige grundfunktionalitäten, wie Hashlisten verwalten und nur das erstellen und Löschen von Contextbezogenen Sachen wird noch über ableiten neuer Klassen hinzugefügt.
Basisklassen wie CMesh,CMaterial,CShader,CScissor,CViewport sind ebenfalls so, gemeinsame funktionalität ist drin und Contextbezogene wird durch ableiten neuer Klassen ermöglicht.
Wenn du z.B. schon ein OpenGL 1.5 Pipeline drin hast und für die 2.1 Pipeline die GLSL implementierung ändern willst, dann leitest du von CContextOGL15 CContextOGL21 ab, von CShaderManagerOGL15 CShaderManagerOGL21 ab und von CShaderOGL15 CShaderOGL21 ab.
In CContextOGL21 änderst du ledeglich in Generate den Klassennanem von CShaderManagerOGL15 auf CShaderManager21 um und in CShaderManager21 änderst du in generate CShaderOGL15 auf CShaderOGL21 um. Die wirkliche arbeit ist dann CShaderOGL21, wo du nun auf die neue GLSL implementierung umstellst.
Am Spielcode oder restlichen Framework änderst du garnichts, da die dank überladung mit den basisklassen von CShader,CMaterial,CMesh und so weiter arbeiten. Eine Globale Liste, statische Liste in CContext oder Singleton mit Liste in der namen und Contextgenerator Methode hinterlegt sind sollte noch rein.

Ein bischen Konfus aber ich denke man versteht, das Prinzip schon. Basisklasse für Context und die Contextabhängigen Manager sowie Context abhängigen Ressourcen. Durch ableiten kann man dann weitere Renderer implementieren und ne menge Zeit sparen, da man im Framework nur mit den Basisklassen arbeitet und damit unberührt von anderen RenderContexten bleibt.
Momentan bemühe ich mich z.B. um eine PS3, um OpenML in Karmarama als Context zu implementieren und um ein BeagleBoard, um OpenGL ES zu implementieren.

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

Projekte: https://github.com/tak2004