Are these enough engines?

[rogerborg]

Subjective anecdote:

It took me less time to integrate Irrlicht, rebuild and make my first source modification to Irrlicht as part of an existing app than it did to figure out how to write a Hello World using Ogre.

[twilight17]

Subjective anecdote:

It took me less time to integrate Irrlicht, rebuild and make my first source modification to Irrlicht as part of an existing app than it did to figure out how to write a Hello World using Ogre.

QFT!

and just to get a blank screen with ogre its over 50 lines of code. Also, they tell you to use an "ExampleApplication.h" That makes everything really slow. Oh! and they only support Ogre's .mesh format (which sucks)

[Kojack]

Not trying to start an argument or anything, just a couple of clarifications:

and just to get a blank screen with ogre its over 50 lines of code.

12 lines of code, and that includes
- normal cpp stuff (include, main, return 0 at the end, etc)
- user selection of screen resolution, modes and renderer, including loading and saving of settings to a config file
- making a camera and viewport
- selecting the Octree scene manager
- rendering a blank window
- not counting lines with just braces

Also, they tell you to use an "ExampleApplication.h" That makes everything really slow.

Actually, the standard advice is to not use ExampleApplication.h. It's used in most of the beginning tutorials and in the demos, but after that most people move on to something like the Practical Application tutorial or just write their own (which is pretty easy).

[rogerborg]

Note that I included "figure out" in my calculations. Note also that if the ExampleApplication provides an "example" of how not to write an "application" then it may not be doing the best job.

[Kojack]

True, it's probably time for exampleapplication.h to be replaced.

There's nothing really wrong with it as such, it's just not as flexible as if you want to do everything manually (like use your own main loop instead of having a callback style frame listener). I'm sure people on here don't look at the examples which come with the irrlicht download and assume that since 14 of the 16 examples use the console to select the renderer every time they are run, that's how all irrlicht software should be written. The larger demo uses the gui instead, a better method but the code is probably more confusing to a beginner than simple console stuff.

[Saturn]

I remember that Sinbad always stated how low-priority changing example application is. And rightly so. But nevertheless it is ugly and it is not persuasive advertising for the engine itself.
While the samples themself look still more convincing than Irrlicht ones, the source code causes eye cancer. And it is cause for one of the more persistent rumors about Ogre, namely that it supposedly needs lots of strange files to work, like plugins.cfg, resources.cfg etc, etc.

Anyway, like most other similiar threads, this one also contains factual errors:
Cassini, Halifax, that Irrlicht has just the same features as Ogre (save for hardware buffers) is simply not true. And repeatition of this statement doesn't make it any more true.

And if you count changing Irrlicht source itself, well you can prove anything with that. Arguing like this causes Irrlicht to be on par with Unreal engine in every aspect, because something that is missing can be added with just writing a parser here or a handler there...

Making Irrlicht support the same flexibility as Ogre regarding materials, requires more than just writing a parser, simply because Irrlicht core doesn't support all the material features and generic multipass rendering.
The shader callbacks are quite uncomfortable and don't support everything Ogre does. And even the very cool shadow work of BlindSide pales compared to the flexibility and universality of Ogre's shadow support.

No mesh format supported by Irrlicht has the wide range of animation types supported by Ogre and the flexibility of Ogre's animation API.

How often do people write here: "It is just a question of the art, with nice art every engine looks good.", but you somehow have to get the art into the engine. And this is currently easier with Ogre.


I might have never said it before (and I should have after the split-off with Spintz and sio2), but I have the greatest respect of hybrid's, bitplane's and Luke's work for the engine. They have done a way better job than I can ever hope to achieve in this regard. (doing something very different in my daylight job anyway) And they are steering the work on the engine in the right direction. Expanding without giving up the ease-of-use and without going head-over-heels, blindly chasing the latest hot in-feature (*cough* 3demon *cough*) Still, facts are facts, and seeing another engine I have quite fond memories of, being misrepresented by other users who clearly operate over the limits of their knowledge is annoying and it is helping no one.

[Halifax]

I remember that Sinbad always stated how low-priority changing example application is. And rightly so. But nevertheless it is ugly and it is not persuasive advertising for the engine itself.
While the samples themself look still more convincing than Irrlicht ones, the source code causes eye cancer. And it is cause for one of the more persistent rumors about Ogre, namely that it supposedly needs lots of strange files to work, like plugins.cfg, resources.cfg etc, etc.

Anyway, like most other similiar threads, this one also contains factual errors:
Cassini, Halifax, that Irrlicht has just the same features as Ogre (save for hardware buffers) is simply not true. And repeatition of this statement doesn't make it any more true.

