Occlusion Culling

[micheallarkin]

I'v been given the task of making use of occlusion culling in our system (City Scene, lots of characters and buildings). I'm having trouble finding much information on what Occlusion culling ogre provides, I know there's HardwareOcclusionQuery stuff in the renderSystem, but I can't figure out where to start with it. I need to cull buildings against other buildings, and the city characters against the remaining buildings. Can anyone point me in the right direction?

[xavier]

Ogre provides no occlusion culling. the HOQ class is simply an interface to the hardware capability. The only effort to produce a working scene manager based on HOQ was done by Tuan Kuranes a long time ago, but we found it largely unfinished and buggy.

You're starting from scratch, in other words.

[micheallarkin]

Thought so! Thanks for the response, I'm going to have a go at using the Hardware Occlusion Culling, I'm just trying to make sense of it first. Would this be the right way to go about using it?

I'm not going to occlusion cull my buildings initially, I just want to cut down on character updates, my world will be split into bounding boxes that I define for a group of characters.

Code: Select all

1. Render my static geometry (buildings), in some simple form, a low level of detail mesh, and basic shaders. 
  
2. For Each Node

     Create a Hardware Occlusion Query
          beginOcclusionQuery()
               Render a box representing a group of characters
          endOcclusionQuery()
     3. If that box has visible pixels, set the entities inside that bounding box to Visible(true)

4. Render all visible geometry at full detail

I assume I can do this without altering the SceneManager too, but It's not a problem if I can't.

[madmarx]

1/
I have seen Occlusion culling done in ogre with a custom software renderer(with no zbuffer) running on the cpu, it was on a french blog.
And it was done with Ogre.

2/ what you propose seems ok to me, if you don't mind seeing things desapearing and popping from time to time.
+ not sure about effiency if you got 5000 bbox to test.

[xavier]

Just don't wait for the results of the query in the current frame. tuan tried to make the claim in his code that the process is fast enough, but even after many days of trying to make his code work, we still got abysmal frame rates with it.

You need to issue the command and process the results in a later frame. If you stall the GPU while waiting for the results immediately, you are defeating the purpose of doing the query at all -- you might as well just render the geometry. you can exploit temporal and spatial coherence in the frame render -- chances are the camera is not moving more than a fraction of (or at most, one or two of) a degree on any axis each frame, so what was visible now will likely still be visible the next frame, and what was hidden, similarly will still be hidden the next frame.

You'll need to tweak (for your needs) the re-issue logic of course -- you don't necessarily want to query every potentially-visible object every frame, but you also don't want to leave too much time between queries. You will also have to decide whether you can stand popping, and how you want do deal with that (perhaps make the object bounding volume a bit larger, that sort of stuff).

In other words, there is a reason that Umbra is still a viable product.

[_tommo_]

I think that the problem can't be really solved on modern cards... at some point you will need to access the render texture with the CPU, and this slows the pipeline more than a standard render...

Maybe it would be different if you made the visibility check completely on the GPU (eg. killing occluded triangles), but as for today i would stick with frustums and boxes

[micheallarkin]

Nice comprehensive answers, cheers!

One more thing, not so important but I'd like to understand it. If I issue a query in one frame, but don't want the results until a later frame, the gpu can complete other tasks while that query is happening? Or, is the explanation that the query executes when the gpu is Idle?

I'm aware I'm going to run into a lot of problems implementing this, but it's an academic exercise if nothing else...

[Praetor]

For far more detailed information on what to do look up Coherent Hierarchical Occlusion Culling. There was even a CHC++ paper I found that supposedly used Ogre as its test framework, but I wasn't able to get in touch with the authors about it. It made a few batch count and stalling improvements on the regular CHC algorithm. Anyway, searching for that should give you a lot of information.

[nullsquared]

If I issue a query in one frame, but don't want the results until a later frame, the gpu can complete other tasks while that query is happening?

That's correct, several things are done in parallel. If you try to read back the results the same frame you issued occlusion query, you end up with what is known as a stall while the GPU completes this specific task and returns the results to the CPU.

[xavier]

I think that the problem can't be really solved on modern cards... at some point you will need to access the render texture with the CPU, and this slows the pipeline more than a standard render...

Maybe it would be different if you made the visibility check completely on the GPU (eg. killing occluded triangles), but as for today i would stick with frustums and boxes

You are not accessing a render texture. The GPU is wired (since the GeForce 3) to treat the HOQ as a first-class command, and the results are returned to the CPU "when convenient", by the drivers. Usually this means "when the bus is not owned by someone else".

[syedhs]

You can also take a look at new feature of the latest SceneManager plugin - PCZPlugin which is a portal-based SceneManager. The sub-forum is here:- http://www.ogre3d.org/addonforums/viewf ... 8e0ede4337.

In it, there is a new feature being developed which is Anti-Portal that is suitable for out door object culling (portal is suitable only for in-door object culling). The plugin is wonderful, but I haven't managed to play around with it.

[_tommo_]

You are not accessing a render texture. The GPU is wired (since the GeForce 3) to treat the HOQ as a first-class command, and the results are returned to the CPU "when convenient", by the drivers. Usually this means "when the bus is not owned by someone else".

But... have HOQs been used in real-world games? I had the idea that games still used CPU to find occlusion...

[beaugard]

AFAIK, CryEngine 2 uses HOQ almost exclusively for culling.
In addition to using lagged results, you need to use some good partitioning system for geometry (like octree) to batch objects for visibility determination, it will never be efficient to have one HOQ per object.

[Halifax]

Well, I have no idea, but I think that conditional rendering is an extension in OpenGL 2.1, and a core function in OpenGL 3.0, right? If so, I'm pretty sure that's meant to keep things purely on the GPU with no need to read back the values to the CPU. Might want to look that up, and implement it in Ogre if it isn't already in there.

Ah, it looks like it is nVidia specific in OpenGL 2.1: http://opengl.org/registry/specs/NV/con ... render.txt