Irrlicht Engine

hybrid wrote: So you say it's a matter of taste? Well, then it's not worth discussing, it's usually even not worth mentioning.

Uhm, no, he doesn't say anything to this effect. It is only you reading into it what you want to read into it.
Sorry, if I sound pissed or something, but your post is quite ridiculous.
You set up your own strawman and beat this instead of actually answering the points being raised, which have nothing to do with what you pretend them to be in your post here.

agi_shi's account might not be exactly oozing objectivity, but I guess it wasn't meant as such. He delivered an report of the experience he made. This was obviously not meant as an objective benchmark, so please hybrid, don't pretend he failed to do so, just because you expected it to be one.

I hope I have made it extra clear in other posts, that not one 3d engine is able to serve all. I want to stress this again. But to dismiss his experience report like this, without even addressing a single point he made is a bit insolent. He explicitly mentioned that shadows are available, but also mentioned the state they are in. And I don't believe this is the first time you heard it.

What kind of comparison do you need here? Irrlicht supports modulative stencil shadows. Ogre supports additive and modulative stencil and texture shadows. Stencil shadows there are better integrated into the whole render pipeline. They can be used together with vertex shaders that transform the vertices, unlike in Irrlicht. Ogre has a very advanced system of determining the hull of a mesh and caching it for more speed, Ogre uses double sided stenciling, which only requires rendering the mesh once instead of twice like Irrlicht does (one time front faces, one time back faces) Ogre uses hardware extrusion on GPUs supporting it, it has better culling and it automatically determines the algorithm to use, whether z-fail or z-pass. Irrlicht only has its own "capped z-pass" which doesn't really work in the cases z-fail is needed. (Like when the camera is inside a shadow volume)

I don't want to bad mouth Irrlicht in any way here. I only list this because, reading your post, you seem to doubt this as fact. What information do you need to accept it? Same is true for everything else you mentioned.

Yes, you are right: "Lights, shaders, shadows, everything's there for Irrlicht" too. But having the features just to put them onto the feature-list, or having them implemented in a way, that they are ready for prime-time is a difference. For shadows see my last paragraph, for shaders see what agi_shi wrote. Using shaders in irrlicht in a big project is a PITA, once for the reasons listed by agi_shi, and also because artists can't define the material to be used. this is imho a severe hit to the art pipeline.

STL not available on platforms Irrlicht is available? Like what platform exactly? Even Nintendo DS has STL available. (Though it is hardly used) So have PSP, XBox, etc..

hmm, should i suggest AGAIN, delete this thread, since it is quickly spiraling into a flame war AGAIN?

rooly wrote:hmm, should i suggest AGAIN, delete this thread, since it is quickly spiraling into a flame war AGAIN?

No flame war. I only mentioned my experience.

Seriously, I was all out Irrlicht in the beginning. Ogre confused me beyond belief. But now that I've made the switch (and have become accustomed to Ogre and it's complicated, yet fully-user-controlled and accurate features), I'm never going back...

Here, I've give you a little "insider" info... I was thinking of switching back to Irrlicht before I got my Ogre portals working. Ogre's RT system was just overly complicated...

You know what stopped me? Irrlicht's shader possibilities. My shader needs >10 parameters, and a pass for each light. Multi-passing is a b*t*c* in Irrlicht, and so is parameter binding. Irrlicht's shadow possibilities. I thought I can just live without shadows... but I couldn't. Just couldn't. Not in this generation of graphics.

Good that I didn't switch, though. I realized why Ogre's RT system was so complicated. It had a plethora of features and options you could use. TBH, I have no idea how I would've done my alpha-mask generation in Irrlicht (Ogre is simple, easy material scheme)... I need to render 1 object in full white, and EVERYTHING else in pure black, at maximum speed. And do this whole switching and generating without a speed impact. Ogre did it.

