Hardware queries vs. hardware rendering
Author
Hi,
for several reasons, I need to compute the occlusion of the sunlight in the scene, e.g. to render a lens flare effect. I have two options:
1) Use a hardware query and let the GPU count the number of pixels rendered of a 3d-model at the position of the light source.
2) Render the scene from the camera's position to an 1x1 pixel render target (depth-map or something) and analyze if objects are in front of the light source.
Which approach would you prefer and what is faster, a hardware query or rendering to a 1x1 pixel render target?
Thanks,
Christian
A single software transformation is bound to be far faster than any method involving the GPU. Is there a special reason you must perform this in one of these two methods?
If done on the CPU, all it would take is one call to D3DXVec3Transform...
Hope this helps.
If done on the CPU, all it would take is one call to D3DXVec3Transform...
Hope this helps.
Author
I need to know how much the sunlight is occluded by other objects in the scene. I don't know any technique to achieve this at satisfying frame rates using the CPU. If you know any, please let me know.
One of the Gpu Gems books has a neat way of doing this in hardware, but without occulsion queries. Basically it goes:
1. Render white image of sun + blackened surrounding geometry to a small (16x16) texture.
2. Downsample this texture into a 1x1 texture (can be done on the GPU with GL_POINTS and blending)
3. Use this 1x1 texture to modulate the lens flare via multitexturing.
This is basically doing an (speciallised) occulsion query which returns a greyscale texture for the percentage coverage in the initial occulsion texture. Depending on your scene however it may be faster to just cast a few rays towards the sun and calculate collisions on the CPU. However that won't get you proper results for alpha masked geometry (ie. trees).
1. Render white image of sun + blackened surrounding geometry to a small (16x16) texture.
2. Downsample this texture into a 1x1 texture (can be done on the GPU with GL_POINTS and blending)
3. Use this 1x1 texture to modulate the lens flare via multitexturing.
This is basically doing an (speciallised) occulsion query which returns a greyscale texture for the percentage coverage in the initial occulsion texture. Depending on your scene however it may be faster to just cast a few rays towards the sun and calculate collisions on the CPU. However that won't get you proper results for alpha masked geometry (ie. trees).
Sorry about my post, I've been out of it for a while.
I was thinking culling for some reason, and not occlusion.
I was thinking culling for some reason, and not occlusion.
Quote:Original post by OrangyTang
One of the Gpu Gems books has a neat way of doing this in hardware, but without occulsion queries. Basically it goes:
1. Render white image of sun + blackened surrounding geometry to a small (16x16) texture.
2. Downsample this texture into a 1x1 texture (can be done on the GPU with GL_POINTS and blending)
3. Use this 1x1 texture to modulate the lens flare via multitexturing.
Someone actually tried this out? Although this is good as a fall-back path, it looks more heavywheight than using occlusion queries. Is it meant as a performance winner or a legacy path?
I'd put money on a down-sampling approach being an order of magnitude faster than occlusion queries.
If only for the simple case that down-sampling will give you an immediate answer whereas occlusion queries can take several frames to return (worst case is you slaughter your frame rate by busy-waiting on the result).
For the down-sampling technique you can disable any/every effect such that it only costs you geometry transform. If you're clever you can probably use a scissor rect and/or write-masks to further reduce the amount of per-pixel work.
hth
Jack
If only for the simple case that down-sampling will give you an immediate answer whereas occlusion queries can take several frames to return (worst case is you slaughter your frame rate by busy-waiting on the result).
For the down-sampling technique you can disable any/every effect such that it only costs you geometry transform. If you're clever you can probably use a scissor rect and/or write-masks to further reduce the amount of per-pixel work.
hth
Jack
i used occlusion queries for my lens flare, and preformance tested the crap out of it. I ended up slaving the query to a max of like 15fps (the minimum I can get away with and still have good results), and it doesn't dent the framerate at all.
-programmer_tom
-programmer_tom
Quote:Original post by programmer_tom
i used occlusion queries for my lens flare, and preformance tested the crap out of it. I ended up slaving the query to a max of like 15fps (the minimum I can get away with and still have good results), and it doesn't dent the framerate at all.
Yea, I think this is a very good solution. Lens flares (and similar uses for occlusion queries) don't exactly need to be perfect, so it's okay that they lag behind a little bit. However, for other things like occlusion culling, queries can become quite painful to use - but that's why we have predicated rendering in D3D10 [wink]
Quote:Original post by KrohmQuote:Original post by OrangyTang
One of the Gpu Gems books has a neat way of doing this in hardware, but without occulsion queries. Basically it goes:
1. Render white image of sun + blackened surrounding geometry to a small (16x16) texture.
2. Downsample this texture into a 1x1 texture (can be done on the GPU with GL_POINTS and blending)
3. Use this 1x1 texture to modulate the lens flare via multitexturing.
Someone actually tried this out? Although this is good as a fall-back path, it looks more heavywheight than using occlusion queries. Is it meant as a performance winner or a legacy path?
I'd expect it to be faster myself - unlike queries you're never reading anything back from GPU->CPU, as everything stays on the GPU. You never have to stall for the result either so the whole thing pipelines much nicer. And as Jack mentioned the actual black and white rendering can be very minimal - no shaders or textures needed, and you could probably cull most of your geometry too.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
