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

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

  • 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