And if you count changing Irrlicht source itself, well you can prove anything with that. Arguing like this causes Irrlicht to be on par with Unreal engine in every aspect, because something that is missing can be added with just writing a parser here or a handler there...

Making Irrlicht support the same flexibility as Ogre regarding materials, requires more than just writing a parser, simply because Irrlicht core doesn't support all the material features and generic multipass rendering.
The shader callbacks are quite uncomfortable and don't support everything Ogre does. And even the very cool shadow work of BlindSide pales compared to the flexibility and universality of Ogre's shadow support.

No mesh format supported by Irrlicht has the wide range of animation types supported by Ogre and the flexibility of Ogre's animation API.

How often do people write here: "It is just a question of the art, with nice art every engine looks good.", but you somehow have to get the art into the engine. And this is currently easier with Ogre.


I might have never said it before (and I should have after the split-off with Spintz and sio2), but I have the greatest respect of hybrid's, bitplane's and Luke's work for the engine. They have done a way better job than I can ever hope to achieve in this regard. (doing something very different in my daylight job anyway) And they are steering the work on the engine in the right direction. Expanding without giving up the ease-of-use and without going head-over-heels, blindly chasing the latest hot in-feature (*cough* 3demon *cough*) Still, facts are facts, and seeing another engine I have quite fond memories of, being misrepresented by other users who clearly operate over the limits of their knowledge is annoying and it is helping no one.

It appears that you formed quite a few misconceptions about my previous post. I clearly stated that there is much more to it than just hardware buffers, 32-bit indices, etc.

And in the end I concluded with saying that it depends on a lot more than just the engine. Irrlicht vs. Ogre is just like C++ vs. Java, everyone is a protagonist for the language that they feel closet to, but in the end each one has its use for some problem.

Tapping on the fact of example application, it does in fact create a few gray areas in a beginner's understanding of what is really needed to make an Ogre application. According to those tutorials, Ogre appears much more easier then it truly is.

Your analogy to my argument of integrating material scripts etc., was sadly off point. Comparsion of Irrlicht to the Unreal Engine is not even possible first of all for the shear fact Irrlicht is only a rendering engine, while the comparison of Irrlicht to Ogre is very real. Don't go forming ridiculous analogies of the solutions that I pose. By material scripts I was suggesting the manipulation of Irrlicht materials, independent of the core application.

[cassini]

@Saturn dude you wrote a lot of nonsense there.
You talk about facts and you prove zero. I stand by what I said.
I am going to go in a ledge here and say you are an Ogre user.

[hybrid]

@Saturn dude you wrote a lot of nonsense there.
You talk about facts and you prove zero. I stand by what I said.
I am going to go in a ledge here and say you are an Ogre user.

