Irrlicht Engine

Wow, thanks guys for the new release and all the work you put into irrlicht!

Thank you very much for this Release, sounds good.
Some questions though:

Is the performance on weak machines noticably improved?

Occlusion Query... I read something about this... am I right with the following: It checks, whether something is behind something else before rendering it - ? Will this improve performance? do I have to activate it somehow, or is it activated by default?

Stencil Shadows: When I implemented them the last time, in an earlier version of Irrlicht, they were very slow and only for Demos, not for real games (because of their performance) - is it better now?

Thanks for any replies in advance, and sorry, if all that is already written somewhere, please give me a link if so. (I tried to read through the Changelog, but I didn't get much information out of it... sorry)

One thing that is noticably faster (around factor 10 in my tests) is xml-loading (including formats using xml like collada).
At runtime I don't know. There have been a few cases we improved, but no one has written a comlete performance test-suite so far, so I can't really tell.

Stencil Shadows are a good deal faster, but you have to be more careful now that models are correct (they have to be closed without any additional edges).

Don't know about effects of occlusion query on speed (didn't use those myself yet).

Occlusion querries in irrlicht are not designed to be fast enough to allowocclusion culling based on them right now so they are merely a way to know how much of your object is visible

Thankyou !!!

Nice work! Thanks.

Granyte wrote:Occlusion querries in irrlicht are not designed to be fast enough to allowocclusion culling based on them right now so they are merely a way to know how much of your object is visible

It's depend on Your scene structure and handling them. Occlusion Queries in Irrlicht works in the same way as standard Occlusion Queries system.

We recently added Occlusion Query for one of our games and It really works perfect.

Just popping in for a moment after remembering something.

I'm wondering if 1.8 has an extra z-index option by default (to prevent z-fighting), or something similar? I modified CSceneManager.h and re-compiled Irrlicht a few years ago that prevents z-index fighting for flat nodes in the same plane by allowing an extra z-index value for all nodes.

the features page says, it now supports OpenGL 1.2-3.x
so it finally has fully integrated opengl 3 renderng features?
more importantly, which version of GLSL should one preferably code shaders with?

Just read carefully. It says support for OpenGL 1.2-3.x (even 4.x). It does not state Irrlicht provides every feature that OpenGL 3.x supports. Not sure about GLSL, cou cannot use those versions where the vertex attribute system is required, though.

What's a reasonable threshold for saying something "supports" OpenGL 3.x though? Based on forum posts and the very brief mention on the features list, I couldn't find any serious evidence of there being a 3.x .. 4.x oriented portion of Irrlicht development. I'm currently looking at the code itself, trying to find keywords which might give evidence one way or the other. I'm inclined to believe that it's an OpenGL 2.x technology project and that anything higher is token support, not applicable to the real world.

I am currently doing a similar exercise with Ogre and ClanLib. Ogre 1.9 HG has a work in progress 3.x renderer that people are trying to shake some bugs out of. ClanLib 2.3.6 may have some 3.x support, not totally sure looking at that code. ClanLib 3.0 SVN has a clear, well rationalized 3.x source directory. Got it built, still assessing what it can or can't do.

bvanevery wrote:What's a reasonable threshold for saying something "supports" OpenGL 3.x though?

Because you have access to some OGL3 features from gpu driver level (those features aren't available without OGL 3.x Context) eg. MRTs with different pixel formats, GLSL statements from OGL 3.x etc.

Anyway we have in plans add support for Core Profile -> OGL 3.x/4.x driver with many of new features available only for OGL 3.x/4.x hardware.

It may be token support, but it's very applicable to the real world. Any number of things not in gl 2.1 can be accessed via extensions if your hw supports them, such as texture arrays.

I still find it mindblowingly difficult to recognize what OpenGL 3.x 4.x can do "in the wild," because of all the cockamany extensions and function pointer wrappers and getProc calls and hoopla and general engineering s***e that OpenGL has turned into over the past several years. If someone could make a blurb in the Features section, or even in the forum, with more detail on what's possible that wasn't before, I think that would help a good number of people. Also if there's any roadmap of 3.x 4.x stuff that has been done, hasn't been done but probably will be, hasn't been done and probably won't be for awhile or ever.

The forum search engine will not allow the word "opengl" as a search term because it is "too common." That's *really* irritating. I don't care if it's too common. I want to look up what people have been saying about it for the past year, not forever for all time.