ogre and irrlicht thingy!!

[hybrid]

Nadro, are you older than 14? If so you should increase your social skills fast, if not you still have some time...
Discussion and competition are good things, but you have to start from facts. Non-constructive gossip will at most lead to flame-wars, but neither group will get some benefits from it. I guess many people here have deep respect for the Ogre community. And that's what you definitely have to learn.
Next time try to develop some serious figures and profound comparisons. Your list in the Ogre forum was a start, but as you saw it needs more than some simple lists. I think it's best to know both engines to a very large extent when doing some benchmarking or feature comparison.

[Duncan Mac Leod]

Ogre is good, but Irrlicht is better Irrlicht only require: good VBO, new Animation system for good mesh format and Shaders

What a nonsense! Just like my old car which needs an engine with more power, bigger wheels and a chassis like a Lamborghini Gallardo !

[hybrid]

We could try to make this discussion better, at least starting now

[rooly]

i say just delete the thread. it has spiraled to nonsense on both forums, and i for one really don't wish to have another "Which is better, irrliht or ogre?" flame war.
People stick with irrlicht because they like it more than ogre, and vice versa. It's really as simple as that.

[catron]

agreed, but if we are going to have this it needs a better name than 'irrlicht ogre thingy' . GEEZ!!!!

[omar shaaban]

Ogre is good, but Irrlicht is better Irrlicht only require: good VBO, new Animation system for good mesh format and Shaders

i saw the ogre forum topic posted by saturn and yeah nadro got attacked very much

I think it's best to know both engines to a very large extent when doing some benchmarking or feature comparison.

@catron: yeah it is a stupid name make another one i am very bad when choosing names

@rooly:first i didn't start the topic in ogre forum so don't blame me on that

second my topic inst talking about which is better but talking about why do companies choose irrlicht like as:
and individual programmers choose irrlicht
and i am not trying to make flame wars and

People stick with irrlicht because they like it more than ogre, and vice versa. It's really as simple as that.

so people born with a sticker on them on it the engine they have to use no i myself may switch from irrlicht to ogre so it is not about sticking it is just who is better!!
but until now what makes me choose irrlicht is that it's ease of use than ogre and irrlicht is more like a game engine where ogre is a mature rendering engine
that doesn't mean that irrlicht isn't a rendering engine!!

[vermeer]

The thing is that this of "companies"... I tell you , companies deal a very different way, if you refer to game companies...I've been in them, and they don't tend to care about indy engines at all, no matter how they're called. There may be some exceptio, but nothing that worths mention...
So, there's no free engine that is wildly used by game companies, sorry...

[omar shaaban]

So, there's no free engine that is wildly used by game companies, sorry...

ya every company has it is own engine !!

[kburkhart84]

According to what I've seen, more commercial games are using Ogre than Irrlicht. I would say the reason is simple. Some Irrlicht users(not all), avoid Ogre though they know it is much more powerful, simply because it is more complex and difficult to use. That level of power is probably important to most companies, who by the way probably contain programmers that aren't as new at it as most of us here at the Irrlicht community. In fact, I chose Irrlicht over Ogre(at least for now) for the same reason, so I speak from experience.

[vermeer]

