What Irrlicht has over Ogre...

[agi_shi]

What's your problem?

I count:
- the OIS dll (I can switch input systems easily, not forced to use one)
- the OgreMain dll (um... you use ogre, you use OgreMain)
- the CG dll (I want to use Nvidia's "C for Graphics", I have to use the dll)
- the Newton dll (want to switch physics, easy)
- the D3D renderer dll (want a different rendering system, switch the dll)

Irrlicht is way too "packed all into one" for my liking. I want a different gui? I'm fucked. I want a different input system? I'm fucked. Etc.

My current does not load media if it doesn't need to. Don't get confused by the huge media folder of the demos. Ogre needs no media other than what you need. I use no plugins file (load them based on what my levels need), no config file (all customized so the user choosed configuration options), and no log file (use my own custom gfx.log file).

Also, there is a VERY good tutorial that doesn't use ExampleApplication, which loads a poop-load of plugins and media and what-not. Go to the Ogre wiki tutorials, and look for "developer picks" or something like that, under Articles. Look for "Practical Application".

Ogre is not as simple as "make a device, make stuff, render". Why? Because it lets you configure to your heart's desire. Read the above article and you'll easily see. Sure, you can make an FPS camera and a BSP level in Irrlicht with what, 2 lines? But what's next, huh? How do you turn that into a game?

[Saturn]

Don't overdo it.

Just because GUI and input are included into Irrlicht, doesn't meant you have to use them. You can use your own GUI with Irrlicht too, like e.g. cegui and you can use your own input, like e.g. OIS/SDL.

[agi_shi]

Don't overdo it.

Just because GUI and input are included into Irrlicht, doesn't meant you have to use them. You can use your own GUI with Irrlicht too, like e.g. cegui and you can use your own input, like e.g. OIS/SDL.

You're right...

Let me rephrase... what I'm trying to say is that Irrlicht integrates best when you use it's built-in functionality... hm... you know, obviously implementing a different input system over the internal one won't be as pretty as not having an input system to start with. Know what I'm saying? Last time I checked, I couldn't say: Irrlicht, don't create anything input-related, I'll handle it myself...




To everyone saying they need a good tutorial for Ogre, because the others are too "complicated"... I'll share part of my open-source engine here:

Code: Select all

struct OgreCore {
            Ogre::Root *root;
            Ogre::RenderWindow *window;

            Ogre::LogManager *logMgr;
            Ogre::MaterialManager *materialMgr;
            Ogre::MeshManager *meshMgr;
            Ogre::TextureManager *textureMgr;
            Ogre::ResourceGroupManager *rcGroupMgr;

            OgreCore(): root(NULL), window(NULL) {
                root = new Ogre::Root("", "", OGRE_LOG_NAME);

                logMgr = Ogre::LogManager::getSingletonPtr();
                materialMgr = Ogre::MaterialManager::getSingletonPtr();
                meshMgr = Ogre::MeshManager::getSingletonPtr();
                textureMgr = Ogre::TextureManager::getSingletonPtr();
                rcGroupMgr = Ogre::ResourceGroupManager::getSingletonPtr();
            }

            ~OgreCore() { delete root; }

            Renderer renderer;
        };

        struct OISCore {
            OIS::InputManager *oisInputMgr;

            // (custom) input manager singleton for registering input listeners
            InputManager *inputMgr;

            // names get a bit confusing, but that's what namespaces are for =)

            OIS::Keyboard *keyboard;
            OIS::Mouse *mouse;

            OISCore(unsigned long windowHandle) {
                /*OIS::ParamList wH;
                wH.insert(
                    OIS::ParamList::value_type(
                        "WINDOW", Ogre::StringConverter::toString(windowHandle)
                    )
                );*/

                oisInputMgr = OIS::InputManager::createInputSystem((size_t)windowHandle);

                keyboard = (OIS::Keyboard*)oisInputMgr->createInputObject(OIS::OISKeyboard, true);
                mouse = (OIS::Mouse*)oisInputMgr->createInputObject(OIS::OISMouse, true);

                // create custom input listener, attach it to keyboard and mouse
                // and allow multiple custom listeners

                // ogre's singletons must be created via constructor once
                // and then access by getSingleton[Ptr]()
                // in this case, we make a new InputManager here
                // and delete it in the constructor
                inputMgr = new InputManager();
                keyboard->setEventCallback(inputMgr);
                mouse->setEventCallback(inputMgr);

                //const OIS::MouseState &mouseState = mouse->getMouseState();
                //mouseState.width = 640;
                //mouseState.height = 480;
            }

            ~OISCore() {
                delete inputMgr;

                oisInputMgr->destroyInputObject(mouse);
                oisInputMgr->InputManager::destroyInputObject(keyboard);

                OIS::InputManager::destroyInputSystem(oisInputMgr);
            }
        };

Code: Select all

Core(Renderer r = D3D);
        ~Core();

        Ogre::RenderWindow *createWindow(
            WindowParams *windowParams = NULL
        );

Code: Select all

// initialize ogre
    ogre = new OgreCore();

    // parse directory file and add resource locations
    ogre->rcGroupMgr->addResourceLocation(
        DATA_DIR, "FileSystem", "General"
    );

    std::ifstream dirFile((DATA_DIR + DATA_DIR_FILE).c_str());
    if (dirFile.good()) {
        Ogre::String dir = "";
        while (dirFile >> dir) {
            ogre->rcGroupMgr->addResourceLocation(
                DATA_DIR + dir + "/", "FileSystem", "General"
            );
        }
        dirFile.close();
    }

    ogre->renderer = r;

    // if we want to render, check which one
    if (r != NONE) {
        switch (r) {
            case D3D:
                ogre->logMgr->logMessage("*-*-* Loading D3D9 Renderer *-*-*\n");

                #ifdef _DEBUG
                ogre->root->loadPlugin("RenderSystem_Direct3D9_d");
                #else
                ogre->root->loadPlugin("RenderSystem_Direct3D9");
                #endif
            break;

            case GL:
                ogre->logMgr->logMessage("*-*-* Loading GL Renderer *-*-*\n");

                #ifdef _DEBUG
                ogre->root->loadPlugin("RenderSystem_GL_d");
                #else
                ogre->root->loadPlugin("RenderSystem_GL");
                #endif
            break;
        }

        // set a render system and initialize it
        Ogre::RenderSystemList *renderSystems = ogre->root->getAvailableRenderers();
        // use the first one
        Ogre::RenderSystem *rSys = *(renderSystems->begin());
        ogre->root->setRenderSystem(rSys);

        // now just initialize (no default window!)
        ogre->root->initialise(false);

        // load the cg program manager
        // it works for both renderers
        #ifdef _DEBUG
        ogre->root->loadPlugin("Plugin_CgProgramManager_d");
        #else
        ogre->root->loadPlugin("Plugin_CgProgramManager");
        #endif
    } else ogre->logMgr->logMessage("*-*-* No renderer loaded, gfx not available.\n");

    // obviously if we didn't fall into that if statement,
    // ogre won't be initalized for rendering

    // techniqually, we can't create any input objects
    // before we have a window.  so, set OIS to null
    // for now
    ois = NULL;

Code: Select all

Ogre::RenderWindow *Core::createWindow(Core::WindowParams *windowParams) {
    if (ogre->renderer == NONE) {
        ogre->logMgr->logMessage("*-*-* Attempted to create window without a renderer...\n");
        return false;
    }

    Core::WindowParams::iterator fI = windowParams->find("file");
    if (fI != windowParams->end()) {
        Ogre::ConfigFile videoSettings;
        videoSettings.loadFromResourceSystem(fI->second, "General");

        Ogre::ConfigFile::SettingsMultiMap *settings = NULL;

        Ogre::ConfigFile::SectionIterator section = videoSettings.getSectionIterator();
        while (section.hasMoreElements()) {
            if (section.peekNextKey() == "video") {
                settings = section.getNext();
                break;
            }

            section.moveNext();
        }

        if (settings) {
            Ogre::ConfigFile::SettingsMultiMap::iterator setting = settings->begin();

            for ( ; setting != settings->end(); ++setting)
                windowParams->operator [](setting->first) = setting->second;
        }

        //Ogre::ConfigFile::SettingsIterator sI = videoSettings.getSettingsIterator("video");
        //while(sI.hasMoreElements())
        //    (*windowParams)[sI.peekNextKey()] = sI.getNext();
    }

    Core::WindowParams::iterator i;
    int w = DEFAULT_W, h = DEFAULT_H;
    bool fullscreen = false;
    Ogre::TextureFilterOptions filtering = Ogre::TFO_NONE;
    int anisotropy = 0;

    if ((i = windowParams->find("width")) != windowParams->end())
        w = Ogre::StringConverter::parseInt(i->second);

    if ((i = windowParams->find("height")) != windowParams->end())
        h = Ogre::StringConverter::parseInt(i->second);

    if ((i = windowParams->find("fullscreen")) != windowParams->end())
        fullscreen = Ogre::StringConverter::parseBool(i->second);

    if ((i = windowParams->find("tex_filtering")) != windowParams->end()) {
        if (i->second == "anisotropic") filtering = Ogre::TFO_ANISOTROPIC;
        else if (i->second == "trilinear") filtering = Ogre::TFO_TRILINEAR;
        else if (i->second == "bilinear") filtering = Ogre::TFO_BILINEAR;
    }

    if ((i = windowParams->find("anisotropy")) != windowParams->end())
        anisotropy = Ogre::StringConverter::parseInt(i->second);

    Ogre::String rtName = "OgreCore::window";
    if ((i = windowParams->find("rtName")) != windowParams->end())
        rtName = i->second;

    ogre->logMgr->logMessage(
        Ogre::String("*-*-* Creating window at ") +
        Ogre::StringConverter::toString(w) + Ogre::String("x") +
        Ogre::StringConverter::toString(h) + Ogre::String(" *-*-*\n")
    );

    ogre->window = ogre->root->createRenderWindow(
        rtName, w, h, fullscreen, windowParams
    );

    ogre->materialMgr->setDefaultTextureFiltering(filtering);
    ogre->materialMgr->setDefaultAnisotropy(anisotropy);

    // now that we have a window, create our input system

    // get handle to window
    unsigned long windowHandle;
    ogre->window->getCustomAttribute("WINDOW", &windowHandle);

    // create OIS core
    ois = new OISCore(windowHandle);

    return ogre->window;
}

That should be enough to show you a "simple" Ogre.

Code: Select all

v01dEngine::Core core(v01dEngine::D3D);

// creature camera/viewport/scene manager, render

Why is the whole camera/viewport/scene manager stuff outside of the core? Because Ogre supports multiple different ones of the. You aren't dictated to one scene manager.

License:

Code: Select all

/*

    Copyright (C) 2007 nu11 & v01d pr0duc+!0ns

    This software is provided 'as-is', without any express or implied
    warranty.  In no event will the authors be held liable for any damages
    arising from the use of this software, including the melting and/or exploding
    of your computer.

    Permission is granted to anyone to use this software for any purpose
    and to alter it and redistribute it freely, subject to the following restrictions:

    1.  The origin of this software must not be misrepresented; you must not
        claim that you wrote the original software. If you use this software
        in a product, an acknowledgment in the product documentation is required.

    2.  Altered source versions must be plainly marked as such, and must not be
        misrepresented as being the original software.

    3.  You may not make any money from this software, i.e., you may not use
        it in commercial applications.

    4.  This notice may not be removed or altered from any source distribution.

*/

It's found in every file, but I didn't post my whole files. So, yeah.

[BlindSide]

Thanks, im grateful.

[monkeycracks]

I can feel the simplicity.


Edit :

The above was sarcasm to the extreme.

[rooly]

wow, after reading thru all that ogre stuff...

irr::IrrlichtDevice* device = irr::createDevice();

just seems overly complex. i guess i'll switch to ogre now.

also, just thought about it, i must admit this isn't my favorite part of irrlicht.
my favorite part is this: the licence.

irrlicht = anything anywhere at anytime by anybody.
ogre = experienced programmers with paid-for time and no willingness to use the idea of "open source" to its full capacity.
for the most part, anyway...

[Saturn]

ogre = experienced programmers with paid-for time and no willingness to use the idea of "open source" to its full capacity.

Care to explain? Sounds very wrong to me. There are many open source projects, both using Ogre and extending it. Actually probably more than for Irrlicht, at least this is my impression from a short visit to Ogre showcase/using in practice forum and wiki and comparing it to Irrlichts project announcement forum and Irrlicht's wiki.

btw, agi_shi, your example is unnecessarily complex, you're not prooving your point with it.

[rooly]

alright, i admit, that was a bit uncalled for.

however it does get mighty tiring to have some ogre-god-all-mighty come in here every month or so, find a thread asking "hey, what do you guys think about irrlicht versus ogre" and start posting how much ogre is better.

once again, irrlicht's strengths, in my opinion far outweight ogre's for the single reason that, if that previous code was any example, or any of the official examples for that matter, i can do 90% of any ogre code in one or two lines with irrlicht.

our friend keeps going over the idea that irrlicht is only so deep. you can only use those two lines, and after that, your out of options. We all, on these forums, know for a fact that thats a complete lie. I agree, loading a level mesh, then placing an FPScam is not much of a game, but damn it takes alot less code than it does in ogre.

I'm pretty sure everyone here has taken a look at both engines. I know i did. I've been here for two years now, hell i even tried crystal space. Irrlicht is just as extensible, if not more, than any of the other major OSS 3d engines out there for the simple fact that, "hey...i wanna change this, how much work will it take?" well, honestly you can change irrlicht anyway you want, and hell, redistribute it however you want. but the answer, quite frankly is alot of work. but your file will still be smaller than any other engine. let me ask this, how large is the core ogre redistributable? i know the answer for irr: 1.5MB for msvc, 2-3MB for gcc.

another point, i've noticed that ogre loves its little singletons. have any of you ever thought about the reprocussions of a singleton? you get one and only one object to work with, and thats it. maybe you think you'll be able to do alot, but it can be very limiting, see if you can figure that out on your own. also, the use of new and delete in a library is simply ugly. irrlicht seems to be much more mature in this idea, because it keeps the user from having to excessively handle dynamic pointers. in a small to medium sized project you may never see "new" at all, which in my opinion is quite nice.

i apologize. i'm beginning to rant a little. can i simply ask that we stop having these discussions? the answer you would get from an ogre forum concerning irrlicht is "its too young" "its not complete" "ogre is more powerful" (i know this for a fact so don't dispute it.) the answer you get from an irr forum concering ogre is usually "irr is easier, but ogre is probably more powerful" "i use irr cause its easy and the community is great". guess what that means: I WANT EASY 3D! the learning curve for blender is steep enough, throw in ogre and you have a year just to get the basics. no one here disputes that ogre is more powerful in the long run on powerful hardware. can ogre run on an old nvidia tnt2 tho? i don't think it can.

