Ich kann es noch garnicht recht glauben. Das allseits zum Testen und für den schnellen Einstieg in die API geliebte glBegin() soll sterben. Wir werden uns alle Vertex-Buffer-Klassen schreiben müssen, nur um einen Markierungspunkt zu malen. Auch die Selektion von Objekten mit der Maus wird von der API nicht mehr unterstützt werden.
Auf der anderen Seite, wird immer wieder der Immediate-Mode auch in veröffentlichter Software verwendet und sorgt da für schlechte OpenGL Preformance und taucht die ganze API in ein schlechtes Licht. Man will weg vom Zustandsautomaten hin zu Objektorientierung und freier Programmierung des Grafikprozessors (Stichwort: Geometrie-Shader).
Ich habe vor einiger Zeit eine meiner alten OpenGL Anwendungen ausgegraben und festgestellt: "Auf meiner nVidia TNT von damals lief das schneller". Ich dachte damals ich müsste nach jedem Frame den Rendering-Context deaktivieren und vor jedem Frame aktivieren. Die TNT hat da nicht viel zu tun gehabt, meine neue Grafikkarte war aber offensichtlich ganz anders strukturiert und schlich nur noch.
Ein anderes Beispiel sind VBOs. Nachdem ich ~1000 Polygone im Immediate-Mode renderte viel mir ein leichtes Ruckeln auf. Erst da wurde mir klar, dass dieser Betriebsmodus tot ist. Ich fing also an mich über VBOs zu informieren und eine neue Delphi-Klassenhierarchie für Gemotrie zu entwerfen.

- Verliert OpenGL nun viel von seiner Zugänglichkeit?

- Was soll mit den OpenGL 1.0 - 2.x Tutorials geschehen?

- Gibt es schon neue 'Einsteigertutorials', die nur VBOs verwenden?

Nu warte doch erstmal ab bis das ganze erschienen ist. Erst dann kann man irgendwie beurteilen, wie viel schwerer/leichter der Einstieg geworden ist.
Und sobald OpenGL 3.0 draußen ist, ist 2.0 doch noch nicht tot, deine Anwendungen werden weiterhin hardwarebeschleunigt laufen.

Warten wir erstmal ab bis die OGL 3.0 Spezifikation draussen ist.
Danach können dann unsere Kinder die Tutorials entsprechend anpassen.
Bis jetzt sind es ja nur Spekulationen und nichts festes.
Desweiteren haben wir nach Veröffentlichung der Spezifikationen noch weiter Zeit bis es entsprechende Treiber gibt.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Du bist ja optimistisch ^^.

Ich sehe die Kürzung von glBegin und glEnd als Verbesserung an, da ja keine Funktionalitaet verloren geht. Eine einfachere API ist meisstens auch einfacher zu implementieren. Und wer VBOS schon fuer kleine Projekte verwendet tut sich nicht schwer, diese auch in groesseren Projekten zu verwenden.

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Ich persönlich sehe das so. Die OpenGL32.dll ist fester Bestandteil von Windows und bereits die dll bietet die imediate Funktionen. Die Treiber dürfen an dieser Datei nichts verändern. Sondern sie registrieren eine DLL im Windows auf die die opengl32.dll dann zugreift. Ein neuer Treiber mit einer neuen Struktur darf auch nicht einfach so Methoden weglassen. OpenGL Methoden die existieren aber nicht funktionieren darf nicht sein. Deswegen denke ich, dass es ein Gegenstück zur opengl32.dll geben muss. Und entsprechend dann zusätzlich zu OpenGL 2 auch noch 3. OpenGL 2 wird zu mindest bei den großen Herstellern dann relativ schnell brach liegen bleiben bzw "aussterben". Aber ich denke einfach mal, dass es technisch so laufen wird.

Alles Andere steht noch in den Sternen. Und das muss man dann mal sehen, wenn OpenGL 3 irgendwann mal erscheint. Das Jahrtausend ist ja noch kurz...

Und in unsere Tutorialsection im Wiki gibt es bereits ein Tutorial für VBOs. Viel einfacher wirds nimmer gehen.

[edit]Als Anmerkung. Klar, wenn man nur ein Viereck zeichnen will ist es mehr Aufwand. Aber in der Regel wird es ja so sein, dass man mehr damit macht. Models, Level, etc.

Naja, und ansonsten ist eine kleine Klasse, die einem solche Primitiven wie Quads zeichnet, doch bestimmt fix geschrieben.

