My sentiments after having used several 3D frameworks

[mikademus]

Hi folks!

I have been coding 3D apps for over a decade and over the years have developed over nine versions of my own 3D engines, mostly in Direct3D. However, for my latest project I suddenly realised that I was seriously suffering from Enginatis and spend much more time on back-end API details than writing actual game code. Thus I decided to change tactics and use a 3rd party FOSS 3D framework.

Using a set of basic requirements (the most important being FOSS, scene-graphed, multi-platform and C++) I selected and evaluated a set of frameworks (the most important of which was OSG, OGRE 3D, Irrlicht, Nebula2 and Horde3D), and the two finalists were OGRE and Irrlicht, mostly for reasons of code structure and the general purpose orientation of the frameworks. OGRE because it is superlatively feature-rich and mature, and Irrlicht for its sleekness and design aesthetics. I then decided to go with Irrlicht.

Since my project is a meta-remake for several older games (ranging from the 90's until about 2000) there would be a lot of low-level coding going on. I started developing the presentation layer (in Irrlicht 1.4.1), and it was initial smooth sailing, until I ran into problems and limitations with materials and inconsistencies between the OGL and D3D drivers. Since I came to 3rd party solutions to not have to edit engine code myself and Irrlich seems surrounded by official yet non-FOSS tools and APIs I surmised that Irrlicht wasn't yet mature and ported the project to OGRE 3D.

OGRE 3D has delivered. It brings all conceivable and necessary features and a stable and consistent behaviour. It also brings endless headaches. It is the most verbose and convoluted 3D framework I have worked with, and unless there is a API call for it, the functionally same code takes three to ten times the amount of calls and source code as in Irrlicht. Not even that the code uses proper British spelling and proper case for members make up for this. OGRE also has a relatively unfriendly and in spite of its numerical size unresponsive community. OGRE has a very nice Wiki but it has very poor examples. Pedagogy is simply neither understood nor a priority of OGRE, or as Simbad (the OGRE lead) says, a programmer who can't figure out OGRE by himself isn't really welcome. That is not to say that I couldn't handle OGRE or needed to be led by hand (my project presentation and render base is done), but OGRE has an incredibly steep learning threshold and I wasn't exactly thanked when reporting and discussing the bugs and inconsistencies I found in the framework.

This bring me to my conclusion: I really, really miss Irrlicht. It is a very nice, sleek and accessible API. It isn't bloated, it is reasonably well-designed and it has a very nice community and lead devs that personally respond to questions and reports (even when the reporter (me) could have been friendlier (frustration is bad for one's friendliness)). Thus, I really, really hope that Irrlicht will mature enough soon for it to be generally usable.

The only real disadvantages Irrlich has are

* Consistency between drivers. For high-level stuff (f.i. using the provided Quake 3 BSP loader) you'll probably never encounter this, but this can really be a deal-breaker
* Materials are insufficient: Irrlicht has an enum-based material system that only supports two texture layers and no flexibility in setting layer blendings etc. This really must be redressed which will bring some additional complexity, but necessary complexity: just as in economics, not all costs are bad.
* The above ties in with vertex definitions: with only two basic vertex types more advanced material management is impossible. Irrlicht needs a way to define custom vertex types.

