C++ Community

Gast

hey
es gibt ja in der FAQ schon einige Themen, bei denen die
Vor- und Nachteile von DirectX bzw. OpenGL besprochen werden.
So etwas wäre doch auch für Enginen hilfreich oder nicht?

Also...
Mit welcher Engine programmiert ihr und
warum habt ihr euch für diese entschieden?
Was sind die Vor- und Nachteile von Ogre bzw. Irrlicht
(es dürfen auch andere genannt werden)

Ich freue mich schon auf eure Antworten.
Viele Grüsse
Melan

Code-Walker

Irrlicht:

Sehr Anfängerfreundlich und schnell zu lernen. Man kann mit nur Wenigen Funktionen Komplexe dinge erstellen, wie ein Terrain oder Animierte Modelle laden! Leider ist der Umfang und die eigencreativität stark eingeschrängt, so kann man beispielsweise kein Multitexturing anwenden, wenn man keinen Shader dafür schreibt! Irrlicht ist noch nicht weit genug entwickelt um ein größeres und umfangreiches Spiel zu entwickeln!

Ogre3D:

Ogre ist schwerer zu erlernen als Irrlicht, dafür ist der Funktionsumfang und die möglichkeiten zu eigencreativität riesig! Multitexturing, Terrain, LOD, alles was man sich wünscht! Viele größere und bekannte spiele wurden mit Ogre gemacht. Ogre ist ebendfalls auch gut für adere Dinge ein zu setzen, nicht nur für Spiele!

Als anfänger sollte man sich zuerst mit Irrlicht beschäftigen, und wenn dies nicht mehr ausreicht, kann man auf Ogre umsteigen!

Dravere

Melan schrieb:

(es dürfen auch andere genannt werden)

Vielleicht könnte jemand auch etwas zu den folgenden zwei sagen, würde mich persönlich auch noch interessieren, ob jemand Erfahrungen damit gemacht hat:
OpenSceneGraph: http://www.openscenegraph.org/projects/osg
G3D Engine: http://g3d-cpp.sourceforge.net/index.html

Von OpenSceneGraph kenne ich näher nur, dass ein MMOG dies neu einsetzt und die Entwickler scheinen sehr zufrieden zu sein.
Beim anderen bin ich mal drüber gestolpert.

Grüssli

Erhard Henkes

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

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

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.

Erhard Henkes

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

Warum?

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

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

SideWinder

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

MfG SideWinder

rapso

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.

Erhard Henkes

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.

Artchi

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?!

Erhard Henkes

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. ...

Dravere

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

Grüssli

Ogre vs Irrlicht