Performance charts

[migizi]

So I was looking around the wiki and I saw the performance charts http://irrlicht3d.org/wiki/index.php?n= ... anceCharts. It showed an increase from 1.1 - 1.3 but it stops at that point. I'm trying to decide between ogre and irrlicht and it will come down to which has better performance. Has anyone been keeping performance logs between the versions to see how it has evolved?

[hendu]

They are close to equal in performance, you should choose on which you prefer to work with

[hybrid]

And sorry for not continuing with this performance chart. It was simply a very painful work, and I was switching my systems far too often at that time. Which rendered those values pretty useless, as only the relative change was really important. Moreover, the FPS of the example scenes are not too good to track in most cases, which makes this project even worse. Just don't use the values for direct comparison, as both the gfx cards and drivers as well as Irrlicht's foundations have changes significantly since Irrlicht 1.3

[migizi]

I'm not saying the charts had to be maintained, I was really just looking to see if anyone has noticed any performance changes from earlier versions to now. Between my testing with Ogre and irrlicht I like working irrlicht more but it comes down to performance. I have a feeling that irrlicht has better performance than ogre just from some of the complaints I'm seeing on the ogre forums. I know hendu says irrlicht and ogre are pretty much on par for performance but I personally don't have man power to write tests on each of these systems. But if no one has seen any regressions in irrlicht I'm probably just going to stick with it. It's much easier to work with than Ogre.

[devsh]

there is no optimal solution for optimization

forward and deferred renderer optimization often only benefit one and detriment the other

[migizi]

Many of the complaints on the ogre form had nothing to do how things were rendered by the fact that the code was built when single core was king. Some of the code complaints also point out that the engine will make many duplicate calls for rendering which lowers performance. Some of which they don't plan to fix until 2.0 which is at least a year away depending on when 1.9 is released.

[hendu]

Irr isn't multithreaded either, but at least any excess drawcalls are gone by now.

[migizi]

Oh I guess I haven't looked into that much, is it at least thread safe or plans to make it thread safe? I know that ogre isn't multithreaded or thread safe at this point.

[hybrid]

Irrlicht isn't either, though all things which are really worth being multi-threaded are not part of the engine anyway. In most cases, you'd want all components of the game engine to be parallelized, and Irrlicht would be just one component. So keep it in its own thread - due to the MT problems of OpenGL and DX it's better anyway. Only drawback for Irrlicht in this regard is that the loading also has to be done in the same thread as the rendering, or that you have to do some pre-processing manually.