well, i fell victim as well. i ask one final thing before i begin ignoring this damn thread. can we PLEASE DELETE THIS THREAD.

[Saturn]

however it does get mighty tiring to have some ogre-god-all-mighty come in here every month or so, find a thread asking "hey, what do you guys think about irrlicht versus ogre" and start posting how much ogre is better.

Completely right. I don't like it either. agi_shi seems to be out on a mission here. But after things are said, I feel the urge to correct them to my knowledge and learn, if others made different experiences.

once again, irrlicht's strengths, in my opinion far outweight ogre's for the single reason that, if that previous code was any example, or any of the official examples for that matter, i can do 90% of any ogre code in one or two lines with irrlicht.

No it isn't, no you can't. The implication doesn't work, because the premise is wrong. The code posted is overly complex for what it does. Everyday jobs are almost equally easy with Irrlicht having the lead here, if only by little.

our friend keeps going over the idea that irrlicht is only so deep. you can only use those two lines, and after that, your out of options. We all, on these forums, know for a fact that thats a complete lie. I agree, loading a level mesh, then placing an FPScam is not much of a game, but damn it takes alot less code than it does in ogre.

Agreed partly. Yes Irrlicht is deeper than that, but Irrlicht is nevertheless lacking in many areas when comparing to the flexibility of Ogre. (Materials, Vertex format, Shadows, to name just three areas.) If the FPS camera scene node is enough for you, then use it sure, but it isn't enough if you want to make it feel good, because it doesn't.

