Ogre3D or Irrlicht ?

[CuteAlien]

This brings me towards a point: Does anyone have even a slight fact based idea towards what irrlicht is primarily aimed/ used for? So we having somewhere to develop irrlicht towards. Because I seem to notice that Irrlicht is slowly but surely slipping away to becoming obsolete, with far too small a developer base available to work on the svn.

I do primarily use it for an architecture application, but also for a VR project and plan to use it again for games as well in the future. My long term target is using it in some AI experiments as well (was once the reason I started with 3D...). Don't know about other people's plans. And while I would like to see more people working in svn, there is one thing even worse than more people working - that is the wrong people working on it. The reason for that is that recovering from wrong decisions takes way longer (and is very frustrating) than writing any feature.

Not sure if current base-classes have any sane advantage over STL (I doubt it), but that's one of the examples for how hard it is to change a decision once taken (changing that would for example break nearly every project using Irrlicht, not exactly something you do lightly).

[Mel]

If you feel Ogre3D is better, then go ahead, don't let us stop you.

As for Irrlicht... I like it. Frankly. It allows you to create all the things ogre do, the only diference is that you will surely need to work more, which is a bad point for Irr, but, on the other hand, it may save you from much of the Ogre overhead.

I tried to use Ogre, and wouldn't go further than the examples. I've used Irr, and i am quite satisfied with it.

[Ethon]

And while I would like to see more people working in svn, there is one thing even worse than more people working - that is the wrong people working on it. The reason for that is that recovering from wrong decisions takes way longer (and is very frustrating) than writing any feature.

Are there plans to break backwards compatibility so Irrlicht 1.7 or below code may not compile with Irrlicht 1.8 ?
If not, thats the reason why its hard to improve the engine itself, if you always try to stay backwards compatible.

For example i'd love to rewrite the MeshCache (yeah, I like caches ) with better performance guarantees and optional thread safety. But that would require to drop the index-based access, which cannot be implemented efficiently with a tree/hashtable. So I guess it will stay like it is forever.

[CuteAlien]

We break backwards compatibility in major versions, but you can't do that lightly. Even minor interface breaks will cause forum posts for years about people trying to compile old stuff. And no user likes having to rewrite code because an engine decided to improve something (probably not even affecting him, just causing more work...). So breaking interfaces is sometimes unavoidable - and it's at the same time about the worst you can do when developing a library.

[hendu]

If I remember correctly the MeshCache still uses an array and a binary search instead of a RB-Tree/Hashtable, right?

Yes, but I have provided a patch to that effect over a year ago You can find it in the open discussions forum if you're interested.

As you can probably guess, using a Red-Black tree it scales much better.

[Ethon]

If I remember correctly the MeshCache still uses an array and a binary search instead of a RB-Tree/Hashtable, right?

Yes, but I have provided a patch to that effect over a year ago You can find it in the open discussions forum if you're interested.

As you can probably guess, using a Red-Black tree it scales much better.

Yeah, I saw that patch and was kinda annoyed that it was never accepted.
But well, it depends, for low numbers of entries the array-solution is better, because of its better (CPU)cache locality. Imho a hashmap would be the perfect solution, but it suffers the same problem, it can't be done with index access.

[ACE247]

Maybe we should start a separate branch project to Irrlicht that can afford take on such changes. Maybe create a 'IrrEngine'?
What do you think? Make a new thread probably.
PS: Why isn't the word Irrlicht in the forums word list!

[CuteAlien]

@Ethon: Also was never denied if I remember correct. Don't have that one in mind too much right now - this is about optimizing getMesh by putting meshes into an map instead of an array? On first thought not sure if that would make sense - I mean getMesh can cause file-access if the mesh is not already in memory, so that's nothing you should ever call inside speed-critical code anyway. While going over all loaded meshes for example sounds more like something that could make sense in speed critical code - and that would be a lot slower then. But probably there are situations I don't see by thinking about it just for a minute. Without writing a test first I couldn't even tell at which size map-access starts getting faster than array-access on modern systems (I just recently learned that even inserting elements into arrays is these days faster than inserting elements into lists - independent of the listsize! - eat that O-notation).

@ACE247. Yes, that's what I also do. I often add patches first to own engine versions. And many of them get rewritten after beeing used for a while before I add them to the official engine as I often miss the real problem on my first try. Also I have still a lot of my own patches not applied which are open for years because I never found time for cleaning them up enough and I'm scared of messing up the interfaces, but they are still useful for myself in the meantime.

Not sure which word list you mean... I've only noticed the list of forbidden words so far and won't add Irrlicht to that :-)

[hendu]

@CuteAlien

In the thread there were benchmarks for the mesh cache, but it also replaced the texture cache. I found load time improvements even with small scenes of ~20 meshes.

It's all the unnecessary sorts that really eat the performance.

[ACE247]

I mean the spelling wordlist

[CuteAlien]

@Hendu: yeah, sorry, not yet on my todo (that's too full already). But still not sure if loading is really the place you want to have optimized, as you usually don't do loading in a speed-critical part of your application anway. So if you save a second on loading while maybe costing 5ms while going over all meshes it can be hard to tell what is better. Optimizations in a 3D engine should mainly be about things that help to get a smooth framerate, that doesn't mean optimizing loading isn't worth it, just something you have to be careful - you never want to reduce framerate for any reason. If there are unnecessary sorts (again - I didn't check now, just writing the answer in between while working) my first guess would be because the array has still no insert into a sorted array (which it also shouldn't get but instead there should be an algorithm using iterators for doing that which then also works with list and string like in STL, so that might be the real problem that should be fixed).

[Kojack]

@Kojack you know exactly what I'm talking about with OGRE, once something becomes popular with a certain type of use/crowd its developed more towards it.

True, games do tend to be a driving force for most 3d programming. I just had an issue with claims that ogre is aimed only at games (when that isn't true), especially since irrlicht contains support for md2 (a game format), md3 (a game format) and quake3 bsp (a game format). Ogre does have quake3 bsp as well, but no other game specific formats.

One of my previous students make an awesome game with irrlicht. It was a 3d pacman with weapons and destructible environments, using lua for scripting. 5 years later and I'm still showing it to new students as an example of what they should aim for. On the other hand, a couple of my previous students are using ogre at a company that does architectural visualisations for government clients. Both engines have features that may be bloated for simple serious use (both have particles, fog, skeleton animation, skyboxes, shadows, shaders, etc, all of which is overkill for a serious app that just wants basic wireframe or flat shaded rendering).

While there's a lot of differences in actual implementation, the higher level overview of both engines is very similar, more so than if you compare them to things like Unity or UDK.

[REDDemon]

I used several engines, Irrlicht is not perfect but suited my needs. Still one of best opensource engines.

[Virion]

@Ethon, not using STL is great it means it works only with what it needs!

Nope. Every major C++ compiler has a good STL-implementation today and ships it by default.
Irrlicht reinvents the wheel and consists of many container/algorithm implementations which are less efficient than the STL counterparts, not to mention that the design is not as good and it's pretty annoying to convert std::strings to Irrlicht-Strings all the time.
If I remember correctly the MeshCache still uses an array and a binary search instead of a RB-Tree/Hashtable, right?

I remember niko himself said it before. He did not use STL because at the time Irrlicht was created, STL wasn't well supported by all compilers. That's an old story anyway.

EDIT: Found the link: http://www.irrlicht3d.org/pivot/entry.php?id=232

[REDDemon]

well STL is still slow for certain games, why supporting that when we could directly switch to faster alternatives? If I remember correct EA did a faster STL version exactly for making games.