Epic hat ihre Seite mal wieder verändert, die auflistung aller Engines mit ein kurzen klappentext gibs ned mehr aber im developer network, welches du gelinkt hast findet man ja fast alle versionen.
Epic hat die UE3 aufgebohrt und bietet eine UE3 MMOG Lizenz an also ist eine eigene vollwertige Version, die auch schon kräftig lizenziert wurde, wenn man auf die Seite von denen schaut.

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

Projekte: https://github.com/tak2004

Naja die Versionen sind nur für Außenstehende. Wenn du jemanden komplexe Versionsnummern lieferst, der noch nie was mit der Engine zu tun gehabt hat, versteht der erstmal gar nichts. Die Versionen werden denke ich eher zur Lizensierung verwendet. Aber so genau weiß ich über die Engine wirklich nicht bescheid. An sich hast du Recht: Mehr Updates für OpenGL. Für mich ist OpenGL 3.0 wie die Ankündigung des imho grauenhaften Windows Vistas, weil es einfach eine viel zu große Umstellung erfordert.

Habe mir nochmal Gedanken gemacht: Es ist mehr an OOP orientiert. Wo liegt denn das Problem ? Man kann sich auch einfach Prozeduren schreiben, die den ganzen Murks etwas verstecken. Sollte man sowieso tun denke ich.

DirectX ist nach jeder Version inkompatibel, beim OpenGL passiert das nun zum ersten mal nach über 10 Jahren. Und ihr wollt doch nicht ernsthaft behaupten dass die alte API schöner sei als die von OpenGL3?
imo ist die statemaschiene sehr nervig, da ist die sammlung von Einstellungen in Gruppen doch extrem sinnvoll.
glBegin/glEnd verwendet niemand außer dem absoluten Anfänger der gerade sein erstes Dreieck rendert verwendet.
wenn man vernünftig mit OpenGL arbeiten will, muss man ohnehin eine OpenGL3 ähnelnde Abstraktionsebene drübersetzen.
Man muss auch mal alten Mist rauswerfen und eine schlanke neue API erstellen. Wen das stört kann doch einen OpenGL2 kontext erstellen. Ich habe wenig Sorgen das das bald eingestellt wird, Anwendungen die alte DirectX versionen verwenden werden doch auch noch unterstüzt.

Das einzige was mich an OpenGL3 stört ist die fehlende kompatibilität mit älterer Hardware (kein SM2). Die würde ich durch eine spezielle abgespeckte Shadersprache nachrüsten.

_________________

Ich hab ehrlich gesagt auch noch nicht allzuviel davon gesehen.
Ne kleine Zusammenfassung / Übersicht von den Entscheidungsträger würde ich mir wünschen. Die Specs durchackern, fehlt mir ehrlich gesagt die Zeit zu.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Genau an dieser Stelle beißt sich die Katze in den Schwanz. Es gibt noch keine Spec oder wirklich offizielle aussagekräftige Codebrocken zu OpenGL 3.

Unter folgendem Link gibt es die Newsletter dazu. http://www.opengl.org/pipeline/
[edit] Wobei ich gerade sehe, dass da noch andere Newsletter drunter sind. Das dreht sich also nicht alles um opengl 3. [edit]

"Another Object Lesson" ist ein Teil des letzten Newsletters. Dort ist (recht weit unten) eine Grafik enthalten. Die zeigt den zukünftigen Aufbau inklusive einer kleinen Beschreibung.

Haha

Selbst in fortgeschrittenen Programmen muss mal ein einfaches (texturiertes) Quad gezeichnet werden, glaube nicht, dass man dort mit Vertexarrays rangeht.

Klar, bei vielen Daten benutzt man es nicht mehr, OpenGL hat aber einen sehr breiten Anwendungsbereich ( nicht nur Spieleprogrammierung ), deshalb würde ich solche pauschalisierten Aussagen an deiner Stelle lieber nicht treffen...

Viele Grüße
dj3hut1

Es gibt viele Projekte, bei denen man mit glBegin besser bedient ist als mit OOP. Bei Audio-Visualisierungen kann man zwar für jede eine Klasse erzeugen, aber Unterklassen dafür wären meiner Meinung nach die größte Schande überhaupt. Wozu OOP wenn man es nicht zwangsweise braucht ? Dem Benutzer die Möglichkeit zu geben, sich zu entscheiden wäre denke ich die einzig wirklich richtige Entscheidung.