I'm pretty sure everyone here has taken a look at both engines. I know i did. I've been here for two years now, hell i even tried crystal space. Irrlicht is just as extensible, if not more, than any of the other major OSS 3d engines out there for the simple fact that, "hey...i wanna change this, how much work will it take?" well, honestly you can change irrlicht anyway you want, and hell, redistribute it however you want. but the answer, quite frankly is alot of work. but your file will still be smaller than any other engine. let me ask this, how large is the core ogre redistributable? i know the answer for irr: 1.5MB for msvc, 2-3MB for gcc.

Redistribution size is out of question. Irrlicht is much smaller, but not by the factor stated in the first post. This is imho a common Irrlicht forum specific urban legend. Ogre is smaller than it is often believed and it doesn't, contrary to the rumor, need any external configuration files. At least form Windows applications, whether you distribute 1.5MB + assets or 6MB + assests is next to irrelevant. Since the assests will be the fatter part anyway. And in cases where memory is more valuable, Irrlicht is at an advantage, yes.

As for the extensibility, imho you are wrong. Sure, you can rip Irrlicht open and change its source. But isn't it better to just use the stubs provided by the engine without changing it internally? Here is where the (imho) more flexible internal design of Ogre kicks in. In order to add a new feature you often don't have to change the engine, you just *use* it. Ogre has stubs for adding extensions in almost every part of it, every rendering aspect can be customised.
Also most proposed extensions for Irrlicht just implement things that are already implemented in Ogre or can be done by using it.