Erstmal bist du nicht gezwungen OpenGL3.0 zu verwenden, wie schon in der Pipeline erwähnt wurde, kommt einer neuer OS API befehl hinzu, der es ermöglich ein OpenGL3.0 Context zu erstellen, statt einen OpenGL2.x .
Wenn du also bei deinen glBegin und co bleiben möchtest, dann kannst du die alten Tutorials verwenden, wo auch der (dann alte) Rendercontext erstellt wird.
Ausserdem werden Objekte eingeführt, wonach alles als Objekte gekapselt sind(namenstechnisch blöd, da es ja immernoch procedural ist).
Damit wird auch das arbeiten leichter, da man wesentlich schneller alle verfügbaren Funktionen zu einem Objekt finden kann.
OpenGL3.0 ist eigentlich für die interessant, die schon mit OpenGL arbeiten und nicht für die neueren.

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

Projekte: https://github.com/tak2004

Mir gefällt nicht, dass Einsteiger es dann schwerer haben als früher. Viel Zulauf hat OpenGL bis jetzt schon nicht gehabt, weil hier alles viel mühsamer ist als in DirectX, wo den Programmierern alles auf dem Silbertablett serviert wird. Den Zugang jetzt zusätzlich noch schwerer machen halte ich für einen strategischen Fehler.
Traude

Hallo,

also ich würd da nichts überstürzen.
Ersteinmal wird es eine Weile dauern, bis sich OpenGL 3.0 verbreitet hat, selbst die 2.0 Version läuft momentan noch nicht auf allen neuen Rechnern ( z.B. auf einigen Laptops mit OnBoard-Chips ).
Es wird sicher noch eine Weile dauern, bis alle Grafikkartenhersteller OpenGL 3.0 fähige Karten herausbringen.