I'd say you try to talk about things you don't understand. But that's only my first impression, let's see the proofs:
- When you talk about facts you don't need proofs. Otherwise, facts wouldn't be facts. They are proven.
- Your other post contains just as less contents as your last one. I only saw unproven gossip (which you might have taken from some other threads without even understanding it, but that's also just my impression). So why do you ask for proofs without giving them yourself. And don't say that just because you get access to the native gfx driver you can do everything with a render engine. In that case you wouldn't need any engine at all.

[hybrid]

I might have never said it before (and I should have after the split-off with Spintz and sio2), but I have the greatest respect of hybrid's, bitplane's and Luke's work for the engine. They have done a way better job than I can ever hope to achieve in this regard. (doing something very different in my daylight job anyway) And they are steering the work on the engine in the right direction. Expanding without giving up the ease-of-use and without going head-over-heels, blindly chasing the latest hot in-feature

Thanks a lot, Saturn. Your contributions are always appreciated. Even more the support for our development style and roadmap
I think that Niko chose a clearly defined profile for his design of Irrlicht, namely an easily usable engine with support for the full range of graphics capable systems. And we all (including Niko and the rest of the team) do our best to keep this profile alive. We won't disallow bleeding edge features in Irrlicht, but the ease of use is always prioritized over extending the engine. Dropping these unique properties of Irrlicht would make it just another OSS engine.

Still, facts are facts, and seeing another engine I have quite fond memories of, being misrepresented by other users who clearly operate over the limits of their knowledge is annoying and it is helping no one.

Yes, it's annoying, but also inevitable. You'll always meet such opinions. Just make your point and hope that they do learn from it. You won't persuade all, at least not once and for all

[twilight17]

12 lines of code

Does this look like 12 lines of code? (You can subtract the braces if you want.)

Code: Select all

#include <Ogre.h>
#include <OIS/OIS.h>
#include <CEGUI/CEGUI.h>
#include <OgreCEGUIRenderer.h>

using namespace Ogre;

class ExitListener : public FrameListener
{
public:
    ExitListener(OIS::Keyboard *keyboard)
        : mKeyboard(keyboard)
    {
    }

    bool frameStarted(const FrameEvent& evt)
    {
        mKeyboard->capture();
        return !mKeyboard->isKeyDown(OIS::KC_ESCAPE);
    }

private:
    OIS::Keyboard *mKeyboard;
};

class Application
{
public:
    void go()
    {
        createRoot();
        defineResources();
        setupRenderSystem();
        createRenderWindow();
        initializeResourceGroups();
        setupScene();
        setupInputSystem();
        setupCEGUI();
        createFrameListener();
        startRenderLoop();
    }

    ~Application()
    {
        mInputManager->destroyInputObject(mKeyboard);
        OIS::InputManager::destroyInputSystem(mInputManager);

        delete mRenderer;
        delete mSystem;

        delete mListener;
        delete mRoot;
    }

private:
    Root *mRoot;
    OIS::Keyboard *mKeyboard;
    OIS::InputManager *mInputManager;
    CEGUI::OgreCEGUIRenderer *mRenderer;
    CEGUI::System *mSystem;
    ExitListener *mListener;

    void createRoot()
    {
        mRoot = new Root();
    }
    
    void defineResources()
    {
        String secName, typeName, archName;
        ConfigFile cf;
        cf.load("resources.cfg");

        ConfigFile::SectionIterator seci = cf.getSectionIterator();
        while (seci.hasMoreElements())
        {
            secName = seci.peekNextKey();
            ConfigFile::SettingsMultiMap *settings = seci.getNext();
            ConfigFile::SettingsMultiMap::iterator i;
            for (i = settings->begin(); i != settings->end(); ++i)
            {
                typeName = i->first;
                archName = i->second;
                ResourceGroupManager::getSingleton().addResourceLocation(archName, typeName, secName);
            }
        }
    }
    
    void setupRenderSystem()
    {
        if (!mRoot->restoreConfig() && !mRoot->showConfigDialog())
            throw Exception(52, "User canceled the config dialog!", "Application::setupRenderSystem()");

        //// Do not add this to the application
        //RenderSystem *rs = mRoot->getRenderSystemByName("Direct3D9 Rendering Subsystem");
        //mRoot->setRenderSystem(rs);
        //rs->setConfigOption("Full Screen", "No");
        //rs->setConfigOption("Video Mode", "800 x 600 @ 32-bit colour");
    }
    
    void createRenderWindow()
    {
        mRoot->initialise(true, "Tutorial Render Window");

        //// Do not add this to the application
        //mRoot->initialise(false);
        //HWND hWnd = 0;  // Get the hWnd of the application!
        //NameValuePairList misc;
        //misc["externalWindowHandle"] = StringConverter::toString((int)hWnd);
        //RenderWindow *win = mRoot->createRenderWindow("Main RenderWindow", 800, 600, false, &misc);
    }

    void initializeResourceGroups()
    {
        TextureManager::getSingleton().setDefaultNumMipmaps(5);
        ResourceGroupManager::getSingleton().initialiseAllResourceGroups();
    }

    void setupScene()
    {
        SceneManager *mgr = mRoot->createSceneManager(ST_GENERIC, "Default SceneManager");
        Camera *cam = mgr->createCamera("Camera");
        Viewport *vp = mRoot->getAutoCreatedWindow()->addViewport(cam);
    }

    void setupInputSystem()
    {
        size_t windowHnd = 0;
        std::ostringstream windowHndStr;
        OIS::ParamList pl;
        RenderWindow *win = mRoot->getAutoCreatedWindow();

        win->getCustomAttribute("WINDOW", &windowHnd);
        windowHndStr << windowHnd;
        pl.insert(std::make_pair(std::string("WINDOW"), windowHndStr.str()));
        mInputManager = OIS::InputManager::createInputSystem(pl);

        try
        {
            mKeyboard = static_cast<OIS::Keyboard*>(mInputManager->createInputObject(OIS::OISKeyboard, false));
            //mMouse = static_cast<OIS::Mouse*>(mInputManager->createInputObject(OIS::OISMouse, false));
            //mJoy = static_cast<OIS::JoyStick*>(mInputManager->createInputObject(OIS::OISJoyStick, false));
        }
        catch (const OIS::Exception &e)
        {
            throw new Exception(42, e.eText, "Application::setupInputSystem");
        }
    }

    void setupCEGUI()
    {
        SceneManager *mgr = mRoot->getSceneManager("Default SceneManager");
        RenderWindow *win = mRoot->getAutoCreatedWindow();

        // CEGUI setup
        mRenderer = new CEGUI::OgreCEGUIRenderer(win, Ogre::RENDER_QUEUE_OVERLAY, false, 3000, mgr);
        mSystem = new CEGUI::System(mRenderer);

        // Other CEGUI setup here.
    }

    void createFrameListener()
    {
        mListener = new ExitListener(mKeyboard);
        mRoot->addFrameListener(mListener);
    }

    void startRenderLoop()
    {
        mRoot->startRendering();

        //// Do not add this to the application
        //while (mRoot->renderOneFrame())
        //{
        //    // Do some things here, like sleep for x milliseconds or perform other actions.
        //}
    }
};

#if OGRE_PLATFORM == PLATFORM_WIN32 || OGRE_PLATFORM == OGRE_PLATFORM_WIN32
#define WIN32_LEAN_AND_MEAN
#include "windows.h"

INT WINAPI WinMain(HINSTANCE hInst, HINSTANCE, LPSTR strCmdLine, INT)
#else
int main(int argc, char **argv)
#endif
{
    try
    {
        Application app;
        app.go();
    }
    catch(Exception& e)
    {
#if OGRE_PLATFORM == PLATFORM_WIN32 || OGRE_PLATFORM == OGRE_PLATFORM_WIN32
        MessageBoxA(NULL, e.getFullDescription().c_str(), "An exception has occurred!", MB_OK | MB_ICONERROR | MB_TASKMODAL);
#else
        fprintf(stderr, "An exception has occurred: %s\n",
            e.getFullDescription().c_str());
#endif
    }

    return 0;
}

This is without the ExampleApplication.h because thats painfully slow.

[rogerborg]

Oh, that reminds me: it's that assumption about an "Ogre app" (rather than Ogre being a minor sub-component of the user app) that really turned me off.

Yes, I know that there are other ways of viewing/doing it, but the very presence of Root::startRendering() makes my hackles rise. Hackle, hackle.

[Kojack]

Does this look like 12 lines of code? (You can subtract the braces if you want.)

No it doesn't. But this does:

Code: Select all

#include "ogre.h"

INT WINAPI WinMain( HINSTANCE hInst, HINSTANCE, LPSTR strCmdLine, INT )
{
	 Ogre::Root *root = new Ogre::Root("plugins.cfg","config.cfg","ogre.log");
	 if(!root->showConfigDialog()) 
     return 1;
	 Ogre::RenderWindow *window = root->initialise(true, "Blank Window");
	 SceneManager *scene_manager = root->createSceneManager("OctreeSceneManager");
	 Camera *camera = scene_manager->createCamera("PlayerCamera");
	 Viewport* vp = window->addViewport(camera);
	 root->startRendering();
	 delete root;
	 return 0;
}

That's a complete working ogre program which renders a blank scene.

With 3 more lines of code, it could load the irrlicht demo's castle bsp out of the pk3 file and display it with animated sprites/textures (I know because I've done it).

but the very presence of Root::startRendering() makes my hackles rise. Hackle, hackle.

Is it really hackle raising that there's a single OPTIONAL function to start the rendering loop? You are free to call root->renderOneFrame() instead.

Apart from the example above (which was intended to be small) I never use startRendering. I think the last time I used it for my own projects was around the beginning of 2004, after that I just used a my own main loop.

[rogerborg]

but the very presence of Root::startRendering() makes my hackles rise. Hackle, hackle.

Is it really hackle raising that there's a single OPTIONAL function to start the rendering loop?

That seems like a rhetorical question, since I've already expressed my opinion.

Thanks for that example code; had I seen that then I might have stuck with Ogre. As it is, I may revisit it again.

IMO, Ogre benefits from lovely demo executables, but suffers from bloated demo code. Perhaps there's a happy medium to be found.

[cassini]

I'd say you try to talk about things you don't understand. But that's only my first impression, let's see the proofs:

Excuse me, I thought facts were piece of information about circumstances that exist or events that have occurred and can be proved by the historical record.
However if you feel so strong about this then I grant that you are better programmer than I am and you can do better things with Ogre than you can do with Irrlitch. I only stated what my experience was using Ogre and Irrllicth.