another point, i've noticed that ogre loves its little singletons. have any of you ever thought about the reprocussions of a singleton? you get one and only one object to work with, and thats it. maybe you think you'll be able to do alot, but it can be very limiting, see if you can figure that out on your own. also, the use of new and delete in a library is simply ugly. irrlicht seems to be much more mature in this idea, because it keeps the user from having to excessively handle dynamic pointers. in a small to medium sized project you may never see "new" at all, which in my opinion is quite nice.

This doesn't make sense to me. The very reason to use singleton is to make sure that there is only one instance. This is done for classes, which the engine relies on, that there is only one of. It is a design tool. I'm not a fan of Singleton for other reasons, but this use is true to what it is for.
As for new/delete: First, you don't use new/delete in Ogre either much. I am a bit surprised you mention it here, as I am not aware of many cases where you do this. Second, what do you think Irrlicht does internally when you call ISceneManager::addXySceneNode? Irrlicht as well uses the new operator internally to create an instance of it. The difference between both in terms of memory allocation strategy is negligible. This will change this summer though, when Ogre gets a more sophisticated manager for this (still defaulting to new/delete)

i apologize. i'm beginning to rant a little. can i simply ask that we stop having these discussions? the answer you would get from an ogre forum concerning irrlicht is "its too young" "its not complete" "ogre is more powerful" (i know this for a fact so don't dispute it.) the answer you get from an irr forum concering ogre is usually "irr is easier, but ogre is probably more powerful" "i use irr cause its easy and the community is great". guess what that means: I WANT EASY 3D! the learning curve for blender is steep enough, throw in ogre and you have a year just to get the basics. no one here disputes that ogre is more powerful in the long run on powerful hardware. can ogre run on an old nvidia tnt2 tho? i don't think it can.

