Ogre VS Irrlicht

Which of these (or other) is the best LGPL cross platform engine?

-Ease of 'getting in to it'?
-Which do you prefer and why?
-Dissadvantages?


(Ps: please dont suggest any windoze only ones, if theyre not cross platform i am not interested)

I prefer Irrlicht simply because there's a free finished BlitzMax wrapper for it. :)

I consider it easy to use. It's a bit harder than Blitz3D, but not much. You get a hang of things simply by looking at the BlitzMax examples, and Irrlicht documentation is good enough (though not perfect). Having the option to choose between Direct3D9, Direct3D8, OpenGL and two software drivers is a real plus.

There's also a module that lets one use Blitz3D commands with Irrlicht, but I haven't really used it.

-AF

None of both

OGRE is no engine, just a renderer -> you will have to implement your own collision handling, sound, ...

Irrlicht is nice but its "surrounding" starts to going into a perhaps too professional (ie too expensive) direction (irrKlang licenses for example)

Ogre has all those available as addons and offers you more freedom to chose the components you want. Has much better geometry and material formats and handling, better design, faster, and is much, much more feature rich.

Irrlicht has mostly obsolete file formats that were never designed for realtime graphics and are extremely limited, often forcing you to use several separate formats to get the specific material and features you need. Depending on whether you want multiple UV's, animation, etc.

Ogre is more complicated than irrlicht but has so many addon modules available, it’s more like Bmax or Blitz3D, their modules offering 5 different physics solutions, many low level scene managers and terrain system depending on your needs. a handfull of GUI libraries, and a couple of input libraries.

Ogre has an older, more experienced and mature community. Its being used for a lot more commercial projects than Irrlicht, and has a lot more finished games released that are made with it..

It also has by far the best art pipeline tools, especially for 3dsmax where you have 2 very good exporters depending on your budget. Unwrap3D supports the Ogre XML format, so if you want to use some weird tool without a exporter for ogres binary meshes you can convert to the XML format and compile binarys with the Ogre mesh compiler.

It may sound restrictive to have only the ogre mesh format, but the mesh format evolves with the engine keeping up to date and developed in parallel to the engine itself.

It also has a mesh update tool for updating binaries to the latest version.

Ogre is constantly updated with a new major release once a year, and an update usually every other month.

Irrlicht seems pretty primitive and constrained in comparison to ogre, but that’s also the main reason it is easier to use and probably better for people starting out. You don't have much in the way of low level scene management, restrictive geometry formats and simple material support with the usual shader support bolted on means there’s less to learn, and no modules you have to integrate yourself, so faster to get up and running.

Flow should fix most of the shortcomings of ogre providing you with a nice game dev framework which should make Ogre much more accessible to Blitzmax users, Flows rendering functions are pretty much a direct wrap of ogres so its not going to suit every B3D user, those that want something as simple as Blitz3D with really simple to use helper functions
will be better off with irrlicht until Easyflow comes out later and will target B3D users more.

I havent said much about Flow but it's basicly a framework that uses Bmax's own functions as much as possible to control the Ogre renderer, but also including physics, collisions, as well as scriptable (LUA or XML) skinnable GUI system, plus Bmax input, sound and MaxGUI support. Oh and has a feature rich sceneloader. plus object placement editor for easy scene building and simple heirarchy rigging from 3dsmax or arbitrary meshes.

ETA on Flow?

Our C++ coder has scheduled the release for Feb 1st, with feature lockdown for Dec 25th. So It's now quite mature, with more development time targeting Linux and OSX versions.

Sweet, let me know if you need beta testers!

Ogre is slow.

Eh? what were you doing with it to make it slow?

Compared to Irrlicht or Truevision3D, Ogre is slow.

Have to agree on that point. On low - mid level systems, OGRE tends to slow down drastically while Truevision3D scales massively.

Might be that similar scalability can be achieved with OGRE as well (although, even on lowest the OGRE head demo will run at < 30 FPS on a GMA900 while the normalmap shadow-selfshadow example of TV3D runs at 50FPS +) but it is definitely harder to do than having an automatic that has been opted for a serious long time.

But that does not mean that OGRE is bad actually. Its high modular building allows to integrate lower and higher level features without too many problems which makes it optimal if you want to opt the engine to your specific game as far as possible.

Agreed - speed isn't everything. But this is supposed to be a thread about comparing engines.

well irrlicht does load .b3d fine

There's quite a difference between a normalmap and a real-time facial morph demo (which might not even be using hardware acceleration if your hardware doesn't support shaders).

