Example 26 Occlusion Query demonstates something?

[mongoose7]

I ran up 26.OcclusionQuery.exe (debug build, 1.8.1) and got a frame rate of ~7295. I then held the space bar down and the frame rate *rose* to ~7345. I'm wondering what I should learn from this.

[CuteAlien]

Hm - usually what you see is a manhole and once you press space you see some sphere which was behind it. I suspect that's not what is happening on your system?

[mongoose7]

That's what I see. Everything is working perfectly, but to no real point.

It would appear that, these days, the occlusion query takes more resources than simply trying to render. The pixel shader would not be called on the occluded sphere.

[The_Glitch]

I agree with mongoose7 ^^ The example does the same on my computer.

[CuteAlien]

The example demonstrates how to use occlusion queries. That's the point. If occlusion queries make sense depends on your scene (and maybe on your system). That this isn't a real scene where they are needed seems obvious - the point is making the code easy to follow, not to get a high framerate for 2 trivial models :-)

[hendu]

Easy to fix by adding some heavy calculations to the sphere

[Mel]

But then, the occlusion queries should be somehow made useful, or else, although they are there, they have little to do. If, for instance, the engine used the occlusion queries on its own to perform efficient automatic culling of the scene nodes, it would be a noticeable feature, not just something almost cosmetic.

How about modifying the terrain rendering so it also used occlusion queries to speedup the rendering? or the Octree scene nodes? The octree scene node has already a data structure that, somehow, could be used to take advantage of the occlusion queries, isn't it?

[kklouzal]

I completely agree with you Mel, Occlusion Queries need a major overhaul. They're there right now but there isn't much of a use for them. Every 3D application needs Occlusion/Culling, more often then not both techniques are used, and more, to minimize draw calls increasing performance.

Occlusion however just sounds and feels like it should be automatically handled by the engine itself plain and simple.

[hendu]

I have yet to see any automatic "handled by the engine" occlusion query approach that actually increased performance. Certainly you can wish for one, but most such approaches are actually detrimental to performance.

[Mel]

Wouldn't it mean any sort of trade off? i.e. the best case scenario gets always worsened of course, but the worst cases may be alleviated somehow, the point of the occlusion queries is to allow for very large scenes to be renderable without the need of (excessive or offline) preprocessing. In this case, the target isn't raw performance, but the occlusion of many calls that, otherwise, would be indeed performed, but would give no result because of the coverage.

The Sauerbraten/cube2 engine (for instance) benefits from the occlusion queries to be able to render vast stages that otherwise would require some sort of preprocessing, and the Sauerbraten engine is capable of modifying the scenes in real time, thus, the preprocessing isn't really a posibility.

[kklouzal]

Does the engine even support any hardware culling? I know OpenGL & DirectX has the functionality. Even the hierarchical solution described here would be a huge improvement from what we have now and could easily be adapted so that the programmer could simply switch it on or off for the entire scene, or add specific scene nodes to a list and let it do it's thing from there, either way it would essentially be automatic.

As a side note when I post things like this I usually do my research. I don't have any personal agendas, I only want to see Irrlicht improve. :)

EDIT:
Added link to "the hierarchical solution described here" http://http.developer.nvidia.com/GPUGem ... ter06.html ;)

[Mel]

Irrlicht really needs many features that most graphics engines use by default today, the problem is that those features some people think that lie in the domain of the application program more than in the field of the rendering engine. Paged geometry rendering, dynamic node occlusion through occlusion queries, and the streaming of resources just sound so game specific that many people fear they would be doing somebody's else work without getting anything in return.

[kklouzal]

...features that most graphics engines use by default today, the problem is that those features some people think that lie in the domain of the application program more than in the field of the rendering engine...

If this truly is the case I may have lost my high hopes for this 3d engine. I am a strong advocate for Irrlicht promoting it everywhere I can and that made me genuinely sad :/

Here's another interesting article on culling as to not make this post completely irrelevant to the topic ;)
http://www.gamasutra.com/view/feature/1 ... hp?print=1

I also found this on the main page hehe

It is completely cross-platform, using D3D, OpenGL and its own software renderers, and has all of the state-of-the-art features which can be found in commercial 3d engines.

[CuteAlien]

@kklouzal: Yeah, that homepage-text was written a decade ago and never updated ;-) We can't compete in a feature-race with commercial engines (not sure if that's really so bad - I still love how easy Irrlicht is always to use for the stuff I need).

[Mel]

Yeah, irrlicht ease of use is its best characteristic, but it would be cool to have the most common features already in the engine (with the same ease of use, if posible ) and not having to reinvent constantly the wheel to use the engine.