Außerdem wird die neue Version, wenn ich das richtig verstanden habe, weiterhin abwärtskompatibel bleiben ( http://en.wikipedia.org/wiki/OpenGL#OpenGL_3.0 (...To support backwards compatibility, all of the old API will still be available... )), d.h. man kann weiterhin noch mit den alten Funktionen programmieren.

Also keine Sorge, die Tutorials und das Wiki müssen nicht umgeschrieben, sondern höchstens erweitert werden

Viele Grüße
dj3hut1

Wenn eines der erklärten Zeile ist, die Entwicklung von Treibern durch Wegfall von Altlasten zu vereinfachen, dann kann ich mir nicht vorstellen wie das über einen längeren Zeitraum gut gehen soll. nVidia macht das mit Sicherheit mit. Die anderen zwei beiden werden aber wahrscheinlich garnicht mehr in die Puschen kommen
Da es aber wirklich noch dauern kann, bis die Ehrenamtlichen von Khronos fertig werden und die Treiber da sind können wir das erst mal entspannt angehen. Auf der SIGGRAPH, so Micheal Gold von nVidia sollen wir mehr erfahren. Das ist glaube ich in einem Monat oder so.

Erstmal wird es den neulingen nicht schwerer gemacht, sondern leichter, da zig funktionen rausfliegen, die völlig veraltet sind, garnicht verwendet werden, doppelt und dreifach vorhanden sind oder schlicht weg es nie weiter als ne extension geschaft haben.
Dies hat ne menge Vorteile,
1. die API wird übersichtlicher und verständlicher
2. die entwicklung von Treibern wird verdammt viel leichter, da der größte mist aka begin end und der ganze kram dahinter endlich verschwindet
(ganz ehrlich wer mit immidate mode in produktiv umgebungen arbeitet hat was falsch gemacht und Anfänger haben definitiv andere sorgen als 5 oder 7 Zeilen code zu schreiben)
3. die abstrahierung auf objektebene ist wesentlich verständlicher für anfänger
4. OpenGL ist so sehr veraltet, dass man mitlerweile nur durch mehere pipelines und massiver verwendung von extensions/arb auf aktuellen Grafikkarten niveau arbeiten kann(teilweise sogar nicht mal damit)

Ich hab mal ne zahl von ~30% gelesen, die der begin/end kram im gl kern ausmacht(ohne arb und ext) selbst wenn es nur 10% wären, ist das ne extreme erleichterung für Treiberhersteller. In Spielen nutzt man diesen Code eh nicht aber er muss trotzdem gepflegt werden, da er in den Kern gehört.
Wer sich mal mit Mesa beschäftigt hat oder vieleicht mal nen eigenen Software renderer schrieb, der kennt das Leid mit dem glBegin/glEnd konstrukt.

Ich hoffe sogar, das noch dinge wie vertex- und pixelprogram und gllight rausfliegen.
Das Materialssystem noch überarbeitet wird und man eine einfach möglichkeit von userdata definierung ermöglicht.
Damit man seine Bone-,Licht- oder Materialdaten, die man noch zusätzlich verwendet einfach in OpenGL rein bekommt.
Den ganzen Blending und picking kram könnte man mitlerweile auch rauswerfen, picking geht über die physikschnitstelle eh schneller und einfacher und Blending sowie lighting wird in Zeiten der Shader eh im Shader gemacht.
Ein Profieler mechanismus im Treiber wäre auch wünschenswert, damit man nicht auf externe Lösungen zugreifen muss, sondern die Vendor Spezifischen eigenarten gleich mit drin hat.
Mitlerweile ist es auch wichtig, dass man Möglichkeiten schafft MGPU und MCPU entwicklung zu erleichtern, vieleicht Container schaffen, Prozesslines, Debuginfos oder schlicht weg zu dokumentieren, welche Funktionen fatal sind(kleines Beispiel occlussion culling verbietet MGPU Programme und lässt das Programm auf nur eine GPU zurückfallen).
OpenGL3.0 sollte eher für die Advanced User sein und sich nicht an die Anfänger richten.
Wenn es nicht schon in OGL3.x passiert wird wohl spätestens mit OGL4.x dann einiges mit raytracing möglich sein.
Screen spaced Funktionen wie SSAO gehen in diese Richtung oder subsurface scattering sowie realtime radiocity.

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

Projekte: https://github.com/tak2004

Tak2004 schrieb:

Klingt gut.


Der "Kram dahinter" ist mir wurscht: ich bin ein Benutzer. Die Grafik-Library ist für mich da, nicht umgekehrt.


Immediate Mode ist dort richtig wo er gebraucht wird: Ich bastle an einem Modeller herum, da weiß ich nie, was dem Benutzer als nächstes einfällt; im nächsten Frame kann eine ganz unterschiedliche Zahl/Art von Primitiven gerendert werden die man nicht schon vorher als VBOs laden kann weil sie vorher gar nicht existiert haben (der User hat große Teile des Modells einfach gelöscht oder hat die "Triangulieren" Funktion benutzt und damit die Anzahl der Primitiven vervielfacht). Da ist glBegin/glEnd für mich einfach leichter, als alle aktuellen Primitiven andauernd in ein Array zu verpacken damit es die Grafik-Library leichter hat.

Dazu kommt noch: Bis vor einigen Monaten habe ich auf einem Laptop gearbeitet, das konnte gar keine VBO's.


Das seh ich ganz anders. Je weniger Code zu Anfang zu schreiben ist desto weniger Fehler können gemacht werden desto früher das erste Erfolgserlebnis. DESTO LEICHTER KANN MAN IN EINEM FORUM HILFE BEKOMMEN.

Überall wo man OpenGL-Tutorials finden kann, wird anfangs mit glBegin/glEnd gearbeitet. Damit fangen die Leute einfach an, zumindest bisher. Komm wieder auf den Teppich.


Verständlicher als glBegin/glEnd?


Wenn eine Überarbeitung der API notwendig ist, warum muss unbedingt der "Immediate Mode" rausfliegen? Bloss weil Du es im Augenblick nicht brauchst, kannst Du nicht ausschließen, dass andere es noch brauchen und dafür auch gewichtige Gründe haben.


Es gibt auch noch andere Grafik-Anwendungen als Spiele. Der Hauptkundenkreis von OpenGL produziert gar keine Spiele.


Dazu siehe unten letzter Punkt.


DAS kann ich vorbehaltslos unterschreiben. Und außerdem noch eine einfache Änderung der UserData zuläßt. Womit wir wieder bei einem "Immediate Mode" wären.


Dagegen hätte ich gar nichts. Wenn der "Immediate Mode" total unvereinbar mit schnellem Rendering ist, gäbe es zwei Systeme nebeneinander, die einander nicht behindern. So scheints ja auch geplant zu sein.

Wenn für das Zeichnen mit OpenGL jetzt die Latte viel höher gelegt wird, kann man sich ganz einfach ausmalen, wohin die Leute abwandern werden.

Traude

Das sehe ich anders, weil OpenGL auf die Unterstützung der Industrie angewiesen ist. OpenGL muss ebenso für die Entwickler von Grafikkarten da sein, wie für die Programmierer von 3D Anwendungen. Wenn die Treiber mühselig zu entwickeln sind und viel ungenutzte Bestandteile beinhalten bedeutet das für uns konkret vermehrt Bugs, aus Zeitmangel nicht implementierte Features (FBOs bei ATi) usw.
Ich würde mich wohler fühlen, wenn die Hardware Hersteller nicht OpenGL 1.0, 1.1, 1.4, 2.0, 2.1, 2.2 und 3.0 unterstützen müssten - wenn gleich sie es dürfen.


Naja, dein altes Laptop kann vermutlich auch keine Shader kompilieren. Das Problem hat man ja in DirectX auch. Dann muss man das so machen wie Valve mit der Source-Engine. Die lief auch auf meiner Laptop-Grafikkarte von 2000 dank separaten Renderpfaden für DX 7,8 und 9. Das muss nicht einmal viel Arbeit sein: Da VBOs auf Vertex-Arrays aufbauen, kannst du mit einer einfachen Fallunterscheidung wechseln.
Nun zu deinem Projekt! Die Entwickler von Blender standen 2005 vor dem selben Problem. Ein Mitarbeiter des ARB hielt einen Vortrag darüber, wie Blender schneller werden könnte (10-fach wie er glaubte, lol) und er verteufelte den Immediate-Mode genauso wie er VBOs in höchsten Tönen lobte.
1. VBOs sind flexibler als viele glauben. Es gibt die statische Variante, aber auch z.B. die Streaming-VBOs, die locker jedes Frame modifiziert werden können. Reserviere dir einfach einen großen Klumpen Speicher und fülle ihn während der Modellierung auf. Wenn er mal zu knapp wird: Einfach freigeben und neuen holen. Dann hast du mal eine kurze Verzögerung, aber die Arbeitsgeschwindigkeit wird so unglaublich verbessert, dass du nie wieder glBegin verwenden möchtest ^^.
2. Du sollst es nicht der Grafik-Library leichter machen, sondern deine CPU und den PCI(E)-Bus entlasten und deine GPU besser nutzen . Über kurz oder lang WIRST du mit deinem Modelling-Tool an die Grenzen der Framerate kommen. Ich habe nur ~1000 Polys auf meinem GF 8600 GT(!) Laptop im Immediate Mode berechnen und rendern müssen und es ruckelte.


Da hast du verdammt recht.


Weil die Treiberentwickler unmöglich ihre gewaltigen Render-Pipelines auf Immediate-Mode optimieren können. Die Grafikkarten BRAUCHEN heute die Gewissheit, dass sich nichts an den Rahmenbedingungen ändert, dass du nicht versuchts ungültige Befehle zwischen glBegin()/glEnd auszuführen und wenn die Vertexdaten im Video-RAM liegen ist die Geschwindigkeit optimal. Durch die Unvorhersehbarkeit und die unzähligen Fehlerabfragen wird die API ausgebremst. Es geht also nicht nur darum, ob man Immediate-Mode noch drin lässt, für die die es brauchen, sondern auch darum, es endlich loszuerden, damit der Großteil der Anwender nicht gebremst wird.

Gruß,
Marco

Aus der Sicht eines Anfängers mag das stimmen aber wer wirklich mit OpenGL arbeitet, Software entwickelt muss wissen was OpenGL hinter den Kulissen macht, damit es reibungslos und performant läuft.


Mhh du hast aber schon mal Blender gesehen oder ?
Blender und wohl auch alle anderen guten Editoren benuzten Verticelisten, diese werden auf OpenGL vertexarrays gemapped und in verbindung mit Indices sind änderungen am Mesh garnicht schwer und aufwändig.


Wie schon gesagt Vertexarrays, die Daten kann man im arbeitsspeicher halten und mapped die dann einfach auf ein vertexarray.
Da ist kein VBO notwendig und es ist auch nicht viel langsamer. Noch dazu reden wir von OpenGL 3.0 und nicht von OpenGL 1.2.
Wenn du OpenGL 3.0 verwenden willst, dann muss deine Grafikkarte auch alle Corefunktionen haben(wo dann auch VBO und GLSL reinzählt) sonnst musst du ein fallback auf software oder OpenGL 1.5-2.x machen.
Du kannst ja auch kein DX10.1 Software schreiben und die dann auf DX9 Hardware laufen lassen.


In meinen Studiengang haben sich allen mit dem glBegin/glEnd schwer getan.
Sie haben nicht verstanden, wie man 7vertice reinpacken kann und er 2 Dreiecke zeichnet, was ist mit dem 7 Vertex, wieso funktioniert das.
Wieso kann ich dazwischen alle anderen funktionen packen und es läuft trotzdem, teilweise haben sie auch probleme mit der reihenfolge der daten gehabt.
Sie fanden es wesentlich verständlicher als die Verticedaten in einer Liste lagen(ein float array).
Dann ein Vertexarray zu verwenden ist vom Code genauso lang wie ein glbegin/glend und ist wesentlich fehlerunanfälliger.
Wenn es wem wirklich leichter fallen sollte, mit glBegin/glEnd zu arbeiten, ist es ja kein Problem, muss man ja nur den alten OpenGL Context erstellen, dort gibt es den immidate mode noch.


Bin ich fest der Meinung. Ja.


Warum soll überhaupt was rausfliegen, jeder benutzt irgendeine Funktion und wird traurig sein, dass sie in OGL3.0 nicht mehr vorhanden sein wird.
Ich brauch ihn nicht nur im Augenblick nicht, sondern generell nicht.
Wie du schon gesagt hast, nutzt die Industrie überwiegend OpenGL und der Industrie ist es nicht im geringesten wichtig, das es ein immidate modus oder VBO gibt, die würden auch die Daten in res files quetschen oder sonnst welche Implementierungen verwenden, wenn es performant und robust bleibt.
In der Software wird die Darstellung eh gekapselt und bei der entwicklung sieht man wenig bis garkein OpenGL mehr.
VBO,Vertexarrays sind leichter zu Kapseln und vorallem wesentlich Fehlerfreier und schlanker.
Wie schon erwähnt wurde, hat der immidate modus ne menge Code im gepäck.
Es muss gegen alle nur erdänklichen Fehler geprüft werden, welche funktionen können zwischen begin und end aufgerufen werden welche aufgarkeinen fall, welche sind akzeptabel und was kann man noch retten. Der ganze Treiber muss erweitert werden, weil man durch den immidate mode ein funktionsähnlichen Scope mit in die Statemachine implementieren muss. Was macht man mit Befehlen die zwischen begin und end stehen und garnicht da sein dürften, sollen sie nach end noch aufgerufen werden oder vor begin ? Dann braucht man caches, wie groß der Cache, welche einbusen bringt dies und viele weitere Probleme kommen damit. Dieses Problem tritt dadurch auf, dass es nicht Objektbezogen ist. Drum meinte ich ja auch, wenn man mal mit dem Mesacode angeschaut hat oder eigene Softwarerenderer geschrieben hat, der versteht was alles an diesen doch so unscheinbaren Feature hinter hängt, denn es zieht sich bis in den rasterizer hinein.
Wenn dieser ganze Aufwand wegfällt, dann kann man die gewonnende Zeit auf sinnvollere dinge lenken, z.B. Fehlerbehebung von neuen Funktionen oder implementierung neuer Algorythmen.


Das geht sehr einfach ohne, Newton, LUA und andere Bibliotheken erlauben pointer an ein Objekt zu hängen und damit hat man seine userdaten.
Wenn man ein Objekt vor der Nase hat, dann kann man den Pointer abfragen und somit auf die eigenen zusätlichen informationen zugreifen.


Du meinst, wenn OpenGL erstmal wieder auf den Stand von DX10.1 kommt ^^.
OpenGL braucht man nicht mit DX vergleichen, OpenML ist der konkurrent zu DX und OpenGL hat einen entscheidenen Vorteil, Platformunabhängig.
Wenn man auf meheren Platformen arbeiten will und nicht bereits eine Engine hat, dann wird OpenGL verwendet.

Ich finde z.B. ziemlich witzig, dass in WOW immernoch ein OpenGL Pipeline drin ist, die man per parameter aktivieren kann.
Wenn man unter Linux WOW und wine installiert, dann bekommt man von Blizzard einen Patch für wine und kann dann mit Flag WOW unter Linux spielen.

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

Projekte: https://github.com/tak2004

Also mich wundert ernsthaft, dass das hier soo lange stehengeblieben ist. Seit wann kann man denn mit Shadern blenden? Dazu muss man doch auf den aktuellen Framebufferinhalt zugreifen, was aber nichteinmal mit FBOs geht. Also das muss mir jetzt einer erklären.

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