So there you have it, my take on it. OGRE works well but is a horrible beast to handle. Irrlicht would be preferable but seems not to be mature enough for general production (which is not to say that it can't be used for the situations it IS enough). I have been curious about Lightfeather, which seems to be an Irrlicht spin-off, but it seems to have gone the ANSI-C path and mostly forfeited OO, which is a big mistake imho (sorry if I misremember or misrepresent Lightfeather, it has been a while).

I'd be very appreciative to hear your opinions on this topic (these topics?).

Cheers!

[rogerborg]

Allah loves wondrous variety.

[hybrid]

Which driver inconsistencies are you talking about? Would help more if you had some examples so we know if those are already adressed.
A per-layer material system instead of the per buffer one we're currently using is planned for Irrlicht 2.0. However, you can already now add new material renderers pretty easy.
Irrlicht has 3 vertex types. The question is why you'd need more. Most examples on the forums have shown that you can usually go with those. A more flexible type isn't completely out of scope, though. However, I'm currently trying to reduce the overhead which comes from the non-virtual usage of the vertex types. Once we have cleaned this all up we can probably add more types rather easy.

[mikademus]

Which driver inconsistencies are you talking about? Would help more if you had some examples so we know if those are already adressed.
A per-layer material system instead of the per buffer one we're currently using is planned for Irrlicht 2.0. However, you can already now add new material renderers pretty easy.
Irrlicht has 3 vertex types. The question is why you'd need more. Most examples on the forums have shown that you can usually go with those. A more flexible type isn't completely out of scope, though. However, I'm currently trying to reduce the overhead which comes from the non-virtual usage of the vertex types. Once we have cleaned this all up we can probably add more types rather easy.

Hi Hybrid, and thanks for the quick reply! This is one reason I do want to use Irrlicht, that you (among others) take personal participation very seriously! Also, I do hope I have conveyed that my post above was in fact one of appreciation of Irrlicht. ^^

Well, it's been a few months now, so I can't remember exactly the issues. I did post here about every inconsistency I found under the same username, though (again, even though I wasn't abusive or anything, I could have been friendlier and more politic in those posts). As I remember there was the thing that alpha blended materials were treated differently regarding depth buffer writing in OGL and D3D. Another one was that materials with multiple texture layers couldn't be blended the same way under the two devices.

As for vertex types, yes, Irrlicht's three vertex types used represent common usage, but by no means all. I do not know how representative I am, but in my project I currently use verttices with any combination of position, normal, diffuse, specular and several texture coordinate sets. F.i my terrain geometry vertex type has position, normal, and three texture coordinate sets.

Obviously, trying to capture all conceivable combinations of these would mean class creep and overload hell, but on the other hand, not allowing a way of defining vertices means precluding certain architectural or algorithmic solutions. If you have the change to peruse some relatively recent real-life game code you'll see that specialised vertex types are abundant. OGRE for instance has a VertexDeclaration class which abstracts away the user tedium. Unfortunately, they've over-designed that aspect just as much as everything else.

I would like to learn more about what is planned for Irrlicht 2.0, though I've found very little information about it. I hope that a greater material and texture layer flexibility will be part of it, though.

[hybrid]

Don't know why you have the impression of me taking things (esp. in this thread here) too seriously. My short question and answer stlye is just because I don't want to put much more time into the forum particiation that I already do. So short postings are just the only way I post here...
Anyway, I really just wanted to know which things you're talking about. Not because I don't believe it, but because some things are already under investigations. The zbufferwrite bug is one of them, the solid2layer material is - just as said way back when you mentioned it - that I have no clue about how it shoud work, and that recent changes made it to work for me rather good.
The flexible vertices were also of not much use, because we were targeting for fixed functions. And this would require the flexible material system first for proper use of the the addition vertex data. However, the opengl-es branch (still to come ) does use a flexible vertex format only (which is mapped to from the 3 default types). So it could be possible to add some more stuff based on that branch in the future.

[Saturn]

Hey, another opportunity to play my favorite role: The devil's advocate!

Ogre's community is unfriendly and unresponsive? I went through your posts. Looks rather responsive to me. Nullsquare is not the ogre community and he is here too, his username is agi_shi and he has the same uppity demeanor here too. Everything else is "You reap what you sow". You have a point though that hybrid and his team answer more often than Sinbad and his team.

OGRE because it is superlatively feature-rich and mature, and Irrlicht for its sleekness and design aesthetics.

Says more about your understanding of design rather than about qualities of Ogre/Irrlicht.
Ogre's design is much better IMHO. There is an inherent antagonism between flexibility and simplicity. You can't have one without hurting the other. Question is where you place the slider, tending more towards simplicity or more to flexibility. Ogre clearly says: Flexibility. Irrlicht says: dunno.
So why do I believe Ogre is better designed? This is because they identified responsibilities and distributed them among the right number of classes, so that each responsibility is met by a class encapsulating it. This makes the design more complex and thus less simple. But this is an implicit consequence, you can't go around it, if you wanted to.
And it is this flexibility that causes Ogre to be used by so many projects.
You name yourself two instances where Irrlicht doesn't meet your requirements, in a big project there are still more and there is the content pipeline and resource management problem too. Both are addressed by Ogre, making it more complex, but also more suited for bigger projects.

I believe your comments about Ogre's design being bad or unaesthetic is due to your lack of understanding software design. Please give examples of bad design choices. Makes it easier to discuss this matter.

Pedagogy is simply neither understood nor a priority of OGRE, or as Simbad (the OGRE lead) says, a programmer who can't figure out OGRE by himself isn't really welcome.

Question: Is pedagogy a priority of Irrlicht? It isn't for Ogre, admitted.
Question: Did Sinbad really say this? When yes, where? I doubt it, unless you prove it, I consider this untrue. Not his style.

It is the most verbose and convoluted 3D framework I have worked with, and unless there is a API call for it, the functionally same code takes three to ten times the amount of calls and source code as in Irrlicht.

Not true.

OGRE for instance has a VertexDeclaration class which abstracts away the user tedium. Unfortunately, they've over-designed that aspect just as much as everything else.

Not over-designed. Designed. You say yourself that you have a requirement not met by Irrlicht's fixed vertex types.
If you consider overdesigned what doesn't bring a MikademusCustomVertexFormat primitive, well that's your problem. You have an additional requirement, it is met by Ogre's flexible API but you have to code for it. User A has another different requirement, it is met by Ogre's flexible API but he has to code a bit. Same for users B, C, D, E, F and so on. I mean this is the very definition of a flexible API, just because it also contains bits and pieces you don't need, it is not over-designed. It is designed to meet a variety of possible needs, not just yours.
Why don't you just encapsule the API by higher level functions that are easy to use by your program rather than bitching about supposed over-engineering. This is how it works with all the APIs. Havok is over-engineered too when you think about it, lots of stuff I don't need for my "ball rolls down a slope" project, stupid Irish software engineers.

Just to state the obvious: Ogre is used in innumerable projects, commercial and not, high profile and smaller home made projects. The featured project section on the home page and the showcase forum bear witness of what it is capable of. Are those project leaders that go for Ogre with their project just stupid? Don't they see just how ugly, convoluted and verbose the API is?

These kinds of cowardly posts, getting cheap praise by debasing other engines, they really give me goose bumps, they annoy me to no end.

[rogerborg]

Uh oh, I think Saturn's account has been hacked. There's no way that the real Saturn would post anything so mellow, balanced and constructive.

Irrlicht is a great engine, because it's so easy to understand that it has many forks.

OGRE is a great engine, because it's so fully featured that there's no need to fork it.

Crystal Space is a great engine, because... uh... because... they just try so darn hard.

[mikademus]

Saturn, I was going to reply to your post because you started it in what appeared a reasonable way but it didn't take many lines before you started generalising and fantasising. I don't doubt you've got a proud coder's fat ass in reality so it is fitting that you're a great fat arsehole in virtuality.

[Saturn]

Saturn, I was going to reply to your post because you started it in what appeared a reasonable way but it didn't take many lines before you started generalising and fantasising. I don't doubt you've got a proud coder's fat ass in reality so it is fitting that you're a great fat arsehole in virtuality.

You are embarrassing yourself here.

@all If someone wants to argue the key points of my post in the lights of mikademus' first post, I'm all ears.

[rogerborg]

I think I'll pass, for much the same reason that I wouldn't enter a kissing competition with a cobra.

[mikademus]

Saturn, I want to thank you for that with great skill destroying any chance of having a good exchange from a post I put a great deal of effort and good will into. Pleasant future trolling on this board, you've scared me away. Kthnxbai.

[FreakNigh]

Long Live Irrlicht!!!!

[torleif]

mikademus Has very good points. Materials when changing drivers is erratic and really needs to be worked on. I don't really use shaders, mostly because of the headaches involved, but a fantastic feature would be a cross driver shading engine.

I had an idea for the name space video::E_MATERIAL_TYPE enum:

Code: Select all

//example:
EMT_SOLID, // sold texture
EMT_TRANSPARENT, // transparent, 
EMT_2TRANSPARENT, // transparent, requires two materials 
EMT_11_2TRANSPARENT, // transparent, requires pixel shader 1.1 and two materials 
EMT_2_2TRANSPARENT, // transparent, requires pixel shader 2 and two materials 

It also would be handy if the user set the material of a object to video::EMT_2_2TRANSPARENT and the hardware didn't support it, it would fall back to the video::EMT_11_2TRANSPARENT or EMT_2TRANSPARENT (depending on the vertex shader the current hardware has).

It would save the user from querying the driver before setting the E_MATERIAL_TYPE. Of course he would have to query the diver upon setting custom shaders

[hybrid]

I started to work on better fallback support in the shader interface. But other things distrubed the work, so it's not yet very far. However, there won't be any additional enum values in Irrlicht. Instead, you'll just choose the transparent material, and Irrlicht will use the best supported material. The list of possible material implementations will be searched until one working material is found.
Cross driver shading is possible with Cg. An implementation can be found in the project forum. This is an external extension so far, but might move into the core engine at some later date.

[torleif]

I started to work on better fallback support in the shader interface. But other things distrubed the work, so it's not yet very far. However, there won't be any additional enum values in Irrlicht. Instead, you'll just choose the transparent material, and Irrlicht will use the best supported material. The list of possible material implementations will be searched until one working material is found.
Cross driver shading is possible with Cg. An implementation can be found in the project forum. This is an external extension so far, but might move into the core engine at some later date.

It would be fantastic if Cg could be merged into the main branch sometime in the future. Also good work on the fall back function, people will love you for it =D

BTW: my enum suggestion wasn't for more, just to make the pixel/vertex shader requirement in the name so people can tell what support is needed for the application