Ogre vs Irrlicht



  • Was sind die Vor- und Nachteile von Ogre bzw. Irrlicht

    Ich habe bisher nur mit Irrlicht vertiefte Erfahrungen, finde den Codingstyle angenehm und habe bisher lediglich ein raffinierteres GUI vermisst, sieht irgendwie aus, wie zu Zeiten von Win 3.11. 😃

    Für Anfänger ist Irrlicht sicher ein angenehmer Einstieg in die 3D-Grafikprogrammierung. Hier findet man Unterstützung:
    http://irrlicht.sourceforge.net/phpBB2/index.php?sid=95d413ce9007f8dd98aa65fe74802809



  • Was ist an Ogre3D denn schwer? Mit dem Example-Framework kann man schnell tolle Sachen zaubern. Und wenn es etwas mehr sein darf, dann kann man sich anschauen wie das Example-Framework aufgebaut ist und wie man Ogre initialisiert.
    IrrLicht habe ich noch nie benutzt, das was ich an Sample-Codes gesehen habe hat mir noch nie zugesagt.
    Angeblich soll IrrLicht aber ein saubereres Design haben..

    OpenSceneGraph wurde auch schon in kommerziellen Titeln eingesetzt (wie Ogre3D auch!), das an für sich heißt ja schonmal was. Ich habe es mir bisher nur kurz angesehen macht eigentlich einen ganz guten Eindruck.



  • IrrLicht habe ich noch nie benutzt, das was ich an Sample-Codes gesehen habe hat mir noch nie zugesagt.

    Warum?



  • Erhard Henkes schrieb:

    IrrLicht habe ich noch nie benutzt, das was ich an Sample-Codes gesehen habe hat mir noch nie zugesagt.

    Warum?

    Kurz: Geschmäcker sind verschieden

    Lang: Mir sagt der ganze Aufbau einfach nicht zu, das fängt schon bei dem Namensraum "irr" an. Ich mag einfach dieses Wortfragment nicht.
    Dann sehen die ersten paar Zeilen in den Tutorials so aus:

    using namespace irr;
    using namespace core;
    using namespace scene;
    using namespace video;
    using namespace io;
    using namespace gui;
    

    Das ist aus dem HelloWorld-Tutorial. Wir haben also einen globalen Namensraum "irr" welcher 5 weitere enthält.
    Nichts gegen Strukturierung im Code, aber man kann es auch übertreiben. Anscheinend geht es den Leuten beim benutzen ja selber auf den Geist, wenn sie erst einmal 6Namensräume in den globalen Namensraum holen.
    Ich glaub auch nicht, dass jemals jemand ernsthaft alles ausschreiben wird, also irr::core::createDevice() (das ist geraten, da die im Tutorial ja die Namensräume global einblenden weiß ich als Lernender natürlich nicht wo die Funktion nun hingehört).

    Du musst mich auch nicht bekehren zu Irrlicht zu wechseln, ich mag sie einfach nicht und so lange ich kein Geld für das Programmieren bekomme wähle ich die Engine die mir persönlich gefällt und das ist Ogre3D 🙂



  • Sieht tatsächlich aus, als würden Namespaces mit Packages in Java verwechselt worden sein.

    MfG SideWinder


  • Mod

    S.T.A.L.K.E.R. schrieb:

    Ich glaub auch nicht, dass jemals jemand ernsthaft alles ausschreiben wird,

    mal die erst beste zeile aus meinem code

    class CReader :	public NDionysos3::NDCore::NDipa::IDiPaDataRead
    

    ich hab nichts gegen namensroume, gibt aber auch vielle die sagen dass niemand fuer jede member auf die man von aussen zugreifen will nen accessor basteln wuerde oder allen ernstens ueberall c++ statt c casts nutzen wuerde oder const vor variabeln bzw an memberfunctions schreibt nur weil er die var nicht vor hat zu veraendern.

    wenn man sich mal an sowas gewohnt geht das voll automatisch und es ist durchaus nuetzlich.

    z.b. hab ich hier ein sdk dass verschiedene verhaltensweisen hat je nach namesspace

    also

    using namespace HERSTELLER::LIB::SICHER
    

    oder

    using namespace HERSTELLER::LIB::SCHNELL
    

    oder

    using namespace HERSTELLER::LIB::SCHNELL::INLINING
    

    (namen sind platzhalter weil die richtigen namen unter NDA stehen, sorry )

    ich finde somit namespaces ganz natuerlich und

    using namespace boost::spirit;
    

    find ich auch sehr natuerlich.



  • Jetzt wird die Argumentation aber wenig überzeugend. Auf dieser Ebene kann man fast alles in einem negativen Licht beleuchten. Namespaces sind schlicht und einfach ein wesentliches Element moderner C++-Programmierung, nicht mehr und nicht weniger. 😃
    Irrlicht hat diesbezüglich überigens einen sauberen Aufbau.



  • Namespaces sind 100% wichtig! Jede C++-Library die kein Namespace benutzt, gehört verbrannt! 😉

    Wie tief die Namespaces sind, ist dann aber wiederrum Geschmackssache. Mir pers. gefällt die Irrlicht-Namespace-Tiefe nicht, da ich es auch für Übertrieben halte. Wenn Irrlicht z.B. Soundfunktionen hätte, würde ich es dann verstehen, wenn es irrlicht::gfx und irrlicht::sound geben würde. Das halte ich pers. für einen guten Kompromiss. Aber den ganzen gfx-Kram auch noch mal aufzuteilen?

    Bei Boost ist es ja auch so: boost als Hauptknoten, darunter die strikte Library-Trennung. Aber nicht sowas: boost::filesystem::file und boost::filesystem::dir und boost::filesystem::commands . So in etwa ist es bei Irrlicht übertrieben worden.

    Aber diese Übertreibung muß ja nicht zwangsweise auf die letztendlich Qualität der Irrlicht-Engine schließen lassen?! 🙂



  • Aber diese Übertreibung muß ja nicht zwangsweise auf die letztendlich Qualität der Irrlicht-Engine schließen lassen?!

    Genau! Die Diskussion hier findet auf einem ziemlich niedrigen Niveau statt. 🙄

    Nur um zu zeigen, wie ein solcher Vergleich an anderer Stelle läuft:
    http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=29741

    ... and the two finalists were OGRE and Irrlicht, mostly for reasons of code structure and the general purpose orientation of the frameworks. OGRE because it is superlatively feature-rich and mature, and Irrlicht for its sleekness and design aesthetics. I then decided to go with Irrlicht. ...


  • Administrator

    Hmmm, mit OpenSceneGraph oder G3D hat in dem Fall hier noch niemand gearbeitet?

    Grüssli


Anmelden zum Antworten