For me the main advantage of ogre is its animation control. You can mix bone animations however you please which leads to interesting possibilities.
Hmm, this will be a big issue in a project I'm planning on starting any day now... is it currently possible to "mix bone animations however you please" in Irrlicht using a physics engine (i.e. Newton)? Or is this feature impossible right now, but planned for the future?
Well I got this working as well as some of other cool animation and bones features, I’ll working on it again now, to speed and tidy it up. You see my ragdoll video?
I prefer Ogre because of its fantastic material system, and world/level editing from inside 3dsmax.
Of course the Pro version of Ofusion for commercial projects costs money but its an awesome tool, and there's a free community edition for non commercial use.
Irrlicht still suffers from fairly limited geometry formats which only allow advanced materials through shaders, whilst Ogre has outstanding fixed function art pipeline support, thats even simple for 3dsmax artists to use.
If your not using 3dsmax though, I think from an artist perspective either engine is good.
Ogre does still offer input through OIS which is included with the eihort demos as well as CEGUI for UI stuff. It has a series of addons that are fairly easy to integrate and has some really nice commercial games released made with it recently. 4 - 6 in 2006.
ah yes... ogre's material system is very nice. when i was using ogre i was using blender and besides a few exporter issues here and there it worked very well.
unfortunately using a 3d modeler doesnt do it for me when it comes to level editing. i use gtkradiant now which brings me back to irrlicht .
being an ex Ogre user, I prefer Irrlicht hands down for its simplicity.
Ogre is the kind of gratuitously overly complex exercise in OPP for not particular reason.
I guess it all comes down to your level of experience and familiarity with game engines. And then you have to consider what features you need for your game and which engine supports those features and is more rhobust.
I havent seen many finished projects completed with Irrlicht, and many including commercial projects done with ogre.
I think Ogre has a head start because it has better support for graphical features artists can use to get their media into the engine looking the way they want it.
CSG and BSP is used less for visuals and more for underlying structure these days with 3D apps becoming the primary level design tools in most modern games. It's been going that way for several years now, you only have to look at the level designer positions and the required skills in places like the job section of Gamasutra to see what people are using.
...3D apps becoming the primary level design tools in most modern games. It's been going that way for several years now, you only have to look at the level designer positions and the required skills in places like the job section of Gamasutra to see what people are using.
while it is entirely possible to do your level designing in a 3d app.. a good level editor will promote consistency and hasten development times. most game engines are less developed than something like hl2:source, unreal, or doom3 and so they dont have the proper level design tools (which is why many game companies will look for maya or 3dmax artists). Also level editors are mostly proprietary and it would be impossible to expect an applicant to already be familiar with an inhouse editor.
CSG and BSP is used less for visuals and more for underlying structure
actual binary space partitioning(the underlying structure) is not as important these days as it was when quake 2 was out. the reason i like bsp is because it is a format that can be exported by one of the highest quality level editors known to man (gtkradiant ).
with that said, both ogre and irrlicht can read bsps. i dont know about ogre, but irrlicht just loads in the geometry data, completely skipping the bsp stuff. this works well for irrlicht because it was not built from the ground up as a bsp engine.
so the point to all this: both engines have a great map editor available. while gtkradiant and other similar editors may not give you all the flexiblity you need for a next gen title, i doubt anyone here is working on one using either engine.
cassini wrote:being an ex Ogre user, I prefer Irrlicht hands down for its simplicity.
Ogre is the kind of gratuitously overly complex exercise in OPP for not particular reason.
What does the debugger tell you? You did use the debugger, didn't you?
cassini wrote:being an ex Ogre user, I prefer Irrlicht hands down for its simplicity.
Ogre is the kind of gratuitously overly complex exercise in OPP for not particular reason.
What? I like Object Poriented Programming for not particular reason
But seriously, I wouldn't critisize a framework for being overly OO... (then again I didn't try Ogre enough to judge it...)
+Really supportive large community. For example, I had 5 answers to my question within 3 minutes!
I find this completely wrong for Ogre. When I last stopped in on the community there and gave Ogre a chance, bout maybe a year ago, the community was full of "noob bashers" and to get the proper help, you would have to read through all the insults/flames to your question.
Only thing I'll comment on. Maybe it's better now, but already spoiled me.
Not now, not one year ago, nor two years ago, when I first looked at Ogre.
Their forum is very helpful and friendly. Though one not always gets the answer one wants.
When I first looked at the irrlicht forum, when guest accounts were still allowed, the atmosphere was more hostile here, then it ever was over there from my experience.
FriendlyWarlord wrote:I like Object Poriented Programming for not particular reason
Are you a sure about that? How do you like MFC then?
Ogre imo is about the same, and for a graphics library that do nothing more, that’s too much for me.
Saturn wrote:When I first looked at the irrlicht forum, when guest accounts were still allowed, the atmosphere was more hostile here, then it ever was over there from my experience.
I think you will find that very common on every forum allowing anonymous posting.
I do not think the atmosphere over ogre forum is any friendliest than it is here. In fact I think that the majority of the people registered there are also registered here.
Anyway I just said what I thought about Irrlicht/Ogre, I am not pretending to convince anybody to change. But I find rather odd that people posting in favor of Ogre maybe do not realize that this is Irrlitch turf.
You would think that if people are hanging around here is because they like Irrlicht more.
1. Irrlicht is easy to compile. The directory structure is simple, and only one DLL or library file is created.
"So what", you say - ease of compilation doesn't matter? Not so - because of the easy compile process, the following are also true:
2. Irrlicht can be easily cross-compiled. Compile for Windows on Linux. Can you do that with Ogre?
3. Irrlicht can be easily statically linked into a single executable, together with any other libraries you are using (ODE, Lua, etc). Ogre's license doesn't allow this. Even if it did, it might not be easy technically. My experience with the Ogre build system wasn't good - it didn't work out of the box (for me), and it was tedious to figure out what the build system was doing because of the shared-object building, ranlib, libtool, configure - I can't remember what I had to hack to get it working, and if I wanted to try it again I'd maybe again have to spend time debugging the complex build system.
Back to the single EXE issue - personally, I don't like applications with lots of files - ideally, I want to make a single executable file, and single data file, to distribute my application. No DLL's, no installation, no de-installation.
4. Irrlicht can be run as a Java Web Start application, for another no-installation scenario.
5. Irrlicht can be easily extended, because of its simple compile (build) structure.
Now, some posts raise the legitimate concern that some parts of Irrlicht architecture are fundamentally poorly designed, "time bombs" waiting to explode. I haven't hit these spots myself yet, but I admit it is a concern.
For me, the key point about choosing a piece of your system infrastructure (like a graphics engine) is flexibility. Can you change it to fit your needs? In my case, my needs are single-EXE distribution, cross-compiling ability, ease of integration with other libraries, feasible maintenance overhead. Irrlicht, as a small, tight, simply-structured codebase, fits my needs.
While Ogre may have more features, you have to ask yourself: do YOU need ALL those features for YOUR game? If so, sure, use Ogre. But if not - wouldn't you rather have an engine that YOU can easily and completely modify, extend, control, and understand?
If you consider a graphics engine to be a mature, black-box, binary library that you want to use but not modify, then a complex, difficult-to-build library wouldn't bother you. But if you consider a graphics engine to be a body of source code that you plan to inherit, understand, maintain, integrate, update, debug, and extend, then you should choose a library with a codebase and build complexity that your team can realistically manage.
For me, right now, I want absolute control over the source code of my graphics engine. I assume there are things I will later discover that bother me about the engine, and that I will need to modify. Irrlicht is the most flexible choice, the easiest to understand, and - most importantly - the best investment of my limited time. I could spend time or manpower to understand a larger library like Ogre - but I don't want to or need to.
.
). 
