Culling problem & GPU utilisation.

Started by
8 comments, last by crowley9 16 years, 2 months ago
Hi all, Take the following birds eye image: Now a naive culling algorithm would remove the solid object from the view, but there is a light behind the object that is causing the object to show a shadow, I'm curious to how is this problem handled? Also, this may be a how long is a piece of string question, but where does the GPU spend most of its time in a typical game (no clever answers like 'inside the case' ;)) Much appreciated, NB.
Advertisement
Most of the time a light in your scene wont be shining on everything you can see anyway. So you're going to want to go through and acquire objects just for the light, much like how you go and acquire objects for your camera view. Then it shouldn't really be a problem.

If you want to do some more work you can see if some of the light's objects are out of the view of the camera. Then you can render them only to the shadow map, and not try to draw it to the screen.

I would imagine most of a GPU's work is done executing pixel shaders, with executing vertex shaders as a close second.

Hi,

You could consider the shadow as a separate object and perform the frustum culling for it.

Cheers!
Advanced Light and Shadow Culling Methods by Eric Lengyel will give you some ideas how to deal with this.
Thanks all,

Quote:
Advanced Light and Shadow Culling Methods by Eric Lengyel will give you some ideas how to deal with this.

Ooh, it seems a complex problem. ;)
Cascaded shadow maps solve this probleme in an elegant way. They always cover the view. So not such a big challenge.
Thank you, looking into them now. :)

NB.
Any decent shadow mapping implementation will at least cover the view, that's pretty much a given and not specific to any particular technique. The slightly more interesting problem is choosing which objects to actually render in the shadow mapping pass. Like a previous poster mentioned, one method is to use the light frustum itself to cull objects. If the object it completely outside both the view and light frustums, then cull it away, otherwise render it. You can usually get away with s somewhat conservative culling algorithm since the shadow map pass won't use any fancy shaders other than depth output. If your hardware supports depth-stencil textures, then you can probably disable color writes completely depending on your shadow mapping implementation.

Just some food for thought. As always, play around with it for best results :)

Quote:Original post by NewBreed
Also, this may be a how long is a piece of string question, but where does the GPU spend most of its time in a typical game (no clever answers like 'inside the case' ;))

From my experience, I would guess a lot of (but not necessarily most) time is spent idle. Games are typically CPU-bound, meaning that the GPU spends a lot of time sitting around waiting for draw calls from the CPU, which is busy doing "everything else"; especially if you're using high-end DX9/DX10 hardware. Perhaps a visually intensive game like Crysis would tax the GPU a bit more, but I really haven't sat down and done extensive benchmarking with a bunch of different games :)
Quote:
Perhaps a visually intensive game like Crysis would tax the GPU a bit more, but I really haven't sat down and done extensive benchmarking with a bunch of different games :)

Maybe one day I'll sit down and do some profiling once I've got to grips with OGL and shading 100%. Thanks for the tips. :)
Geometrically, what you want to do is cull an object from the shadow map rendering pass if its shadow volume intersects the view frustum. This is slightly tighter than culling an object if it doesn't intersect both the light and view volumes, since the light volume(s) usually encompasses the view volume (or view volume slice in the case of layered shadow maps) with some redundancy. Personally, I would just do the frustum tests since the implementation time could be better spent optimizing something else. ;-)

This topic is closed to new replies.

Advertisement