I'd be interested to know what comparisons you found Ogre to be slower. I'm not saying you're wrong, just that I'd be interested in which aspects are slower in Ogre :)


Irrlicht seems to be generally the easiest to learn, since the interface is much more simple. However, I prefer Ogre and would never use Irrlicht for two reasons:

1. Irrlicht has many severe design flaws (there's a lot that isn't possible due to poorly designed internals, like animated models can't have bump maps I think, etc.)

2. Ogre has many advanced features, many advanced community add-ons, is well documented, and is very easy to use once you get used to it. The main downside for beginners is that there aren't really any good tutorials, IMHO, so learning can be a little tough, especially if you aren't proficient in C++

Regarding the fact that Ogre only supports it's .mesh format, this can only be an advantage unless you want to support old model files without conversion. Once you understand how Ogre separates .mesh data from .material data, and allows you to edit material properties with notepad without touching the .mesh data, you begin to see how truly powerful the system is.

Because Ogre supports just one mesh format, it makes things a lot easier - you don't have to worry about bugs in the engine's 3ds/x/b3d/etc./etc./etc./etc. parser; if your model doesn't look right, it has to be an exporter problem. And my favorite part is that if your exporter doesn't support all the material properties you want (bump mapping, alpha transparency, material animations, z-buffer offsetting, etc., etc., etc.), then that's no problem - simply open up the corresponding .material file in notepad and make the necessary changes.

yeah that was an old design flaw, but it's been rewritten and fixed.

Running various demos.

The Ogre Chess Program was the deciding factor for me. Low poly chess pieces with a shiny board and the thing only ran about 90-100 FPS (it was written in C++).

If I were you, I wouldn't let any one program be the deciding factor for any engine, especially one like Ogre. Saying Ogre is slow because Program X is slow can be like saying DirectX is slow because MS Flight Simulator 10 is slow. The chess program runs very slow on my computer also, but I know for a fact that Ogre is not "slow" (I can show you :) )


Well I wouldn't exactly call that a scientific comparison then :). It's strange, but my initial impressions of Ogre were that the demos seemed considerably faster than most other engines, not slower, and that was on my GeForce FX 5200 Go (slower than a GF 4 Ti).

But I do agree that Ogre's performance seems to get better on more modern hardware, but in a way this is to be expected. Often you have two options when choosing/writing an engine:

1. Performs well on old hardware when rendering low complexity scenes, performs poorly on newer hardware when rendering high complexity scenes
2. Performs bad on old hardware when rendering medium complexity scenes, performs well on newer hardware when rendering high complexity scenes

Ogre is a modern rendering engine, so obviously it uses a modern design (#2). TrueVision may be good on old hardware, but I wonder if it performs all that well on newer PCs (in my experience TrueVision ran somewhat poorly on my high end PC, but that was a few years ago).

P.S. What aspects of Ogre's rendering did you find particularly slow? If you found the bump mapping, etc. to be slow, I really hope you understand that the example shaders provided aren't the most optimized ones around (they're meant to be replaced). If the terrain demo seems to be slow, it's most likely because Ogre's terrain demo is optimized mainly for modern video cards (where it runs in excess of 1000 FPS) with geo-mipmapping, unlike Blitz3D, which uses a ROAM-like technique (which is quite outdated simply because it requires all the terrain to be uploaded to the video card every frame - this is good for cards with low polygon rates, but not for modern cards, where the bottleneck is in the upload speeds).

I think you will have to play with Ogre yourself and see. Bad design and materials targeting the wrong hardware can easily have a huge impact on performance. Especially when using shaders on cards that barely support them.

Only problem I noticed with Ogre when playing with SOW was on ATI cards with a certain set of drivers. The FPS would plunge from 3 digits to single digits and simply required you to not use those particular drivers.

in our case it was the ATI Radeon Xpress X1200, fortunately new drivers came out and the problem went away.

No, not scientific - just an overall impression. I'm not the only one with this impression.

And a chess program is hardly a flight simulator.

I had the same problem as Evak above but with an x1300, but the problem went away after driver updates.

Personally Steve, I also used to think Ogre was slow, but about 18 months ago when we started doing the tests we found Ogre to be quicker than we originally thought.

Ogre has some similarities to blitz3D in some areas. Like the surface count. Ogre does batching and the fewer batches with high polycounts you send to the GPU the better.

Ogre has had staticgeometry support for a number of years, which makes it easy to control the surface count in a scene and still use seperate meshes. In simple terms you can set a static geometry group name for a bunch of seperate meshes and ogre will combine these meshes by their material at runtime into a singlesurface meshes, you can also set ranges for the group which splits the single surface meshes into chunks within dimensions you can set manualy.

That alone provides you with huge advantages over Blitz3D, with a lot of control of batching/surface counts even with hundreds of seperate static meshes in your scene. Stencil shadows are quick and work well on older cards, ogre utilizes several methods to optimize shadows to make them fast even on older cards like my geforce 3.

Before we picked Ogre I dabbled with Irrlicht and it seemed a lot slower, that was over a year ago. As for the Blitz3D format. It's nice for what it is, and in someways having a single format for geometry, material and bones can be nice. But its no where near as flexible as ogres native formats.

Ogre has the most complete fixed function support I have seen anywhere, and supports the same shaders as all other engines, we use HLSL or CG because they are very similar, allthough HLSL seems to have a slightly more optimized compiler if your targeting only windows and D3D.

Fair enough. I'll take your word for it.

I'm not using any of those engines anyway, so it's not a big deal. You and Evak might convince a few people to take another look at Ogre though. :-)

It's worth it, constantly in development :-) ;-)

*toots own horn*

Steve, the way the chess AI was written could be making the fps plunge dramatically(ie...inefficiently). I wouldn't use a chess program to evaluate Ogre capabilities personally.

the chess game uses a 2 year old version of ogre, from when it still had a DX7 renderer, as well as DX9 and GL.

I just tried it and its kind of cool, with the hands doing stuff.



http://www.steviedisco.co.uk/files/chess.zip

All I want is the ability to have blitz3d ish control, with amazing lighting and shadow.

Thats all I've ever wanted. Not interested in shaders.

Thanks guys, some interesting views. I will certainly be checking out your ogre wrapper guys :) I am currently experimenting with both the irrlicht.core and irrlicht.b3d mods from gman and they are looking promising too.

Me too (except i would include cross platform in my wish).
The closest thing to DX9/GL blitz3d ive found so far is this: (Check out the 3rd post on this page :)
http://www.gprogs.com/forum/viewtopic.php?id=223
All my initial experiments with ib3d are working well.

True, but I'm not comparing the two. My point is that both can be written poorly; just because MS Flight Simulator 10 runs excruciatingly slow doesn't mean DirectX is slow. Similarly, just because the chess program is slow, it doesn't mean Ogre is slow (whether or not it is :) ).


That's a little bit like saying "I want a really nice, fast car, but you can leave out the engine - I don't need that." Really, you can't have amazing lighting and shadows without shaders - that's why the call them shaders. If you want high quality lighting and shadows, you're going to have to deal with shaders at some point (although I agree that the use of them should be as simple as possible; unfortunately it's hard to make an engine that combines both easy shader use and flexible shader use).

But anyway, definitely try out an engine before you make a decision about it. I can't honestly say that Irrlicht is good or bad, since I haven't really used it much, but I can say from experience that Ogre is excellent (definitely one of the top engines out there).

P.S. And if there's any question to how capable Ogre is, just take a look at the gallery here:

http://www.ogre3d.org/index.php?set_albumName=album07&option=com_gallery&Itemid=55&include=view_album.php

I just looked at a thread on the Ogre forums that compares the two. Sinbad the Ogre project lead says that on some hardware Irrlicht can be faster in GL, especially if your using BSP.



More about GL v's DX9 and VBO's on his blog.

http://www.stevestreeting.com/?p=555

Here's a couple of similar threads from the two engines threads. Mostly usefull to learn a little about the two communities than actual usefull information.

The Ogre V's Irrlicht thread on the Ogre3D forums:

http://www.ogre3d.org/phpBB2/viewtopic.php?t=33791&postdays=0&postorder=asc&start=0

The Irrlicht Irrlicht v's Ogre thread

http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=18125&highlight=

If I made a commercial game with Ogre and compiled it for windows and linux, how would i dynamically link it in linux as there is no DLL so to speak? As the license says if its statically linked you have to release your code.
Mabe im just a little unclear on the difference between dynamic and static. Does dynamic mean at compile or runtime? ie- that it is not included in your binary at all, OR that when the program was compiled you linked to an already compiled "binary.a"? (im still a bit of a confused noob on this :/ ).
In contrast, the irrlicht license doesnt seem to care what you do so long as you mention a few lines in the credits and dont change the engine (without re-releasing it properly)

There are DLLs on unix.
Their extension is SO actually.