My sentiments after having used several 3D frameworks
Posted: Thu Aug 14, 2008 12:23 pm
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!
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!