OpenGL3 ist immernoch prozedural, geht auch garnicht anders, da es ne shared library ist und die sind prozedural.
Doch hat man nun eine variable, die ein Objekt kapselt, dabei hast du ne ID und OpenGL ein Objekt.
Also wie bei Texturen,VBO,Shader,... . Materials und immidate mode sind aktuell Beispiele, die nicht auf dem Objektkonzept basieren.
Es gibt zwar Ansätze Bibliotheken auf OO Ebene zu bringen mit z.B. DCOM aber das ist murks.

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

Projekte: https://github.com/tak2004

Hm, wäre dann nicht aber sogar die Umsetzung von Shadern usw. einfacher als mit der alten Version ? Hätte Vorteile, denn Shader wären recht interessant.

@Nils. Klasse: Ich verstehe nicht ganz was du damit sagen willst aber deine Klasse müssen nicht darauf beschränkt sein, dass du mit einem einzigen Draw() Aufruf auskommst. Du kannst auch Klassen machen die sich nur um die Datenhaltung kümmern und den Rest machst du direkt in OpenGL. Wie es dir lieber ist und wie du es machen willst liegt ja in deiner Hand.

Allerdings ist das Klassen und Unterklassen Konzept wohl eher das was ein strikter OOPler vorziehen würde. Bzw sind Ableitungen für etwas was ziemlich ähnlich ist (Visualisierungen) wie geschaffen dafür. Aber das nur mal am Rand.

Natürlich kann man ableiten. Das ist auch sehr schön, allerdings muss man aufpassen, dass man die ganzen Klassen gut in Units verteilt, da man sonst riesige Units bekommt, die man selbst nur noch mit der Suche durchsucht und an der Fundstelle weiterarbeitet. So viele Units sind aber hingegen auch nicht mein Stil, daher stinkt mir dieses Mega-OOP. Ich denke für eine 3D-Engine ist das aber recht wurscht, da man dort um viele Klassen sowieso nicht herum kommt.

Also ich bin sehr auf Objektorientierung bedacht. Allerdings kenne ich auch einige Fälle in denen OOP wirklich übertrieben oder falsch eingesetzt wurde. Das auf zu viele Units zu verteilen mag ich persönlich auch nicht. Man muss dabei den "goldenen Mittelweg" finden wobei das wieder vom persönlichen Stil abhängt. Bei meinen Fonts habe ich bis auf eine Reihe von Ableitungen (ein Vorfahre) alle Klassen ( 18 ) in einer Unit. Die hat dann locker über 5000 Zeilen. Allerdings hilft Delphi dort ungemein bei der Navigation ohne, dass ich eine Suche betätigen muss.

Aber ich glaube wir schweifen ab. Wobei ich selber angefangen habe darauf rum zu reiten.

Ich finde das Konzept der vielen Units garnicht so übel. So wie in Java funktioniert es ganz gut. Auch das Konzept der Paketsichtbarkeit (vergleichbar mit der Sichtbarkeit von Klassen in der selben Unit untereinander) finde ich sinnvoll. So können Klassen, die eng miteinander verbunden sind auch gegenseitig auf Methoden und Felder zugreifen, die außerhalb des Pakets nicht sichtbar sind. So baut man sich selbst eine paketinterne API und nach außen hin eine sichere eingeschränkte API.
Bei 1 Unit pro Klasse in Delphi bekomme ich immer wieder mal Probleme, wenn man zwei Klassen hat die sich gegenseitig referenzieren.
Meist habe ich das Problem: Klasse TContain enthält immer ein TElement-Objekt und Klasse TElement führt eine Referenz auf seinen Parent als TContain-Referenz.

Um mal was zum Thema zu sagen: So wie es aussieht könnte man für OpenGL 3 / Longs Peak auch OOP-Wrapper basteln.
Es wird für ein paar Konzepte Container geben, z.B. für:
Frame Buffer Object -> Color Attachment, Depth Buffer Attachment, ...
Program Object -> Pixel Shader, Vertex Shader, ...
Vertex Buffer Object -> TexCoord Array, Vertex Array, ...
...
Viele Methoden für Frame Buffer Object und Program Object werden vermutlich gleich sein. Man denkt da an "GetCount" oder "Delete(i)". Die wandern in eine Basisklasse "TOpenGlContainer" und alle speziellen Objekttypen erben davon. Ich glaube aber, dass ich davon absehen würde weil man doch meist nochmals Wrapper für seine Programme schreibt. Statt eines Vertex Buffer Object hat man dann doch eher einen Model Loader o.ä., der direkt in OpenGL rendert.