Index-Buffer in OpenGL
-
Hallo,
ich fange grad an OGL zu lernen und hätt da eine frage.
gibts in ogl einen index-array/buffer wie in DX ? irgendwie bin ich grad extrem verwirt, IndexPointer() ist ja kein index-array sondern ein color-index-array ...
ich find auch nix über sowas wie index-buffer in den ogl docus.
-
Vertex/Index-Bufferfunktionalität wird in OpenGL durch die GL_ARB_vertex_buffer_object-Extension ermöglicht.
Google einfachmal, dazu gibts ne Menge Tutorials.Die oldschool Variante (Quake3) sind compiled Vertexarrays
(normale Vertexarrays mit GL_EXT_compiled_vertex_array kombiniert) oder DisplayLists.Zu deiner Frage, es gibt unter OpenGL keine Vertex/Indexbuffer.
Den Indexarray übergibst du einfach glDrawElements oder glDrawRangeElements.
-
laut der opengl 2.0 spec gibts "Vertex Arrays in Buffer Objects"
btw, um nicht unnötig einen neuen thread zu erstellen:
wo bekomm ich ogl 2.0 für windows ?
ich hoffe einfach mal das ich alles falsch verstanden habe und es gibt doch irgendwo 2.0 ogl für windofs.
man braucht doch nur die neuen header dateien und die libs werden doch durch die graka-hersteller verteilt, richtig?
-
DEvent schrieb:
laut der opengl 2.0 spec gibts "Vertex Arrays in Buffer Objects"
btw, um nicht unnötig einen neuen thread zu erstellen:
wo bekomm ich ogl 2.0 für windows ?
ich hoffe einfach mal das ich alles falsch verstanden habe und es gibt doch irgendwo 2.0 ogl für windofs.
man braucht doch nur die neuen header dateien und die libs werden doch durch die graka-hersteller verteilt, richtig?Ich bin in Sachen OGL eher in der Unix-Welt zuhause und dort wirds noch ne ganze Weile dauern bis 2.0-Treiber kommen. Ich denk, das ist bei Windows nicht wesentlich anders.
OpenGL ist nur die Spezifikation, und 2.0 ist noch ziemlich neu. Nun liegts an der Treiberherstellern da was draus zu machen..
-
naja ich progge ja immernoch mit opengl 1.1 rum
und übrigens muss ich eins sagen, OpenGL ist toll
-
DEvent schrieb:
und übrigens muss ich eins sagen, OpenGL ist toll
-
Naja die OpenGL-Version ist eigentlich ziemlich nichtssagend, anders als bei DirectX.
Der wirklich coole Kram läuft ja meistens über Extensions
-
Kane schrieb:
Naja die OpenGL-Version ist eigentlich ziemlich nichtssagend, anders als bei DirectX.
Dann solltest du vllt mal nachschauen wie das mit den Extensions funktioniert
-
Lol?
Extensions sind von der OpenGL-Version unabhängig!
Die normale Zyklus für ein OpenGL-Feature sieht so aus:
1. proprietäre Extension GL_NV_ / GL_ATI_ etc
2. "allgemeine" Extension: GL_EXT_ / GL_ARB_
3. wenn sich das Feature bewährt wird es vom ARB in den OpenGL-Core
aufgenommen.Die OpenGL-Version bestimmt nur welche Core-Features vorhanden sind,
das ist aber relativ unbedeutend da das Feature immernoch über die Extension
angesprochen werden kann und man somit nur prüfen muß ob die gewünschten Extensions unterstützt werden.Die einzige Extension <-> Version Abhängigkeit bezieht sich darauf dass
einige Extensions bestimmte Features einer OpenGL-Version voraussetzen.
Das wars dann aber auch schon.Ein OpenGL 1.3/4 kann ohne Probleme GLSL unterstützen obwohl es sich dabei um
ein OpenGL 2.0 (Core-)Feature handelt.
-
Kane schrieb:
2. "allgemeine" Extension: GL_EXT_ / GL_ARB_
Kennst du den Unterschied zwischen EXT und ARB ? Nein ? Hab ich gemerkt.
Kane schrieb:
die OpenGL-Version bestimmt nur welche Core-Features vorhanden sind
Kane schrieb:
Naja die OpenGL-Version ist eigentlich ziemlich nichtssagend
Sehr wiedersprüchlich
Kane schrieb:
Lol?
Extensions sind von der OpenGL-Version unabhängig!Jup, deine Aussage ist sehr witzig. Gut, dass es darum ging, ob die GL Version Aussagen über die Extenions macht. Aber das hast du ja oben erläutert und mir somit nur Recht gegeben.
-
Sehr wiedersprüchlich
Stimmt wenn man nicht richtig lesen kann:
das ist aber relativ unbedeutend da das Feature immernoch über die Extension angesprochen werden kann und man somit nur prüfen muß ob die gewünschten Extensions unterstützt werden.
-
Schade dass du es immernoch nicht verstanden hast. Naja, kommt Zeit kommt vllt auch bei dri Rat.
das ist aber relativ unbedeutend da das Feature immernoch über die Extension angesprochen werden kann und man somit nur prüfen muß ob die gewünschten Extensions unterstützt werden.
Wie schon erwähnt geht es nicht darum, ob die Extensions Aussagen über die Version machen sondern ob die Version Aussagen über die Extensions macht. Beeindruckend wie du versuchst deine Unwissenheit durch ein witziges Verdrehen deiner eigenen Aussagen zu verschleiern.
-
Kennst du den Unterschied zwischen EXT und ARB ? Nein ? Hab ich gemerkt.
Ich kenne sehr wohl den Unterschied zwischen EXT und ARB, allerdings zweifle ich daran dass du dass richtig verstanden hast.
ob die Extensions Aussagen über die Version machen sondern ob die Version Aussagen über die Extensions macht.
Du bist wirklich lustig
So schwer ist dass doch gar nicht.
Versuchen wir es mal mit einem Beispiel:
Mal angenommen du willst eine state-of-the-art 3D-Programm schreiben.
Schauen wir uns mal an was du bräuchtest:
GL_ARB_vertex_buffer_object (Vertex/Index-Buffer)
GL_EXT_framebuffer_object (Offscreenrendering, leider noch nicht released. Wird aber anscheinend bald)
GL_ARB_(alle GLSL extensions) (GLSlang)Ok gehen wir mal durch welche Features du an der GL-Version bestimmen könntest.
Der aktuelle NV-Treiber ist bei 1.5.2 (66.29, Linux).
Also ist GL_ARB_vertex_buffer_object im Core, toll.
GLSL aber erst ab GL 2.0... so einen Treiber haben wir aber nicht.
Von framebuffer_object will ich jetzt mal gar nicht anfangen.Hmmm, haben wir jetzt mit Hilfe der Version hinreichend die Features bestimmen können? Ich denke nicht.
Bestimmen die Extensions denn die Version?
Nicht zwingend. Meine Karte unterstützt alle GL2.0 Featues, über Extensions.
Wie aber oben zu lesen ist, hängt der Treiber aber noch bei 1.5.Was lernen wir daraus?
Über die Version einer OpenGL-Implementierung läßt sich keine ausreichende Aussage über die unterstützten Features treffen womit sie beim Implementieren eines Programms unbedeutend wird.q.e.d.
-
Kane schrieb:
Ich kenne sehr wohl den Unterschied zwischen EXT und ARB, allerdings zweifle ich daran dass du dass richtig verstanden hast.
Wie kommt es dann, dass du beide auf eine Stufe stellst ? Haben doch beide so gar nichts miteinander zu tun.
Kane schrieb:
So schwer ist dass doch gar nicht.
Scheinbar schwer genug, damit du es nicht verstehst.
Kane schrieb:
Ok gehen wir mal durch welche Features du an der GL-Version bestimmen könntest.
Der aktuelle NV-Treiber ist bei 1.5.2 (66.29, Linux).
Also ist GL_ARB_vertex_buffer_object im Core, toll.
GLSL aber erst ab GL 2.0... so einen Treiber haben wir aber nicht.
Von framebuffer_object will ich jetzt mal gar nicht anfangen.
Hmmm, haben wir jetzt mit Hilfe der Version hinreichend die Features bestimmen können? Ich denke nicht.Doch. Du weißt, dass du mit entsprechender GL Version auch entsprechende Extensions hast. Du kannst eben nicht davon ausgehen, dass ne Karte mit GL Version 1.5 GLSL fähig ist. Sehr wohl kannst du aber davon ausgehen, dass alle 1.5 Features da sind. Und NUR darum ging es. Die GL Version macht eine Aussage über die vorhanden Core Features und ist damit in keinster Weise nichtssagend.
Kane schrieb:
Nicht zwingend. Meine Karte unterstützt alle GL2.0 Featues, über Extensions.
Wie aber oben zu lesen ist, hängt der Treiber aber noch bei 1.5.Das tut meine Karte auch. Dummerweise hängt der Treiber aber auch bei einer GF2 bei 1.5. Wo ist da der GLSL Support ? Nirgends. Der Treiber sagt hier lediglich aus, dass die 1.5er Core Features vorhanden sind. Er sagt also aus was machbar ist und was nicht.
Kane schrieb:
Was lernen wir daraus?
Dass die Version entsprechende Aussage über dei vorhanden Core Features macht und du dennoch nicht vorhersagen kannst, welche zusätzlichen Extensions da sind. Du weißt lediglich, dass bei einer Version von 1.5 die spezifischen Extensions dafür vorhanden sind. Das bringt bei der Enticklung eines Programmes aber 0 Punkte, da nicht alle Karten die 1.5 unterstützen auch zwangsläufig 2.0 unterstützen werden.
womit sie beim Implementieren eines Programms unbedeutend wird.
Du schreibst also ein Programm, setzt 1.5 als erforderliche Version und nimmst GLSL weil das ja bei deiner Karte als Extension da ist. Da wirste mit allen User mit nur GF4MX und darunter richtig viel Sßa haben. Die bekommen auch ne Version 1.5 angezeigt, nur fehlt da der GLSL Support.
Irgendwei ist es doch lustig, dass du mir immer wieder Recht gibst und dann versuchst dich rauszuwinden wenn man dich darauf aufmerksam macht. Sehr suspekt, wirklich. Aber es ist schön zu sehen, wieviel Mühe du dir wiedermal gegeben hast um genau das zu beweisen, was ich oben gesagt habe. Wenigstnes hast du diesmal das Thema nicht maßlos verfehlt und hast wenisgtens versucht darauf einzugehen, ob die GL Version Aussagen über die vorhandenen Extensions macht. Natürlich tut sie das, wie du ja oben selbst gesagt hast ( siehe Bsp mit VBO ). Ist schonmal ein Fortschritt, dass du was zum Thema geschrieben hast, wirklich.
-
Ich will mitflamen
, hab' aber keine Ahnung von nix!! Was kann ich da tun?!?
Okay, poste ich halt ein paar Smilies:
-
Ahvolon[F-Bytes] schrieb:
Du weißt, dass du mit entsprechender GL Version auch entsprechende Extensions hast. Du kannst eben nicht davon ausgehen, dass ne Karte mit GL Version 1.5 GLSL fähig ist. Sehr wohl kannst du aber davon ausgehen, dass alle 1.5 Features da sind. Und NUR darum ging es. Die GL Version macht eine Aussage über die vorhanden Core Features und ist damit in keinster Weise nichtssagend.
Es ging um die Version des Treibers.. Und nicht um die Karte..
Wenn Du ne 1.4-Karte hast und nur 1.1 (oder so..)-Treiber, dann kannst trotzdem auf die 1.4-Vorteile der Karte zugreifen. Darum gehts..[flame]
PS: und darum rockt ogl
[/flame]
-
durito schrieb:
Wenn Du ne 1.4-Karte hast und nur 1.1 (oder so..)-Treiber, dann kannst trotzdem auf die 1.4-Vorteile der Karte zugreifen.
Sag bloß
Das ist aber die falsche Richtung in dieser Diskussion, da es darum geht, ob die GL Version was über die Features aussagt. Und um es nochmal zu wiederholen, das tut sie. Wenn die gl Version der Treiber 1.1 ist und man das als Systemanforderung in seinem Projekt festsetzt, kann man nicht davon ausgehen, dass die Karte dann auch Sachen wie GLSL kann. Das mag zwar dann bei einigen Karten gehen, bei anderen nicht.
-
Die GL-Version des Treibers mag wohl aussagen, was die Karte mindestens kann. Aber das interessiert niemanden (naja, ok.. :)). Kauf Dir ne 6800er, und Du wirst nen 1.3-Treiber kriegen. Kauf Dir ne GeForce4 und Du kriegst 1.3... Was Dich an der Karte interessiert erfährst Du nicht aus der ogl-Version, sondern aus deren Extensions.
Was die HW betrifft ist die ogl-Version natürlich informativer, aber darum gings ja nicht, sondern um die Treiber..
-
durito schrieb:
Aber das interessiert niemanden.
Siehe Beispiel mit GF2. Wenn du ein Programm jeglicher Art machst musst du Systemanforderungen festlegen und kannst nicht davon ausgehen, dass ne Karte die 1.3 Treiber hat auch GLSL kann. Und die Version sagt dir, was die Karte die du hast 100% kann. Mehr muss man nicht wissen, da es lächerlich ist Programme zu schreiben, die Core Features von ner GL Version benutzen, für die es noch keine Treiber gibt und für die die Extensions lediglich schon in manchen Treibern drin sind, weil es manche Karten können.
-
Ahvolon[F-Bytes] schrieb:
durito schrieb:
Aber das interessiert niemanden.
Siehe Beispiel mit GF2. Wenn du ein Programm jeglicher Art machst musst du Systemanforderungen festlegen und kannst nicht davon ausgehen, dass ne Karte die 1.3 Treiber hat auch GLSL kann. Und die Version sagt dir, was die Karte die du hast 100% kann. Mehr muss man nicht wissen, da es lächerlich ist Programme zu schreiben, die Core Features von ner GL Version benutzen, für die es noch keine Treiber gibt und für die die Extensions lediglich schon in manchen Treibern drin sind, weil es manche Karten können.
Ja eben, 1.3 sagt mir gar nichts über die Karte aus. Wie willst Du also festlegen, dass Deine Anforderungen z.B. OpenGL 2.0 sind (inkl. GLSL), wenns eh keine 2.0-Treiber gibt? Wenn ich was festlege, dann welchen Shader ich will, und was für Extensions ich will. Somit kann ich, von der eh völlig veralteten OpenGl-Version unabhängig, meine Anforderungen stellen.