![Laughing :lol:](./images/smilies/icon_lol.gif)
Maybe...
Dont forget how easily changed Irrlicht is. I don't think there are as many varieties of ogre as there are for Irrlicht (IrrSpintz, lightfeather, that psp engine, lots of various patches and extensions...).
This is probably for a reason.
That's a good point - I hadn't thought of that. Though there is a good reason - OGRE3D at it's core is solid while Irrlicht still lacks in the rendering area. Compare the projects for OGRE3D and Irrlicht - see the difference?BlindSide wrote:![]()
Maybe...
Dont forget how easily changed Irrlicht is. I don't think there are as many varieties of ogre as there are for Irrlicht (IrrSpintz, lightfeather, that psp engine, lots of various patches and extensions...).
This is probably for a reason.
Good point though it's also apples and oranges. Ease of use will only get you so far. Sure you could write a simple demo in say five days, but beyond that you might find you need to re-write 55% of Irrlicht's rendering engine. Still good point.buhatkj wrote:some time ago I read a great analysis based on ease of use, which a guy did exactly the same scene, with the same assets, and saw how long it took him to implement it in several different ways, one of which was using irrlicht. of course, irrlicht got very high marks for its ease of use and powerful API.
perhaps to settle this question of performance we could do the same, scientifically. set up the same series of scenes (to demonstrate different effects), with the same # of polys, and same effects, textures, whatever in several engines, and see if irrlicht really is fundamentally suffering from poor performance. then maybe, we could look at why. till then, much of this is sort of speculation based on the relative performance of this vs. that. it could be we are comparing apples to oranges....