4. [gelöst] OpenGL modern programmieren ist noch nicht "in"?

[gelöst] OpenGL modern programmieren ist noch nicht "in"?

  • S

    dot schrieb:

    stefanjann schrieb:

    Und wie dot in einem anderen Thread dann schon bemerkt hatte: Im Juli 2010 war OpenGL schon jahrelang "out".

    Ich hab gesagt OpenGL 1.x ist schon seit einem Jahrzehnt hoffnungslos veraltet, nicht dass OpenGL im allgemeinen veraltet ist. Auch wenn die API was das Design angeht imo bei weitem nicht mit Direct3D 11 mithalten kann ist OpenGL sicherlich gleich mächtig.

    Entschuldigung, ICH hab mich da verschrieben. Ich wollte natürlich "OpenGL 1.x" schreiben (also das "1.x" vergessen zu schreiben). Dein genauer Wortlaut zu meinem "tollen Buch" war:

    dot schrieb:

    Naja wenn das Buch glBegin()/glEnd() für die ersten kurzen Beispiele verwendet oder einfach der Vollständigkeit halber erwähnt ist das OK, immerhin bekommt man damit schnell was auf den Bildschirm. Wenn das allerdings alles ist kannst du das Buch in die Tonne treten. Das ist nämlich nicht erst neulich veraltet sondern schon seit 10 Jahren oder so

    Aus dem Thread http://www.c-plusplus.net/forum/284326-10

    dot schrieb:

    Was genau soll dieser Noteneditor können und warum meinst du dass du dafür OpenGL verwenden willst?

    Naja, ich bin Musiker und mein Noteneditor soll auf der einen Seite die Noten und Gitarren-Akkorder entgegen nehmen und dann am Bildschirm (mit OpenGL) die Grifftabelle für den Gitarristen direkt auf einer 3D-Gitarre zeichnen (so mit halbtransparente Finger). Ist für meine Gitarrenschüler sehr hilfreich zum üben. Unter Flash hab ich sowas schon gemacht, aber mit OpenGL wäre es noch leichter anzusehen, weil man die Gitarre dann drehen könnte und unter C++ kann ich besser programmieren als unter Flash.

    Nexus schrieb:

    Ogre hat bei mir einen sehr schlechten ersten Eindruck hinterlassen. Das ganze Framework ist ein einziges Biest, ich fand es schwer den Überblick zu behalten. Jede Klasse ist gigantisch gross. Die Kompilierzeiten sind elend lang, bereits Hello World braucht fast eine Minute. Die einzelnen Dinge scheinen zu fest gekoppelt, dieses Konfigurationsmenü am Anfang nervt. Meine Güte, ich will doch nur ein Modell rendern 🙂

    Wie gesagt, erster Eindruck, ich glaube gern, dass Ogre dahinter sehr mächtig ist. Aber für den Anfang würde ich es nicht empfehlen. Da stand Irrlicht im krassen Gegensatz dazu. Eine relativ intuitive und anfängerfreundliche API, gute Tutorials, nicht dieser Code-Bloat. Man kann nachvollziehen, wie etwas zustande kommt. Ich habe auch schon geplant, für ein 3D-Spiel Irrlicht zu verwenden, und sehe keinen Grund, der für mich wirklich dagegen spricht (und schon gar keinen, der für Ogre spricht).

    Also ich hab mir Ogre herunter geladen und hatte schon Probleme die Exe-Datei auszupacken, denn die gab immer die Fehlermeldung aus "Die beinhalteten Daten sind kein Archiv". Und dann bei einer selbstenpackenden Zip-Exe. Ich hab dann eine die Version davor auf einer anderen Quelle gefunden und die ins Visual Studio geladen. Am Ende hatte ich ca. 5000 Warnings in Form von "Type xx zu Type yy: Datenverlust möglich", etc... So richtig als Vorbild würde ich das jetzt auch nicht sehen. Und innen drinnen sehe ich viele Dinge, die mir auch eher als "Altbacken" erscheinen und nicht gerade "wohldurchdacht". Aber das ist jetzt nur mein erster Eindruck.

    inter2k3 schrieb:

    OGL 1.x zu lernen ist nonsense - das wird dich nur verwirren, wenn du dann wirklich auf OGL 3.x aufwärts umsteigen möchtest.

    Wares Wort. Das ist eine ganz andere Welt. Ich tu mich richtig schwer die Denke von glBegin() in ein Vertex-Array umzustellen. Ich empfehle jeden gleich direkt mit "modernen" OpenGL einzusteigen.

    inter2k3 schrieb:

    Dann isses ein schlechtes Buch

    Japp, das isses. Ich hab mir jetzt das folgende Buch bestellt:
    Shader mit GLSL: Eine Einführung in die OpenGL Shading Language
    Und danach werde ich mir wohl die SuperBibel (5th edition) holen.
    Ich hoffe, danach kenn ich mich dann mit modernen OpenGL aus, dass ich auch mal optisch "schöne" Spiele schreiben kann.

    0

  • stefanjann schrieb:

    dot schrieb:

    Was genau soll dieser Noteneditor können und warum meinst du dass du dafür OpenGL verwenden willst?

    Naja, ich bin Musiker und mein Noteneditor soll auf der einen Seite die Noten und Gitarren-Akkorder entgegen nehmen und dann am Bildschirm (mit OpenGL) die Grifftabelle für den Gitarristen direkt auf einer 3D-Gitarre zeichnen (so mit halbtransparente Finger). Ist für meine Gitarrenschüler sehr hilfreich zum üben. Unter Flash hab ich sowas schon gemacht, aber mit OpenGL wäre es noch leichter anzusehen, weil man die Gitarre dann drehen könnte und unter C++ kann ich besser programmieren als unter Flash.

    Wenns dir nur drum geht diesen Noteneditor zu programmieren und nicht drum unbedingt die Technik dahinter in vollem Umfang bis ins letzte Detail zu erkunden dann würd ich dir auf jeden Fall dazu raten eine fertige Engine zu verwenden, damit kommst du viel schneller ans Ziel.

    0
  • S

    dot schrieb:

    Wenns dir nur drum geht diesen Noteneditor zu programmieren und nicht drum unbedingt die Technik dahinter in vollem Umfang bis ins letzte Detail zu erkunden dann würd ich dir auf jeden Fall dazu raten eine fertige Engine zu verwenden, damit kommst du viel schneller ans Ziel.

    Es geht mir ja nicht um Zeit, sondern dass ich Anfang ein echtes Programm zu schreiben um OpenGL zu lernen. Also lieber selbst geschrieben. Das ist jetzt mein erstes Programm. Und wie war der Tipp: "Schreib keine Engine, schreib Spiele!" (oder Anwendungen). *g*

    0
  • C

    Ich komm hier irgendwie nicht so recht dahinter, wo das Problem liegt. Wenn man schon ein bestimmtes Ziel hat (Noteneditor in 3D), schaut man halt was man dazu braucht und lernt es, oder man nimmt eben gleich ne fertige Engine. Und für diesen Zweck, mal ehrlich, ist es ziemlich egal ob du Irrlicht nimmst oder den nächsten strenggeheimen Prototypen von John Carmack. Ich würd dir sogar zu Irrlicht raten, weil diese Engine sehr einfach zu verstehen ist und du somit auch dein Ziel wesentlich schneller erreichen solltest.

    0

  • Ich versteh auch nicht so ganz wo jetzt dein Problem liegt. Wenn es dir darum geht ein gewisses Projekt umzusetzen dann such dir eine fertige Engine/Bibliothek mit der du deine Idee eben möglichst einfach umsetzen kannst.

    Wenn es dir darum geht OpenGL zu lernen dann lern OpenGL. Und OpenGL bedeutet heutzutage nunmal VBOs, Shader, FBOs, etc. Das heißt nicht dass du nicht am Anfang auch mal mit glBegin/glEnd experimentieren darfst. Du sollst dabei nur auf keinen Fall vergessen dass das eben bei weitem nicht der Weisheit letzter Schluss ist...

    0
  • S

    dot schrieb:

    Ich versteh auch nicht so ganz wo jetzt dein Problem liegt. Wenn es dir darum geht ein gewisses Projekt umzusetzen dann such dir eine fertige Engine/Bibliothek mit der du deine Idee eben möglichst einfach umsetzen kannst.

    Cpp_Junky schrieb:

    Ich komm hier irgendwie nicht so recht dahinter, wo das Problem liegt.

    Am Anfang des Thread hatte ich noch ein paar Probleme und Fragen. Die habt ihr aber in der Zwischenzeit schon ausgeräumt/beantwortet. Meine Frage war ja am Anfang (grob gesagt): "Warum nutzen die Engines die man im Web findet eigentlich noch glBegin()/glEnd()". Ich glaube die Frage ist sehr gut beantwortet worden. Auch die Frage nach Sinn und Unsinn von "Immer das neueste OpenGL!" und "Wie fange ich an OpenGL zu lernen" habt ihr mir beantwortet. Dabei habe ich auch festgestellt, dass man evtl. auch (je nach Anwendungsbereich) die Zielgruppe und die vorhandene Grafikunterstützung berücksichtigen sollte.

    Also hab ich jetzt eigentlich kein Problem mehr, außer dass ich noch 2-3 Bücher, viele Tutorials, ein paar "best practice" und ganz viel "Try-And-Error"-Versuche vor mir habe.

    Aber das wichtigste was ich nun von euch gelernt habe ist: Schreib keine Engine, schreibe Anwendungen! Die "Enigne" ergibt sich dann aus deiner Arbeit (und deinen Befehlen) von ganz alleine (und zwar aus der praktischen Arbeit).

    Nur eine Frage stellt sich mir nach wie vor: Welche freie Engine ist denn nun wirklich gut um "hartes" OpenGL 4.x zu sehen/lernen (man muss auch man über seine Ziele hinausschauen um besser zu werden...) *g*

    Daher vielen Dank für euere Gedanken.

    0

  • stefanjann schrieb:

    Nur eine Frage stellt sich mir nach wie vor: Welche freie Engine ist denn nun wirklich gut um "hartes" OpenGL 4.x zu sehen/lernen (man muss auch man über seine Ziele hinausschauen um besser zu werden...) *g*

    Wie gesagt: Die Open Source Engines die mir so bekannt sind würd ich mir alle nicht zum Vorbild nehmen. OpenGL 4.0 wird wohl noch in keiner der bekannten Open Source Engines wirklich verwendet...

    0
  • ?

    dot schrieb:

    Wie gesagt: Die Open Source Engines die mir so bekannt sind würd ich mir alle nicht zum Vorbild nehmen.

    Könntest du das mal begründen? Weiter oben schreibst du noch, du hättest dich nicht wirklich mit Ogre oder Irrlicht beschäftigt 🙄

    Was würdest du denn empfehlen?

    0

  • Auch wenn ichs nicht verwendet hab, hab ich aber schon öfters Code gesehn der mit Ogre bzw. Irrlich arbeitet. Daher weiß ich z.B. dass das Interface von Irrlicht voll mit Fixed Function Kram und Ogre eine Sammlung von Singletons ist. Beides also absolut kein Beispiel für gute Softwarearchitektur. Dazu kommt dass beide Engines soweit ich weiß auf einen riesigen Scenegraph setzen. Von derartigen Dingen hält man man im professionellen Bereich afaik schon seit längerem Abstand da einfach zuviel unötiger Overhead. Aus all diesen Gründen würd ich weder Ogre noch Irrlich als prototypisches Beispiel für eine moderne Engine mit gutem Design sehen. Natürlich kann dieser mein Eindruck, wie mehrmals erwähnt, mangels Erfahrung mit den beiden Engines auch falsch sein...

    0
  • ?

    Für OpenGL findet man heutzutage kaum mehr Libraries, die auch dafür aktualisiert werden. Leider. Selbst CEGUI ist nicht OpenGL 3.x fähig, was ungefähr DirectX10 entspricht. Zumindest benötigt man diese Karten um es zu nutzen. Ich denke mal es liegt einfach daran, dass die alten Methoden nach wie vor in den Treibern vorhanden sind bzw. funktionieren.

    Da ich derzeit meine ganze API auf OpenGL 3.x aufbaue, kann ich dir davon ein Liedchen singen. SDL als auch SFML hängen hinterher mit der Auswahl des Canvas. Die SVN Versionen können das zwar schon, aber die sind halt vom Release noch weit entfernt. Im Fall SFML in der Version 2 aus dem SVN ist es auch nur möglich ein Compability Profile zu erstellen, aber kein Core Profile.

    Da ich mit OpenGL 3 Core arbeite, muss ich jede Lib, die ich verwende, anpassen. Bei SFML war das relativ einfach auf ein Core Profile umzustellen und die Funktionen, die mir glError()s produzierten umzuschreiben. Allerdings nutze ich SFML auch nur als Platformunabhängigen Layer für Fenster und Sound etc und nutze keine der Zeichenfunktionen. Die habe ich alle selber erstellt. Selbst GLew musste ich anpassen, damit die Extension-Strings korrekt geladen werden.
    Ich häng den neuen Code mal an, falls es wen interessiert.

    Wie es Literaturmäßig um OpenGL bestellt ist, siehst du ja selber. Ich würde mich btw bei dem Verlag freundlich beschweren über diesen Umstand. Denn nur mit Rückmeldung können die auch was ändern - wenn sie denn wollen. Aber falls da so ein Autor dahinter sitzt wie ein gewisser JW, der eben nur nen paar Nehe Tutorials gelesen hat oder vor 10 Jahren mal kurz OpenGL gesehen hat, naja :p.

    RedPuma schrieb:

    Du solltest dir außerdem im klaren darüber sein dass OpenGL 3.x im nur von DirectX 10 Hardware voll unterstützt wird. Und ich sehe eigentlich keinen Grund warum ich mit der Radeon 9800 Pro aus meinem alten PC keine 2D Spiele spielen sollte 😉

    Es hat nichts damit zu tun, dass man User aussperren möchte. Nur wenn man eine Anwendung jetzt entwirft, ist es definitiv nicht falsch auch neueste Technik zu verwenden.

    dot schrieb:

    Dazu kommt dass beide Engines soweit ich weiß auf einen riesigen Scenegraph setzen. Von derartigen Dingen hält man man im professionellen Bereich afaik schon seit längerem Abstand da einfach zuviel unötiger Overhead.

    Könntest du das näher ausführen? Welche Techniken verwendet man denn aktuell?
    Wirkliches Interesse, kein Hintergedanke.

    Anhang:

    void NLWindowGL::dumpExtensions()
{   
    NLStringVector v;
    GLint num_extensions;
    GLubyte* p = NULL;
    glGetIntegerv (GL_NUM_EXTENSIONS, &num_extensions);
    for ( int i=0; i < num_extensions; i++ )
    {
        p = (GLubyte*) glGetStringi (GL_EXTENSIONS, i);
        if ( p )
            v.push_back((char*)p);
    }

    SystemController().getLog().printExtensions(v);
}
    0

  • Scorcher24 schrieb:

    dot schrieb:

    Dazu kommt dass beide Engines soweit ich weiß auf einen riesigen Scenegraph setzen. Von derartigen Dingen hält man man im professionellen Bereich afaik schon seit längerem Abstand da einfach zuviel unötiger Overhead.

    Naja Könntest du das näher ausführen? Welche Techniken verwendet man denn aktuell?
    Wirkliches Interesse, kein Hintergedanke.

    Hier gibts z.B. einen guten Artikel warum ein Scenegraph alles andere als optimal ist. Was man aktuell verwendet...naja zumindest nicht den einen Scene-Graph. Die Physik braucht eben z.B. komplett andere Strukturen als die Grafik die vermutlich sogar mehrere verschiedene haben wird (der Renderer will vielleicht einfache Objektlisten, die Visibility Detection dagegen irgendeine Spatial Structure). Ein ganz guter Artikel dazu ist z.B. der hier.

    0
  • R
    Mod

    dot schrieb:

    ...im professionellen Bereich afaik schon seit längerem Abstand ...

    eigentlich war dem auch noch nie so, frueher war es einfach zuu langsam um es ueberhaupt zu erwegen, spaeter fragte man sich, was das bringen sollte. es macht fuer kleinere firmen vielleicht sinn, weil es vom prorammieraufwand echt eine simple sache ist. nodes und allerlei von attachments dran, aber so wirklich sinn macht es nicht. gern wird genannt dass vieles in der welt voneinander abhaengt z.b. ein tisch hat sachen drauf und wenn man den tisch bewegt, sollten sich die sachen mitbewegen die drauf sind und deswegen sind sie "childs" vom tisch. aber was wenn ein stuhl mit je zwei beinen auf dem einen tisch und mit zweien auf den anderen gestellt wird und man will einen tisch bewegen, wessen child ist der stuhl?

    komplett abschreiben wuerde ich scenegraphs aber nicht, im kleinen scope machen die durchaus dinge einfacher, wenn man z.B. vorgefertigte assets haben moechte die eine gewisse hierarchy haben, sodass man eben den tisch mit allem drauf in der level platziert und auch verschieben kann ohne alle dinge drauf selektieren zu muessen.
    aber im finalen spiel wird man diese zusammenhaenge eher nicht mehr brauchen, von daher ein gutes editor feature.

    0

  • rapso schrieb:

    [...] von daher ein gutes editor feature.

    Natürlich, für Rapid-Prototyping oder einen Editor sind Szenengraphen praktisch (die meiste Modeling-Software arbeitet ja wohl auf so einer Basis). In einer richtigen Game-Engine hat sowas aber, wie du ja bestätigt hast, nichts verloren. Und die meisten (mir bekannten) General-Purpose Open-Source Engines sind nunmal Szenengraphen. Das ist natürlich schön einfach zu benuzten aber, wie gesagt, kein Beispiel dafür wie es "die Großen" wirklich machen...

    0
  • ?

    Ich habe hier noch eine Engine gefunden, die eigentlich nur auf das "neue" OpenGL aufbaut:
    http://www.linderdaum.com/home/index.php?title=Main_Page

    0
Anmelden zum Antworten