well, i fell victim as well. i ask one final thing before i begin ignoring this damn thread. can we PLEASE DELETE THIS THREAD.

Please do not delete this thread (or any other for this matter). Simply because deleting threads just looks as if someone has something to hide. Irrlicht doesn't. Yep, it is annoying, that all the time someone has to start an argument about it, but the sensible thing is to lead the whole discussion into rational grounds till it dies. When something is posted everyone can agree to, then it is a help for people looking into the available engines deciding what they need.

[rooly]

thanks, saturn, for being the only sensible person here.

[agi_shi]

I don't see your guys' problems. You wanted a full snippet of code that used PURE Ogre, and no ExampleApplication bullshit. I gave you it.

You want simple Ogre? Fine:

Code: Select all

// you must have a plugins.cfg file that has the names of all the plugins
// you want to use

// an ogre.cfg file which defines the rendering options of ogre

Ogre::Root *root = new Ogre::Root("plugins.cfg", "ogre.cfg", "gfx.log");
root->restoreConfig();
root->initialise(true);

Done. You've got an auto-created window. Just call "createSceneManager()" and you're done with the scene manager. Call "createCamera()" and you've got a camera. Done.

Make a loop, call root->renderOneFrame() every frame. You've just fully integrated Ogre in ~10 lines, hoorah!

What I'm saying, is that the above initializing of Ogre is just as pathetic as Irrlicht's "createDevice()". You automatically create everything without any control other than width, height, bpp, and title, etc..

I can break down my code snippet so you see why I do everything the way I do:
(simple - if you want a more complex explanation, tell me)
- create a root and initialize it without use any default files (thus the "" parts)
- load a plugin based on what the user chooses for the render system
- get the render system, set it
- parse a huge map of options, and give the ability for parsing it from a custom file
- create a custom window
- get the window's handle and create the open input system manager with it
- create a keyboard and mouse object from the OIS manager

That's all there is to it, really. But you get extremely fine control over everything. Don't want GL? The core won't load it. Don't want any seperate scene managers? The core won't load them.

