Hi everyone,

I'm trying to write some occlusion culling algorith. But I don't have a big experience in this subject.
Can you tell me what algorithm will be the best in occlusion culling technique (now I'm using octree hierarchy) ?

I have an idea but don't know who to implement it in XNA:

First I’m rendering all objects which will be occluding the scene (because of dimensions) – in this place I’m rendering only a mesh which will cover the scene.
It is rendered to the texture with a smaller dimension than original scene (320x240). I’m writing only the Z buffer. When I have this texture then I’m checking which nodes of octree are visible in this way:
for every corner of octree node check if its value is bigger or smaller than a value in the texture. If no one is closer to a camera then a octree node will be occluded.
But if at least one corner will be visible then we should render a node.
We have to transform a corner coordinates to the camera coordinates in some way.

It’s only theory. What do you thing about this? Please write your comment.

Thanks,
Rafal K.

The problem with this approach is that you need to do a read-back from the GPU to the CPU, and this is never a good idea.

Also, think what happens when you have a concave object that, by coincidence, cover the corners of the octree node, but doesn't fully cover the contents.

Occlusion Queries are a way to test for occlusions on the GPU, but XNA does not yet support them.

OK, You probably didn't understand something. If I'm rendering a mesh to the z buffer then I have properly values in this Z buffer. So I don't think about concave objects because it is not danger. I'm writing only a few objects with reduced mesh to the buffer Z so it will not  be too slow I think. Then I will compare the Z values from thexture to the octree nodes - it is importatn that I'm not comparing vertices from objects but only corners of octree node.

Ok, I understand.

But still, after you write those objects to the zbuffer, you want to compare the corners of the octree nodes, you need to get the Z buffer back to the CPU (unless you plan on making the corner comparison on the GPU. I'd be interested to see how you do this)

And to get that data back to the CPU you have to do a Texture.GetData(). (Besides, I don't even know if it's possible to read the Z-Buffer back into the CPU). And calling GetData() causes the whole GPU pipeline to flush, thus you loose a great deal of performance.

Yes, You have right. I have to get the Z buffer back to the CPU and put it to the array using getData.

But I'm not sure if I loose to much performance in comparison with other techniques e.g.
creating planes and running process which will be occluded other objects in the scene.
But as I wrote it is only a theory so I can be wrong:)

What technique do you use?

I don't use any technique right now, but I'm going to implement a simple octree in my current game. I don't worry much about occlusion, since the game I'm working on right now will have an isometric camera, so I won't have too many occluders.

Also, I don't worry so much about the vertex processing speed, as I worry about the pixel processing speed. For that, I have the Z-buffer to help me, and techniques such as deffered shading.

this is my approach

- use octree to retrieve objects that are in first depth slice of view frustum
- render these in "occlusion mode" ie: in white, simplified geometry, skip transparent
- render to small texture 64x64 for example
- read back texture
- for each pixel that is not white - query octree for contents and add to list
- now render that list to same texture and repeat
- now you have a list of objects that are visible
- render them for real

I use 8 depth slices

the big downside to this technique is the pipeline flush and readback per depth slice
but there are two solutions to that:

- temporal coherence: assume next frame is similar to this (i do not like this)
- shadow game state: always render game state from last frame - use current game state to calculate occlusion

shadow game state is an awesome solution as nobody notices a 1/60 second lag
but it can be complex for some applications

All good suggestions, but I would also ask, how sure are you that this culling is even necessary?

Culling (even if done cleverly) can be pretty slow, and modern graphics cards are very fast. I've seen many games that spend more time running fancy culling algorithms than they would if they just rendered all their objects regardless!

In my experience the sweet spot is often to just use a simple CPU side bounding frustum test to cull objects that are obviously behind the camera, and not bother doing anything more complicated. I think people are often thrown by the fact that CPU hardware hasn't been getting faster nearly as fast as GPU hardware over the last few years, so the balance of how much CPU work is a good idea in order to cull GPU work isn't the same as it used to be not that long ago, which means a lot of the advice and techniques that used to be a good idea aren't necessarily valid any more.

In my experience the sweet spot is often to just use a simple CPU side bounding frustum test to cull objects that are obviously behind the camera

If you target graphics cards with less filling power than the 9800 GTX or the Xbox, then you can do a lot better by doing better culling. If you can build a cell/portal system, for example, you can often get a lot of culling for very cheap. On my 64-bit laptop graphics, I have a level of "maze" canyons, and when I'm looking straight at a wall, with wall after wall behind it, the frame rate dips below 20. When I look in another direction, it's back up to 60.

Also, sorting opaque geometry near-to-far is a good idea, as you will get the benefit of early Z optimizations in fill rate.