what i referred to about, was as was told by someone who actually works in a aaa company, but he could be wrong, anyway. (I'v been in retail ones too, but not as huge)

but...

ya every company has it is own engine !!

well, seem to be all sort of formulas...
some do use an already proved engine, which was made for doing an older but popular game...
Many use Unreal technologie, or start from there, which is an extremely common way...Others, of course, do all their code by themselves...many use things like havoc, and loads of already famouse libraires, and other companies middleware...there, time is the main issue, more than money, I mean in the big ones. Also as time is load of money.

And I mean retail games.


It's allways been said Ogre is superior in graphic capabilities: havent checked lately, but maybe is true. I don't really care, anyway.

[omar shaaban]

According to what I've seen, more commercial games are using Ogre than Irrlicht. I would say the reason is simple. Some Irrlicht users(not all), avoid Ogre though they know it is much more powerful, simply because it is more complex and difficult to use. That level of power is probably important to most companies, who by the way probably contain programmers that aren't as new at it as most of us here at the Irrlicht community. In fact, I chose Irrlicht over Ogre(at least for now) for the same reason, so I speak from experience.

ya and i am one of those peaple but now i think after i finish my project if i finished it will see ogre!

[rooly]

i'm just wondering, omar, do you understand english punctuations? it would be much easier to read your posts if you would learn to use those.

[agi_shi]

Hm... Read below: I just wrote an unbiased review of Ogre vs. Irrlicht - my mind was actually set on Irrlicht in the start, so read on.

I *was* an Irrlicht user... but now I switched to Ogre. I'll give you it straight-up.

First I started with Ogre, and thought to myself - "w...t...f... I have to get thousand managers, a root, a scene manager, a render system, a camera, a viewport, a render window, and a separate input library on top of all of that JUST to make a simple demo without using the pathetic example application class".

So I switched to Irrlicht. Nice and easy setup - create a device, tell it about the window, you're ready to rock. Load a model, display it, you're done.

But that's where it ends. Once you get deep into the stuff, it just doesn't fit together anymore. For one, orientation. The example FPS camera didn't do stuff I needed it to do. So I decided to make my own camera scene node. Nope, because cameras can only look at stuff without any simple orientation.

So I said ... well, use the fps camera until I "really" need to switch it. Went to work on portals. Got a simple quad up. And it ended. So... I get rotations in degrees and that's it... Never managed to implement portals in Irrlicht (portals like prey and portal, not culling portals). I believe I had the transformation correct, but from there on it sucked. I couldn't get the texture coords correct, and there was no simple way of "copying" the texture to the screen efficient, to create an illusion of a "hole".

Then came shadows. Shadows must be cool! Not exactly as I though. Extremely glitchy modulating stencil volumes that ran at the speed of jelly.

So I went to the Ogre demos... man ... they looked good. Additive shadows (textured-based as well as stencil-based)... in a addition to faster, but less accurate modulative shadows... Self-shadowing.... Multiple shadows... It looked good, really good.

Shaders in Irrlicht are a pain in the a$$. First of all, only ASM/HLSL/GLSL is supported, which means you have to write two versions of each of your shader to be able to use both DX and GL. Since that's not annoying enough, you have to hard-code each and every parameter to the shader. No easy specification of "projection matrix". No easy specification of "here, shader, just use the view matrix". All hardcoded.

Ogre, on the other hand, supports built-in CG. But that wasn't the problem. The problem was that Ogre could parse .material scripts, instead of having you hard-code everything. And even better, it has a crap-load of default parameters it can hand you - view matrix... projection matrix... any light info. Camera info. Material info. All there by default. I haven't found a need to pass any parameters from my code so far, Ogre handles it all. Speaking of shaders... where's the easy multi-pass support for Irrlicht? With Ogre, you tell it " pass {} " and "scene_blend" (or the equivalent functions of the technique, pass, and material classes), and you've got multi-pass rendering EASY. With Irrlicht? You do it all on your own. Want 1 more pass? Change the material, re-render everything, specify everything on your own. 2 more? Do it twice. N more? Do it N times.

Another thing that ticked me off of Irrlicht is... I found no after-pass techniques. No compositor ideas, no overlaying, nothing. Ogre has both compositors and overlays. Implementing my portals was extremely easy as overlays (see below for proof, since you probably won't believe me).

Also, I never found the way Irrlicht handles nodes too interesting. A node should be a "holder", not data on it's own. In Ogre, it's logical - you want a mesh? Create an entity, tell it to use the mesh, and attach it to a scene node. In Irrlicht, you want a mesh? You have to use the mesh scene node. Oh, you want an animated mesh? Ogre: no prob, it's all handled - animated or not animated, we're cool. Irrlicht - oh... sorry, in that case you must switch your scene node to a different type, specifically for animated meshes.

Yes, Ogre seems extremely over-complicated at first. But once you delve into it, you realize WHY it's so complicated. Because once you get the hang of it, there's no pathetic hacks to overcome - there are no problems to solve - you just ... use it.

One more thing - why the HELL does Irrlicht code everything on it's own? Strings, lists, everything. This is also why I like Ogre. At first I though Ogre::String was it's own class, but it's a typedef for _StringBase. And guess what _StringBase is a typedef for? std::string. Ogre is smart. Irrlicht re-implements the whole wheel, but I see no good coming out of it.

These are probably *some* of the reasons as to why commercial apps use Ogre. There's a plethora more, but my hands are getting very tired.

** portal proof:



Yes, I know about Blizz portals for Irrlicht. But I don't like their implementation. They're render-system specific, and not too flexible. My portals, using Ogre, are extremely flexible - any shape size (no need for meshes), each and every portal is independent of the others... Etc, etc. (Not bashing the Blizz-portals, they're cool. Just showing what an amateur programmer can do with Ogre [me], and what a good programmer can do with Irrlicht [blizzard]... btw, the normal mapping with excessive specular lighting you see is also written by me - infinite lights, all fully calculated at the pixel level - supports spotlights, omni lights, and direction lights...)
(my video: http://www.jeepbarnett.com/narbaculardr ... ortals.avi
it's old, it's glitchys - I've fixed everything by now - but it shows off the general idea)

[hybrid]

Thanks for the proof that narrow-minded people are on both sides
So you say it's a matter of taste? Well, then it's not worth discussing, it's usually even not worth mentioning.
You did not get portals even running with Irrlicht with existing implementations? Man, with that knowledge you'd never make it with Ogre. Your facts lack some credibility.
Lights, shaders, shadow, everything's there for Irrlicht, many people use it. You don't like it, you leave it. That's ok, if you'd have asked we could have helped you. But that's also up to you.
And just because many people complain about it: Irrlicht supports some special platforms which might come without proper support for STL and other things. that's why there are some additional classes done in Irrlicht which can also come from elsewhere. You could write a wrapper for stl strings if you like. Should be no problem at all. But you won't get too much from it besides some additional memory usage due to c++ runtime library.
So again: Anyone out there who uses more than one 3d library on a regular basis and can do a better comparison/benchmark?

[agi_shi]

Thanks for the proof that narrow-minded people are on both sides

PHAIL.

So you say it's a matter of taste?

Wrong. Matter of well-supported, non-glitchy features.

Well, then it's not worth discussing, it's usually even not worth mentioning.

The above is wrong, thus this is invalid.

You did not get portals even running with Irrlicht with existing implementations?

Why use the stencil buffer? My implementation needs no stencil buffer, no API-specific functions, nothing like that. If only Irrlicht had some more straight-forward means of doing things (orientation, passes, etc.), my portals would've worked on the damn software device, even.

Man, with that knowledge you'd never make it with Ogre. Your facts lack some credibility.

Right... Since I'd never make it with Ogre, I've already made it. That makes sense, totally bull-poop sense.

Lights,

Yeah, fixed function lights. Some crappy PS1.* normal mapping and parallax mapping with support for 2 lights. No specular, no specular mapping, no emissive mapping...

shaders,

Yeah, to use a simple shader I have to hardcode a whole class to send in data every call-back. Really simple shaders there...

shadow,

A single stencil-buffer implementation that is slow as hell and does nothing more than darken (modulate) the area in shadow. It couldn't even self-shadow. I think it also used only 1 method, so if the camera was "in" the extruded shadow volume then everything went bonkers.

everything's there for Irrlicht

Multi-pass without hardcoding everything? Additive shadows? Texture shadows? Any scripts what-so-ever so everything doesn't need to be hard-coded?

many people use it

Yes, many people use it due to it's ease of getting up a BSP map on the screen. Delve deeper and you're stuck. Like I said, that is why no commercial apps are seriously using it (that WAS the OP's question...)

You don't like it, you leave it. That's ok, if you'd have asked we could have helped you. But that's also up to you.

Yup. You're right. Ogre has a community as well. A very large on, in fact.

And just because many people complain about it: Irrlicht supports some special platforms which might come without proper support for STL and other things.

So if they don't come with STL support, what makes you think they're going to support any rendering what-so-ever? After all, that's what Irrlicht is - a rendering engine.

that's why there are some additional classes done in Irrlicht which can also come from elsewhere.

I'll bet you 50 bucks they are less efficient than the std algorithms and classes. The Ogre devs realized this...

You could write a wrapper for stl strings if you like. Should be no problem at all. But you won't get too much from it besides some additional memory usage due to c++ runtime library.

Right. So you're saying that the Irrlicht wheel-reiventing classes are better, faster, and more efficient than the std classes?

So again: Anyone out there who uses more than one 3d library on a regular basis and can do a better comparison/benchmark?

I used them both in the beginning. I was focused on Irrlicht, so I told you guys why I switched.