There are other shadow implementations available as an addition to Irrlicht. Also light shaders, light managers, all that stuff. That's what I referred to.
And the STL thing: If you really think that the optimization degree of the STL containers will give a 3d rendering engine an extra boost then have fun with your own engine. However, urging people to use STL almost doubles the memory footprint of a SW render application. See my post on embedded devices rendering. They even don't feature a full bloated libc.
So yeah, I realize that there are lots of reasons why situations require to use a different engine. I've never declined the necessity of other engines for different purposes. I've just warned about these kinds of threads and what happens if people talk too much without taking into account all things. I'm not in a position to make an objective comparison of any kind, though. But I can point out those things which I think were missing in the discussion.

well, here's what i think

Irrlicht has some things over Ogre and Ogre also has some things over Irrlicht, for Example Irrlicht nearly runs every where, i mean you can see it on a Pocket PC, PC or Mac, and it supports them well, and it's OpenGL capabilities are quite amazing, but Ogre is not, specailly on Linux (actully that's what i've read on the forums, i haven't used Ogre "yet ".

and of course Ogre has some features that are way over Irrlicht.

so here's what i've came up with:


The best solution to get a great Free OpenSource Engine, is to find some realy, really talented programmers "like the developers of both engines" and then if they worked together on a new engine, that makes use of both engine's features, i think that would make a great new amazing and dashing Free open source 3D Engine..

.........................

agi_shi wrote:TBH, I have no idea how I would've done my alpha-mask generation in Irrlicht (Ogre is simple, easy material scheme)... I need to render 1 object in full white, and EVERYTHING else in pure black, at maximum speed. And do this whole switching and generating without a speed impact. Ogre did it.

Umm I had to do almost the exact same thing to achieve shadow mapping in Irrlicht (Render whole scene using grayscale depth colours to a texture and then switch to normal scene and use the texture to calculate the shadow), and it works just fine...

So Im wondering what stopped you from achieving something so simple?

I'm just mainly looking at Irrlicht and even Ogre right now, but I think it mainly depends on how you feel about engine size and project dependencies. Ogre is very large and has a lot of dependencies, Irrlicht is small and has very few. Irrlicht handles more model types. Irrlicht and Irrclang together weigh in at about 4 meg, I think. I've seen people do a little asteroid game in Ogre and the thing is about 20 or 30 megs. I'm guessing it would be about 5 megs in Irrlicht. Ogre has a longer learning curve. Irrlicht is like a Swiss army knife, small and does a whole lot. Ogre is larger, very well written, but takes more to get a project underway. Maybe more companies use Ogre, but I think most individuals, hobbyists, casual game writers, would be better off using Irrlicht.
The whole thing about who is using what engine is pretty academic. The real question is which engine works best for the project you have in mind. Ive been through the Ogre tutorials and the Irrlicht tutorials and it's just amazing what Irrlicht can do with a small amount of code.

I am still with Irrlicht because imo Irrlicht is getting better and better. Irrlicht also has a lot of advantages: light, simple but the features are all there, just need to improve a little more.

Just like the upcoming new animation system. We got the animation system of course, and what we need to do now is to improve it. Thanks to those who are doing this.

beshrkayali wrote:well, here's what i think

Irrlicht has some things over Ogre and Ogre also has some things over Irrlicht, for Example Irrlicht nearly runs every where, i mean you can see it on a Pocket PC, PC or Mac, and it supports them well, and it's OpenGL capabilities are quite amazing, but Ogre is not, specailly on Linux (actully that's what i've read on the forums, i haven't used Ogre "yet ".

WHAT?! Where the HELL did you "read" that? Ogre's OpenGL rendering system is just as advanced as its D3D system. And it uses OpenGL 2.0, unlike Irrlicht, which uses 1.5.

BlindSide wrote: Umm I had to do almost the exact same thing to achieve shadow mapping in Irrlicht (Render whole scene using grayscale depth colours to a texture and then switch to normal scene and use the texture to calculate the shadow), and it works just fine... Rolling Eyes

So Im wondering what stopped you from achieving something so simple?

I couldn't figure it out with the "nice and simple" Irrlicht. I don't just have to render the scene, I have to only render the occlusion geometry in black without a performance hit.

