What Irrlicht has over Ogre...

[IPv6]

Another 2 cents in this flame war: there was mentioned that Ogre using STL and this is good.

This is wrong.

All high-class game companies does not use standard STL after all (EA, Valve), so Irrlicht is right in not relying on it.

To learn why STL is not good enough for game development read Introduction from this article for example (Electronic arts approach to replace stl with custom implementation)

http://www.open-std.org/jtc1/sc22/wg21/ ... n2271.html

[hybrid]

Indeed this is what I have experienced in my last programming contest. We had to prototype an application which handles lots of data. Writing it with STL was done in about two hours. However, processing the data took several hours. Compared to a lower-level implementation by another group which made the same in only some minutes (using almost the same algorithms) was compelling. I thought that STL was much better optimized, but it's not. And you will always have to create your on adaptions of the containers to better fit your requirements in performance critical situations which is much easier with your own implementation.

[mp3]

I do not think that using STL somehow bars in developing game or graphic engine. Motivations of EASTL are ridiculous and seem to be formulated a long time ago. They don't like debugging containers? Well in newest visual studio this is fixed. Bad allocators? Well you can create custom in STL. STL extensions are not portable? Have they seen boost? And they create another implementation that depends only on their support and argue about flexibility? They don't like STL names? I begin to doubt who wrote this motivations programmers or documentation support team.
STL is known to be most reliable of most fastest libraries.

The STL puts an emphasis on correctness before practicality and performance ... in some cases (particularly std::allocator) it gets in the way of usability and optimized performance.

No experienced programmer will buy this argument.

[IPv6]

EA is not the only company that dumped stl i know the team which is doing commersial MMORG, they declined STL too (after a year of using it), rewriting it with own implementation, gaining huge boost in speed and less memory-related pains in MMORG server. Valve. Nival interactive/Nival Online. You think they didn`t see Boost? Don`t think so. Memory management is the real issue, especially in PC/console cross development.

