Hm... Read below: I just wrote an unbiased review of Ogre vs. Irrlicht - my mind was actually set on Irrlicht in the start, so read on.
I *was* an Irrlicht user... but now I switched to Ogre. I'll give you it straight-up.
First I started with Ogre, and thought to myself - "w...t...f... I have to get thousand managers, a root, a scene manager, a render system, a camera, a viewport, a render window, and a separate input library on top of all of that JUST to make a simple demo without using the pathetic example application class".
So I switched to Irrlicht. Nice and easy setup - create a device, tell it about the window, you're ready to rock. Load a model, display it, you're done.
But that's where it ends. Once you get deep into the stuff, it just doesn't fit together anymore. For one, orientation. The example FPS camera didn't do stuff I needed it to do. So I decided to make my own camera scene node. Nope, because cameras can only look at stuff without any simple orientation.
So I said ... well, use the fps camera until I "really" need to switch it. Went to work on portals. Got a simple quad up. And it ended. So... I get rotations in degrees and that's it... Never managed to implement portals in Irrlicht (portals like prey and portal, not culling portals). I believe I had the transformation correct, but from there on it sucked. I couldn't get the texture coords correct, and there was no simple way of "copying" the texture to the screen efficient, to create an illusion of a "hole".
Then came shadows. Shadows must be cool! Not exactly as I though. Extremely glitchy modulating stencil volumes that ran at the speed of jelly.
So I went to the Ogre demos... man ... they looked good. Additive shadows (textured-based as well as stencil-based)... in a addition to faster, but less accurate modulative shadows... Self-shadowing.... Multiple shadows... It looked good, really good.
Shaders in Irrlicht are a pain in the a$$. First of all, only ASM/HLSL/GLSL is supported, which means you have to write two versions of each of your shader to be able to use both DX and GL. Since that's not annoying enough, you have to hard-code each and every parameter to the shader. No easy specification of "projection matrix". No easy specification of "here, shader, just use the view matrix". All hardcoded.
Ogre, on the other hand, supports built-in CG. But that wasn't the problem. The problem was that Ogre could parse .material scripts, instead of having you hard-code everything. And even better, it has a crap-load of default parameters it can hand you - view matrix... projection matrix... any light info. Camera info. Material info. All there by default. I haven't found a need to pass any parameters from my code so far, Ogre handles it all. Speaking of shaders... where's the easy multi-pass support for Irrlicht? With Ogre, you tell it " pass {} " and "scene_blend" (or the equivalent functions of the technique, pass, and material classes), and you've got multi-pass rendering EASY. With Irrlicht? You do it all on your own. Want 1 more pass? Change the material, re-render everything, specify everything on your own. 2 more? Do it twice. N more? Do it N times.
Another thing that ticked me off of Irrlicht is... I found no after-pass techniques. No compositor ideas, no overlaying, nothing. Ogre has both compositors and overlays. Implementing my portals was extremely easy as overlays (see below for proof, since you probably won't believe me).
Also, I never found the way Irrlicht handles nodes too interesting. A node should be a "holder", not data on it's own. In Ogre, it's logical - you want a mesh? Create an entity, tell it to use the mesh, and attach it to a scene node. In Irrlicht, you want a mesh? You have to use the mesh scene node. Oh, you want an animated mesh? Ogre: no prob, it's all handled - animated or not animated, we're cool. Irrlicht - oh... sorry, in that case you must switch your scene node to a different type, specifically for animated meshes.
Yes, Ogre seems extremely over-complicated at first. But once you delve into it, you realize WHY it's so complicated. Because once you get the hang of it, there's no pathetic hacks to overcome - there are no problems to solve - you just ... use it.
One more thing - why the HELL does Irrlicht code everything on it's own? Strings, lists, everything. This is also why I like Ogre. At first I though Ogre::String was it's own class, but it's a typedef for _StringBase. And guess what _StringBase is a typedef for? std::string. Ogre is smart. Irrlicht re-implements the whole wheel, but I see no good coming out of it.
These are probably *some* of the reasons as to why commercial apps use Ogre. There's a plethora more, but my hands are getting very tired.
** portal proof:
Yes, I know about Blizz portals for Irrlicht. But I don't like their implementation. They're render-system specific, and not too flexible. My portals, using Ogre, are extremely flexible - any shape size (no need for meshes), each and every portal is independent of the others... Etc, etc. (Not bashing the Blizz-portals, they're cool. Just showing what an amateur programmer can do with Ogre [me], and what a good programmer can do with Irrlicht [blizzard]... btw, the normal mapping with excessive specular lighting you see is also written by me - infinite lights, all fully calculated at the pixel level - supports spotlights, omni lights, and direction lights...)
(my video:
http://www.jeepbarnett.com/narbaculardr ... ortals.avi
it's old, it's glitchys - I've fixed everything by now - but it shows off the general idea)