Singletons: I love them. Especially the way Ogre handles them. You construct one just the way you want (using it's constructor - no "CreateInstance()" crap). Then, whenever you want it, getSingleton(). Tada. Managers are practically the only ones who use this (in addition to Root). I have no idea why you'd want 2 mesh managers, for example. Or 2 material managers, or 2 roots or something stupid like that. I use them extensively, too. I only need 1 PortalManager. 1 ScreenshotManager. 1 PhysicsManager.



Here, let you in on something. My collision converter tool uses Irrlicht. No graphics, just loads the mesh and gets the vertices in a completely straight-forward manner. Ogre is overly complex for getting vertices (for obvious reasons, though ), and it only supports .mesh.

[monkeycracks]

What I'm saying, is that the above initializing of Ogre is just as pathetic as Irrlicht's "createDevice()". You automatically create everything without any control other than width, height, bpp, and title, etc..

I'm sorry, I fail to see what else you would want to have control of in a window. I assume the etc. covers rendering API, fullscreen or not, vsync..

Another thing :
Why the hell are you on Irrlicht forums if you use Ogre and only want to glorify its simplicity with a complex code snippet?

[agi_shi]

What I'm saying, is that the above initializing of Ogre is just as pathetic as Irrlicht's "createDevice()". You automatically create everything without any control other than width, height, bpp, and title, etc..

I'm sorry, I fail to see what else you would want to have control of in a window. I assume the etc. covers rendering API, fullscreen or not, vsync..

Another thing :
Why the hell are you on Irrlicht forums if you use Ogre and only want to glorify its simplicity with a complex code snippet?

Because I used to use Irrlicht and I still do for tools. I found these threads, and as I switched to Ogre and used it, I thought I'd share my experience.

And there's a lot of custom stuff to be done. A LOT A LOT. Go to the Ogre docs and read up on Ogre::Viewport, Ogre::RenderWindow, Ogre::Root, Ogre::SceneManager, and Ogre::Camera.

[BlindSide]

Look guys, Id hate to go against your opinions but agi_shi has a point. Sure maybe he is taking it a bit far, on this Irrlicht forum of all places. But its correct that the more code you need to initialize the engine, the more control you have over it and the better chance you have (If you are experienced enough) to achieve a more desired result.

Offcourse we are all still using Irrlicht, because if we wanted the maximum control we would just make our own engine using pure DirectX, or we can use OGRE which is maybe a little inbetween (Or not because apparently you can still do the normal uncontrolled initialization if you chose to.).

Personally Im fine using Irrlicht, because I feel familiar and confident enough with it to utilize its lenient license to its full extent, adding new features and support whenever I need it. In the end I found the structure is not very hard to modify, and is fairly clean and transparent. Need clipplanes, multipass, vertex buffers, just slap em on and your done. Its a little more work than just using Ogre for someone that is used to Ogre, but for me this way is easier.

Also I want to comment on your "Irrlicht re-inventing the std class", this is obviously an advantage, just are the Irrlicht typedefs (u32, s16 etc) as they allow for maximum portability accross all systems. Irrlicht has been ported to many platforms, some embedded ones, xbox, psp, etc, and some of this is thanks to its all-in-one idealism that is supposed to run as a self-sustained module (More or less). I would like to you to keep in mind that the Irrlicht implementations are often better than the std, the array class being superior to std::vector in some ways, and general functions like atof are up to 5 times faster than standard os implementations.

Either way, I don't think anyone here has a right to say Irrlicht is better than Ogre, because thats simply not true (Offcoures thats because its an OPINION and not a FACT, so true or false does not apply).

agi_shi you have to understand many of these people (including me maybe) are acting on emotion, we have a great friendly close packed community here, and Irrlicht is what we stand for and what makes us proud. This is significantly different to someone who wishes to complete a project and is searching for the best engine for the job in a non-biased manner. Someone already mentioned this, and I would hate to repeat it but it seems people arent getting the point. Different solutions are appropriate for different situations, and so not any one piece of software is better than another for any given situation.

Cheers

[JRowe47]

The whole idea of which is better is missing the point entirely. The point is using the right tool for the job. Irrlicht is a two ton gorilla as far as open source 3D engines go... and Ogre is a 5 ton gorilla. It's harder to feed and requires more effort to make it sing and dance, but it has some more impressive features.

Irrlicht is still a simpler system, but has better performance than script-based systems, so it's a happy medium for developers.