PDA

View Full Version : Best way to do clipping?



padawan
04-12-2011, 10:59 PM
In general I think that it's better to let the GPU do graphics related stuff. I wouldn't say there is a discussion here. One of the things that I would like to leave to the dedicated hardware is the decision about what objects should be drawn.
However, if I want to do this I still have to build the whole environment, which can be pretty big, and send it to the GPU. Besides, some of this work can possibly be fairly expensive, like building an animation. If I know in advance that some objects won't be seen I can save some work not only to the GPU, but to the CPU as well.
I read something about OpenGL feedback, but that obviously wouldn't really solve the problem. Besides, the FAQ clearly says:


Typically, OpenGL implementations don't provide a fast feedback mechanism. It might be faster to perform the clip test manually. To do so, construct six plane equations corresponding to the clip-coordinate view volume and transform them into object space by the current ModelView matrix. A point is clipped if it violates any of the six plane equations.

So my question is: what is the best way to find out if an object has to be drawn or not? Better everything done by the GPU? By the CPU? Divide between the two?

Thanks

Alfonse Reinheart
04-12-2011, 11:14 PM
what is the best way to find out if an object has to be drawn or not?

There isn't one. Culling is not something for which there is a general solution. There are many solutions, but each have their benefits and drawbacks. There isn't one that could be considered "best" by any measure, nor is there one that could even be considered "average" or "default".

Indeed, there aren't a lot of "best ways" to do anything in graphics. Pretty much everything is a tradeoff of one form or another. The only way to know what the "best way" for your needs is is to learn several ways of doing something, then measure the performance for your application, and pick the one with the lowest performance.

padawan
04-12-2011, 11:27 PM
Wow, that's a fast answer, thank you.

Okay, so basically everything is up to me. Which leaves me with a lot of flexibility, but also with a lot of doubts.
Are there maybe any references I can look at? Books? Articles? Some generic considerations about performance issues? Would be nice to clear things up a bit

ZbuffeR
04-13-2011, 01:01 AM
The general idea is if you can cull complex objects quickly on CPU side, do it. For example by checking the bounding box against frustum pyramid.
If the check involves complex work for a lot of triangles, it will probably not be worth it.
Hardware occlusion queries can help too, if you have big occluders such as buildings hiding complex geometry.
This overview can help :
http://geck.bethsoft.com/index.php/Occlusion_Culling
For OQ to be efficient, it is best to work on crude placeholders, and do other stuff before asking for results (for better paralellism).

padawan
04-13-2011, 02:12 AM
The general idea is if you can cull complex objects quickly on CPU side, do it. For example by checking the bounding box against frustum pyramid.
If the check involves complex work for a lot of triangles, it will probably not be worth it.
yeah, that's more or less what I was thinking. My idea would be to compute a rough minimum and maximum value for x,y, and z. All objects that have one of the coordinates outside that range will be excluded. In that way the CPU gets only light work, but saves a lot to the GPU, which will only have to do the more detailed filtering.


Hardware occlusion queries can help too, if you have big occluders such as buildings hiding complex geometry.
This overview can help :
http://geck.bethsoft.com/index.php/Occlusion_Culling
For OQ to be efficient, it is best to work on crude placeholders, and do other stuff before asking for results (for better paralellism).
Interesting link, thanks. I was expecting something like that to give more work to the CPU than necessary. The computations behind that don't look trivial, and my first thought would be to leave them to the GPU. Maybe I'll have to look at it.