May be arguments are not clearly depictive (that is why STL is widely adopted - it is good on most tasks), but i`ll think that several companies will not reinvent the wheel without need.

[mp3]

Here are my coins to discussion. I could have misunderstood something. So correct me if I do.
I totally agree that you can compare separate features of both OGRE and Irrlicht, but when it comes to game programming there is no one recipe. The only thing that plays is programmer experience. Because if you intended to produce something significant you will need to extend any of those frameworks to fit your needs or wait indefinite amount of time while they evolve.
Now my experience.
About Irrlicht. Your stuff is been rendered in short time after start: no example frameworks or boring config files. But devil is in details. Material system. Well there is no such entire system. There is irr::video::SMaterial and shader support separately. When exporting something from 3d editor you often should write fix and hack to make it work. No material scripting. I will not describe animation because changes are shortcoming. Performance is very good. Irrlicht supports space partitioning through quake3 bsp. They say outdated but still very fast and reliable format. I prefer own portal implementation but this is hard and not trivial task.
About OGRE. Its a bit time to start but soon you find out that everything is rendered perfectly and precisely as it is in you 3d editor. OGRE has its own mesh format and scripting material system and exporters for most 3d editors. You've got your mesh transported from editor to your program with a few clicks and edit materials and shaders in scripts (very convenient) with no coding efforts. Everything is done for you. Or almost everything... You want to display your 3d level with some indoor corridors (like Quake) or outdoor island with trees (like FarCry)? So, you need to write your own scene manager! I am not joking: OGRE Eihort natively supports only terrain mesh scene manager (details are here).Writing own scene manager is not easy. There are some community attempts to write own portal system and engine authors promise to support this in future, but again - wait indefinite. Another discussed here drawback of OGRE is its large libraries and memory usage. Again they say that's normal for big games (sorry, do not say 'games' because they are offended diminishing OGRE to game only engine. And I do not understand why - games are now cutting edge of 3d technologies). Also you can recompile it with needed features only. But their license: you should be careful recompiling for commercial project.
For now I stay with Irrlicht. Why? Because anyway creating a game means extending engine. I do not need all cutting edge 3d technologies. Many of them could be implemented in Irrlicht. And the last but not least - engine interfaces. It's not all about beginners. Easy understandable, good named, structured interface relieves programmer from doing lots of odd job. IMHO interfaces are the main reason why why Crystal Space hasn't got massive support. And Irrlicht here is the best (though, I still want to cry looking at some places where they are implemented).

[agi_shi]

@ STL argument: THIS IS FOR THE PC PLATFORM. We are very little "limited" in memory.

Here are my coins to discussion. I could have misunderstood something. So correct me if I do.
I totally agree that you can compare separate features of both OGRE and Irrlicht, but when it comes to game programming there is no one recipe. The only thing that plays is programmer experience. Because if you intended to produce something significant you will need to extend any of those frameworks to fit your needs or wait indefinite amount of time while they evolve.
Now my experience.
About Irrlicht. Your stuff is been rendered in short time after start: no example frameworks or boring config files. But devil is in details. Material system. Well there is no such entire system. There is irr::video::SMaterial and shader support separately. When exporting something from 3d editor you often should write fix and hack to make it work. No material scripting. I will not describe animation because changes are shortcoming. Performance is very good. Irrlicht supports space partitioning through quake3 bsp. They say outdated but still very fast and reliable format. I prefer own portal implementation but this is hard and not trivial task.
About OGRE. Its a bit time to start but soon you find out that everything is rendered perfectly and precisely as it is in you 3d editor. OGRE has its own mesh format and scripting material system and exporters for most 3d editors. You've got your mesh transported from editor to your program with a few clicks and edit materials and shaders in scripts (very convenient) with no coding efforts. Everything is done for you. Or almost everything... You want to display your 3d level with some indoor corridors (like Quake) or outdoor island with trees (like FarCry)? So, you need to write your own scene manager! I am not joking: OGRE Eihort natively supports only terrain mesh scene manager (details are here).Writing own scene manager is not easy. There are some community attempts to write own portal system and engine authors promise to support this in future, but again - wait indefinite. Another discussed here drawback of OGRE is its large libraries and memory usage. Again they say that's normal for big games (sorry, do not say 'games' because they are offended diminishing OGRE to game only engine. And I do not understand why - games are now cutting edge of 3d technologies). Also you can recompile it with needed features only. But their license: you should be careful recompiling for commercial project.
For now I stay with Irrlicht. Why? Because anyway creating a game means extending engine. I do not need all cutting edge 3d technologies. Many of them could be implemented in Irrlicht. And the last but not least - engine interfaces. It's not all about beginners. Easy understandable, good named, structured interface relieves programmer from doing lots of odd job. IMHO interfaces are the main reason why why Crystal Space hasn't got massive support. And Irrlicht here is the best (though, I still want to cry looking at some places where they are implemented).

WHAT? Eihort comes with hordes of scene managers (and using different ones is as easy as typing in a different name to "createSceneManager()").

1) Default - not optimized, just for "getting stuff on the screen".
2) Terrain - small terrain, nice and easy.
3) BSP - quake III style BSP
4) Far Terrain - bigger terrain, nice and cool.
5) Paging Landscape - practically "infinite" terrain and foliage, etc.

And there's the plugins:
1) Portal-connected zone culling: F.E.A.R.-style culling
2) A second paging landscape.
3) Some "dotscene" that I never figured out.
4) And a bunch of others.

What's your problem? One manager cannot do everything. Terrain culling is useless in "corridors". Portal culling is useless in "forests".

[IPv6]

2agi_shi: "We are very little "limited" in memory" - this is really a hasty conclusion. If we are talking about tiny game without ambitions - yes, limits are not important, but there is no difference which engine to use in this case. But even moderate game starting to demand good memory management, because poor one may be not visible at the beginning but starts to hit performance after an hour of gaming for example - when fragmentation reaches the limit.

P.S. Material scripts i think will be added in some form sooner or later. This is what really seems to be useful and time-saving. The only thing that i miss in Irrlicht is VBO.

[mp3]

This is off topic but as for STL the only argument I've seen here is memory allocation. But for which implementation? MS, Borland, GCC etc? As I know STL doesn't limit you in implementation of allocators. And second there is only few bottlenecks in application that may need avoiding stl. You can use there some simple hacks. But reimplementing whole STL for these few moments is imho unjustified. This is the business for huge companies and team leaders who can afford this. You know, if I have owned a veeeery big corporation for game making I would rewrite Windows (and remade all consoles!) cause its memory memory management is unefficient for games ':D'

Eihort comes with hordes of scene managers

1) Default - not optimized, just for "getting stuff on the screen".

Not for game scenes

3) BSP - quake III style BSP

I heard they stopped supporting bsp. And even want to drop this plugin from OGRE distribution in next releases. In any case for my own tests Irrlicht new support of bsp is much better.

3) Some "dotscene" that I never figured out.

You may have chance not to figure it out any more. As for last my check it is not compatible with Eihort.

4) Far Terrain - bigger terrain, nice and cool.
5) Paging Landscape - practically "infinite" terrain and foliage, etc.

And there's the plugins:
1) Portal-connected zone culling: F.E.A.R.-style culling
2) A second paging landscape.

There is one particular thing about these plugins - they don't come with sdk and not officially supported. That matters. They live in cvs, often don't keep in touch with new OGRE interfaces. Sometimes die. This is a problem for community. Especially for those who don't have large team to implement this from scratch. The link I gave above is the discussion of this problem. In a few words there is one stable well supported core of OGRE which supports only terrain (and still contains bsp) and many other volunteer implementations. But everybody knows the difference between community and official code. For some reasons OGRE team don't want to incorporate those contributions.

[agi_shi]

This is off topic but as for STL the only argument I've seen here is memory allocation. But for which implementation? MS, Borland, GCC etc? As I know STL doesn't limit you in implementation of allocators. And second there is only few bottlenecks in application that may need avoiding stl. You can use there some simple hacks. But reimplementing whole STL for these few moments is imho unjustified. This is the business for huge companies and team leaders who can afford this. You know, if I have owned a veeeery big corporation for game making I would rewrite Windows (and remade all consoles!) cause its memory memory management is unefficient for games ':D'

I agree. For a "huge game" rendering, physics, and AI will be your bottlenecks, not the STL.

Eihort comes with hordes of scene managers

1) Default - not optimized, just for "getting stuff on the screen".

Not for game scenes

Nope, perfect for certain games. Ogre isn't only for huge FarCry-type scenes, or huge F.E.A.R.-type scenes. You can use it for a small game of asteroids, for example.

3) BSP - quake III style BSP

I heard they stopped supporting bsp. And even want to drop this plugin from OGRE distribution in next releases. In any case for my own tests Irrlicht new support of bsp is much better.

Haven't dropped it yet. And I don't see how Irrlicht is better supporting BSP files. From what I saw so far, it misses some textures, textures that should be animated aren't, and everything is just ... weird-feeling. Ogre uses dynamic lights where the lights should be, animates everything as it should, etc.

3) Some "dotscene" that I never figured out.

You may have chance not to figure it out any more. As for last my check it is not compatible with Eihort.

Eh, never intended on using it.

4) Far Terrain - bigger terrain, nice and cool.
5) Paging Landscape - practically "infinite" terrain and foliage, etc.

And there's the plugins:
1) Portal-connected zone culling: F.E.A.R.-style culling
2) A second paging landscape.

There is one particular thing about these plugins - they don't come with sdk and not officially supported. That matters. They live in cvs, often don't keep in touch with new OGRE interfaces. Sometimes die. This is a problem for community. Especially for those who don't have large team to implement this from scratch. The link I gave above is the discussion of this problem. In a few words there is one stable well supported core of OGRE which supports only terrain (and still contains bsp) and many other volunteer implementations. But everybody knows the difference between community and official code. For some reasons OGRE team don't want to incorporate those contributions.

So what? Any good programmer can take them and change what's necessary to get them to work. I got the PCZ manager to work easily under GCC (it was intended for VC++ as far as I can tell). Yes, some die. But the PCZ is still under development. And it's so good that even if the original author leaves it, there'll be others to keep it up. sinbad mentioned including it in Ogre ~v1.6 if Chaster agrees (he obviously does and will).

Besides. The best Irrlicht can do is BSP. Do I see PCZ culling anywhere?

[mp3]

Let me correct myself: all my previous assessments were done for 3d action games (FPS and third person). This is the sphere of my interest and I pay attention to features of engines for this game type.
From this point I made assessment of OGRE scene managers. BSP (as everything in OGRE) is very precise. But in previous version (Dagon or smth similar) it was slow for standard and for my own maps. Irrlicht was very fast. After Irr 1.3 quake3 shaders are supported: let it be not so precisely as in OGRE but still very fast. With new OGRE Eihort my maps started to crash OGRE (although they ran on Irrlicht and Quake3), nobody could help and then they said those words I have written above: forget about bsp, it is past and probably will not be supported.
And the "Portal-connected zone" is my only hope in OGRE. I think it is only month from it's early release and I haven't checked it yet. Anyway until it is documented it will be hard to use it. I saw Electron made portals for Irrlicht, but to great community despair that code didn't evolved into core feature.

[monkeycracks]

Not everyone needs portals. Why include it into the engine?

[mp3]

Not everyone needs portals. Why include it into the engine?

Are you seriously? You know I never use blender importer. Some people never use GUI, material system or even octree scene manager. I saw once a post on forum where one user says he uses Irrlicht for splash screen in his application. So what is that bunch of stuff is doing there in the engine?
Do not offend. There is a common problem with a definition of rendering engine. What should it do: basic coverage of low level features or more complicated stuff? As for me, I understand rendering engine as a collection of functions for creation, loading and manipulation on 3d and 2d content under common interface. Everybody picks what he needs, and the more functions are available the better engine is. I think that's why portal manager, as it is said here is going to be included in OGRE. Thats why it is already there in Crystal Space. And I always said that when I come through all that tricky 3d theories and triangles there will be one for Irrlicht.

[monkeycracks]

For the people who need it, they simply download and use it. Otherwise it just adds bulk to it.

[hybrid]

Unfortunately electron left for IrrlichtNX so his extension was not added to the core engine. Niko also announced some stuff concerning portal culling some years ago. If someone has a nice implementation floating around I'm pretty sure that we can add it

[IPv6]

forget about bsp, it is past and probably will not be supported.

And what is the future? i mean what will be instead of BSP?