Thread: some kind of occlusion culling

so i have my scene organized in some kind of tree (e.g. kd-tree, oct tree)
each node has a bounding object assigned to it (e.g. axis aligned cuboid (bounding box))

now i position the camera somewhere in the scene and want to render the stuff.
so i first check what nodes could be seen (so which lie in the frustrum), sort them in z-order and start pushing the contents of the boxes to the graphics card.

the thing now is that if i stand right in front of a wall i would probably render things that are like a kilometer away although they are occluded.

so is it a good idea to do the following (can it be even done that way?):

ok, the nodes to be drawn are sorted already (closest first)

i would say that when selecting nodes against some frustrum, always the nodes that just overlap or are completely contained in the frustrum are chosen. (instead of e.g. chosing all leaf-nodes)

Code:

draw the objects in the first visible node (that is the leaf the camera is in)

current_node = next visible node in z-order;

render the front sides of the current node's bounding cuboid (so at most the 3 sides of the bounding box
that can be seen from the camera position) but  just do depth checking, and count how many pixels would have
been drawn (but don't draw anything) )

if(0 pixels were drawn)
  skip that node and all children because its already occluded by previous objects
else (if there are objects in that node) {
  render all objects in that node
  move to the children (if there are any) and repeat the same procedure (thus: render their
  bounding box, and check if anything was drawn)
}

move on to the next visible node.

so is this a good idea to do that?
(is it even possible not to draw something, but do depth-testing, and just count the pixels? i am just about to start learning pixel shaders)

If you're using OpenGL, you can use the occlusion culling extension. There may be more work involved with D3D, but I don't really know.

hm ok ive just read through ARB_occlusion_query and this is bascially exactly what i had in mind.

but i think id like to reinvent the wheel for that test - cause i think its a good thing to learn shaders with - i mean can't be hard counting the drawn pixels

Might be a little difficult though, since shaders generally don't allow you direct access to the Z buffer contents.

hmmm... so i have read around with shaders - and it seems there is no way of letting a pixel (fragment) shader write to a "variable" that could be read by the application? (so communication between fragment shader and app is one way only)
or is there some work around for this?

No practical work-around. But theoretically, you could write variables as fragment data per-pixel, and then extract this data from the screen on the CPU.

>> No practical work-around. But theoretically, you could write variables as fragment data per-pixel, and then extract this data from the screen on the CPU.
>> can you render to a texture instead of the frame buffer, and access the texture's memory?

thats what i was hopeing to be able to avoid, since i would guess that would really stall the rendering process
(so setting a texture as a render target, then access the data, set the backbuffer as render target, continue rendering, setting a texture as the render target and so on)

if just the depth-buffer was accessible through a shader, and shader could communicate with the app via some "global" (per primitive) variable, then life would be so easy


but if there is no other way than to render to texture or get the depth buffer, how is occlusion culling implemented usually?

can you render to a texture instead of the frame buffer, and access the texture's memory?

Nope. You would basically be using the screen as a texture, since it's your only output.

but if there is no other way than to render to texture or get the depth buffer, how is occlusion culling implemented usually?

Usually with API methods like the occlusion extension in OGL (again, I don't know how it works in D3D).

Basically, you would precomute the visibility data of each node in your tree system, using OpenGL to do the dirty per-pixel stuff.

in psuedo code:

Code:

setViewToCurrentNode()
for(eachOtherNode){
  occluded = checkOGLOcclusion
  if(!occluded)
    mustRender
  else
    cantBeSeen //skip
}

With out the ability to check occlusion per-pixel, you would have to rely on basic scale+position+rotation information to use with your z-order info....I think.

Originally Posted by Bubba

So get the contents of the z buffer and pass this as a texture resource to a pixel shader

But there's no way (that I know about) to get the z buffer contents to be passed as a texture. Or do you mean things like vertex z-values, etc?

well of course i could read the whole z-buffer and pass it back in as a texture. but then i have to copy around the zbuffer all the time - right?