Sign in to follow this  
riuthamus

God Rays + Alpha ( is it possible )?

Recommended Posts

riuthamus    8361

http://http.developer.nvidia.com/GPUGems3/gpugems3_ch13.html

 

Would it be possible to get the above effect while using alphas from a model+texture? I ask because our cloud system works like so:

 

gallery_1_8_4831.png

 

We create a cylinder object that rotates in a selected direction ( slowly ).

 

gallery_1_8_70580.png

To get the desired cloud effect we apply a texture to it using SRGB and Alpha layer to remove the areas we do not want to cover by clouds.

 

gallery_1_8_113222.png

Our desire is to use the dome ( which encases the cylinder and the world ) where we apply the sun and generate the GPU gems lighting ( god rays ) from the clouds that are showing. I guess the question is, is there any way to create the same desired effect by using the Cloud system we have in place?

Share this post


Link to post
Share on other sites
Lightness1024    933

I tried that in your almost exact same situation, but it was a failure (only 2 days spent on it though).

For two reasons:

- difficult to find the correct smearing direction for each pixel, though I'm sure there is a way had I put a bit of effort

- serious issue with desaturation over the whole sky. to have "god rays" somehow you need to "add haze" and that is terrible for the result. your image becomes whiter and desaturated overall. I tried various operators; like multiplication, or mix of mul and add, none were good. anyway, consider using somekind of pow() function to add godrays only near the solid angle that subtends the sun. Because physically, in-scattering mainly happens on light paths around this angle anyway.

- impossible to use with tiled rendering.

 

I will add one reason that could be a bother to your particular case, you have animated clouds so you will need to re-run this. but it is damn costly (100 samplings per pixel) so I suggest you use the fact that your rotation is very slow to smear progressively (in multiple passes over multiple frames).

 

But again, if I were you, I would still attempt this method, it seemed the easiest and best fit for cool results in a simple fasion for this case. I'm just saying it will require serious engineering. Kenny Mitchell gives us a theory, in practice it's always another story.

Share this post


Link to post
Share on other sites
riuthamus    8361

Well, the inital test proved.... some what interesting. We used only the GPU gem tutorial and we got it working....

 

gallery_1_8_122071.jpg

 

But the cost of this was damn near 250 fps ( normally i get 350 or higher ). This would be a serious blowback for any rig since my machine is pretty beefy. That said, we have not optimized nor do we know if it is all correct. We do have some ideas on how we could get away with such things but the biggest part is that we got it working. I will keep you guys posted as we travel down this road. Any further suggestions or hints let us know! Thanks btw

Share this post


Link to post
Share on other sites
kalle_h    2464
Post full shader code if you want help with it. Also fps is not measurement of cost because its all relative. Use milli seconds instead. So the cost of your implementation is 1/100fps - 1/350fps = 0.00714285715s or 7.14ms.

Share this post


Link to post
Share on other sites
riuthamus    8361

Shader code is the exact same as that I linked in the first post. We mimicked the GPU gems. Not sure what you mean by FPS is not a measurement of cost. If i have 50 shaders and my FPS goes to 10 because of those shaders It is very much cost related. This is not a flight sim where 5 or 10 FPS will do so it is very much a relation to cost. You may have some valid point related to code as to how FPS = MS but in the world of the common person ( me ) FPS is the measurement of cost because it defines whether something is worth the effort or not to implement.

Share this post


Link to post
Share on other sites
kalle_h    2464

Shader code is the exact same as that I linked in the first post. We mimicked the GPU gems. Not sure what you mean by FPS is not a measurement of cost. If i have 50 shaders and my FPS goes to 10 because of those shaders It is very much cost related. This is not a flight sim where 5 or 10 FPS will do so it is very much a relation to cost. You may have some valid point related to code as to how FPS = MS but in the world of the common person ( me ) FPS is the measurement of cost because it defines whether something is worth the effort or not to implement.

One rather obliviou optimization is move Weight multiply out of the loop and only does it once after loop.
sample *= illuminationDecay * Weight <-- This one!

Next but not that big optimization is move direction calculation to vertex shader.

half2 deltaTexCoord = (texCoord - ScreenLightPos.xy);
// Divide by number of samples and scale by control factor.
deltaTexCoord *= 1.0f / NUM_SAMPLES * Density

This all can be calculated at vertex shader and interpolated to pixel shader.

But I bet these modifications does not give any benefits and you are texel fetch bound. But all hope is not lost. This presentation walks through quite fast implementation of God rays. It even run at iPad2
http://www.unrealengine.com/files/downloads/Smedberg_Niklas_Bringing_AAA_Graphics.pdf


About fps. If someone only say that this effect cost 100fps you cannot say how much that effect use rendering time that why one should always use absolute time. If game run 1000fps then losing 50fps is not much(only 0.05ms) but if game run only 100fps then losing 50fps is rather big deal(10ms).

Share this post


Link to post
Share on other sites
CC Ricers    1491

Here's a cheap way to get God rays in screen-space. It's an adaptation of radial blur with the center pointing to the light source. Here's what looks like.


It works like this:

- Find the light's position in screen space

- Compute the intensity of the rays using the direction the camera is facing in relation to the light

- Create a low-res mask texture to only allow the sky to contribute to the blur (depth buffer is good for this)

- Apply the mask to a downsampled render target of your scene, so it only keeps sky pixels

- Blur the pixels in the direction of pixel position to light's screen space position (most costly step)

- Add the blurred texture times intensity to the original scene render

 

Optionally you can have a threshold for luminance on the blur.

Share this post


Link to post
Share on other sites
SiddharthBhat    358

nice link. Also, they neglected to mention that they also added a lens flare effect 

 

Aren't 5 passes kind of expensive? I've found ping-ponging between FBO's to have a MAJOR impact on performance.

 

wouldn't a simple radial blur act as a cheap approximation to the 2nd pass + 3rd pass combined? I'm not really sure why it's implemented in two separate passes,

Share this post


Link to post
Share on other sites
kalle_h    2464

nice link. Also, they neglected to mention that they also added a lens flare effect 
 
Aren't 5 passes kind of expensive? I've found ping-ponging between FBO's to have a MAJOR impact on performance.
 
wouldn't a simple radial blur act as a cheap approximation to the 2nd pass + 3rd pass combined? I'm not really sure why it's implemented in two separate passes,

That 5th pass technique is optimized carefully to certain hardware. PowerVR hardware does not like texture fetches where texture coordinate is calculated at pixel shader. If you have simple radial blur without using any dependant texture reads could you please share it?

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