Sign in to follow this  
MrSparkle

Hardware queries vs. hardware rendering

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Sorry about my post, I've been out of it for a while.

I was thinking culling for some reason, and not occlusion.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Quote:
Original post by Krohm
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 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.

Share this post


Link to post
Share on other sites
Quote:
Original post by OrangyTang
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.



Maybe you could also use hardware antialiasing to render a 1x1 pixel texture by supersampling instead of downsampling it in another stage... What do you think?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this