fireside wrote: I'm just mainly looking at Irrlicht and even Ogre right now, but I think it mainly depends on how you feel about engine size and project dependencies. Ogre is very large and has a lot of dependencies, Irrlicht is small and has very few.

That is true. I do prefer Irrlicht's size - but then again, it hasn't all the capalities of Ogre, so it's justified.

Irrlicht handles more model types.

It's not about "more model types", it's about model features. Ogre has named animations, models that have tangents and binormals integrated into them (work seamlessly with animation), skeletons, etc. It's a very good, full format. It's not that hard to fire up blender and export stuff correctly.

Irrlicht and Irrclang together weigh in at about 4 meg, I think. I've seen people do a little asteroid game in Ogre and the thing is about 20 or 30 megs. I'm guessing it would be about 5 megs in Irrlicht.

True.

Ogre has a longer learning curve. Irrlicht is like a Swiss army knife, small and does a whole lot. Ogre is larger, very well written, but takes more to get a project underway. Maybe more companies use Ogre, but I think most individuals, hobbyists, casual game writers, would be better off using Irrlicht.
The whole thing about who is using what engine is pretty academic. The real question is which engine works best for the project you have in mind. Ive been through the Ogre tutorials and the Irrlicht tutorials and it's just amazing what Irrlicht can do with a small amount of code.

Yes, Ogre has a longer learning curve. Unless you know where to look for a starting point (Practical Application on their wiki), you'll be stuck.

And, yes, Irrlicht can do a lot in a small amount of code. But that's the problem. It's extremely easy to put up a BSP map and then use a simple FPS camera that listens on its own for input. But then you have no control. The BSP is controlled by Irrlicht. The camera is controlled by Irrlicht. When you need to delve deeper to do stuff, you'll be stuck. That's why, like you said, Irrlicht is good for individuals who just "want to get stuff on the screen". But making a game is not just loading a BSP.

It's extremely easy to put up a BSP map and then use a simple FPS camera that listens on its own for input. But then you have no control.

You can create a custom camera or just add a keymap to the FPS camera.
Why the hell would you need to edit a bsp map inside Irrlicht anyways. Seems a bit ridiculous to me.

monkeycracks wrote:

It's extremely easy to put up a BSP map and then use a simple FPS camera that listens on its own for input. But then you have no control.

You can create a custom camera or just add a keymap to the FPS camera.

That's what agi_shi probably meant. There is an easy to use FPS camera implementation inside irrlicht. If it suits your needs, you can just use it and you're done with it. Costs you five minutes. While it might be suitable for small demos you hack together in little time, it isn't good enough for a serious project. For instance, there is no damping, but if you want to make an FPS camera that feels good, you need damping.

This is the core of the whole argument to me. Irrlicht: ultimately easy to use, presets for common problems, but when the cases it is made for are not what you want, you're screwed and have to dive into the source of the engine and do changes. Ogre: ultimately flexible but complex. There is a very steep learning curve waiting for you. Ogre doesn't even have input. (it's a render lib after all) Every aspect of the engine and what it does is customisable. There is hardly ever the need to change it. Extending it, means using it, not changing it.

I restate :

You can make a custom camera.

I fail to understand what isn't flexible about that.

i'll say it in here to:

DELETE THE funking THREAD!

No, this kind of threads won't be deleted. But you can simply ignore it such that it moves into oblivion soon.

monkeycracks wrote:I restate :

You can make a custom camera.

I fail to understand what isn't flexible about that.

Yes you can make your own camera, there is no difference to how you'd do that in Ogre. The FPS camera in Irrlicht is to give you a head start, but it is not useful for projects where
It is not Irrlicht core business, it is dead weight in cases where you have your own camera. This is why I earlier argued, that this is more stuff for a utlitity lib on top of Irrlicht than in Irrlicht itself. Irrlicht is somehow in between being a pure rendering engine and being a game engine. It does much stuff outside rendering. (basic input, special case input, collision detection) There is nothing wrong with this.

My flexibility statement was targeted wrongly. It is better directed to materials, vertex format and shadows.

I'm not up to it anymore here. This thread got very heated and I am not inculpable in this. I apologize for it.