PDA

View Full Version : Testing if a polygon inside(!) the viewing frustrum really would be drawn



smoooochy
04-09-2006, 05:03 AM
Hi there,

i have the following problem
i am programming a little opengl program where a lot of
objects are rendered. Basically all Objects are little
spheres which are inside a big cube, which is subdivided
in small cubes.
So all spheres are inside this big cube (the cube itself
is not drawn), and the cube is always completely inside
the viewing frustrum. The cube itself is subdivided
into 10x10x10 little cubes, and all the little cubes
have a reference list to the spheres which exist inside
them.
So when I am rendering I draw the spheres from front to
back using the little cubes. The problem is that I a m
drawing about 100,000 of these spheres. So the fps are
really low. But in fact, after drawing 3-4 Layers
of the cubes, around 95% of the screen are filled with
cubes, so from the last 6-7 layers nearly no sphere is drawn.

So I thought about it, and now I thought about
test-drawing the little cubes (not really drawing), and if any
pixels of them would be drawn, i have to draw the spheres inside.
(The problem is the cubes are inside the viewing frustrum,
so I cant use feedback mode :( ). So is there any possibility
to "testdraw" them, and realise if any pixel of them would be
drawn?

Or do you have any suggestion what I could do? (I use displaylists
for the spheres, I use an automatic LOD)

Thanks, smoooochy

Trahern
04-09-2006, 05:52 AM
I think that the Occlusion query (http://oss.sgi.com/projects/ogl-sample/registry/ARB/occlusion_query.txt) is what you want ( if I understand you correctly :) )

ZbuffeR
04-09-2006, 06:00 AM
You do the "test-render" with occlusion queries :
http://oss.sgi.com/projects/ogl-sample/registry/ARB/occlusion_query.txt

For best performance, check query results from previous frame (better parallelism).

Search this forum, there have been quite a lot of tips on the topic.

jide
04-09-2006, 07:56 AM
The problem with this approach is that you'll do all the OQ in hardware. So I'm not sure this will really help you. From what you'll read, you'll understan that it's greatly advise to do things during some process of the hardware OQ. If you have nothing to do, you'll both loose GPU and CPU time.
If the framerate does not really improve with hardware OQ, then try what's below.

So I can first advise you to try software occlusions. The fact that you base on cubes (supposedly static) is a pretended good start for common software occlusions. However, this is not a perfect task because you'll make some asumptions (that all cubes are fulling filled, which is wrong in your case).
So maybe try raytracing algorithms then.

Hope that can help.

smoooochy
04-09-2006, 06:23 PM
Thank you very much,
the occlusion test extension nearly
doubled the frame rate!

Thanks, smoooochy

AnselmG
04-10-2006, 01:04 AM
be careful when using OCs sequentially - that leads to stalling. maybe in your case you would do best to first render all your spheres into the depth buffer as Bounding boxes in front to back order and send an OC for each cube. when finished, clear the depth buffer and start rendering your spheres in front to back order - check the OCresult and only render the spheres if they are visible...
if you use the OC-results in the next frame your framerate will get higher, but the result won`t be conservative any more!

-ag

tamlin
04-10-2006, 01:18 PM
Yet another idea to test could be to, instead of using whole spheres for the occlusion test, instead just use billboarded circle planes. I think it will produce the same end result while reducing geometry dramatically.

Also, if the spheres are not intersecting, perhaps a single impostor texture used on a billboard quad could replace the geometry alltogether when actually rendering the scene? This of course assumes the sphere's aren't using different textures.

Trahern
04-10-2006, 02:51 PM
From his post I assume that he's already drawing only a simple cube for the occlusion test and only if it's visible he draws the spheres within. Which is IMHO optimal.

smoooochy
04-11-2006, 09:04 AM
Yes, I just draw a simple cube for the occlusion test. Actually this really works fine.

Do you have any other optimization-tip?
Because I really have to get every fps more...

I know the tips from red book and the opengl superbible, so are there any more from you guys?

Perhaps what about the datatype, better use
float or better use double?

Anyother tip (I am also using an little automatic level of detail)?

Thank you very much, smooooochy

jide
04-11-2006, 09:14 AM
Yes both float and lod could help increase the framerate.

As the hardware OQ give pretty much result, maybe you can try to do some optimisations on your spheres: render only half spheres pointing all to the camera eye. With some maths it can be quiete easy to do.
Also, you might want to divide your half spheres into more potions so that the OQ can have a better granularity.

Hope that could hlep.