God Rays + Alpha ( is it possible )?

Started by
12 comments, last by riuthamus 11 years, 1 month ago

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?

Advertisement

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.

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

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.

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.

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).

Thank you for this help, I will have Goss try to add that in later today when he gets up.

As for the FPS, thank you for explaining it as I now have a better understanding of what you mean.

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.

New game in progress: Project SeedWorld

My development blog: Electronic Meteor

I saw that tutorial.... hm.. okay thanks. This is great information and I appreciate it.

Not sure where goss took these links but this is what we have so far:

godrays.1.jpg

This is with 0 optimization and more or less just a test to see if it works correctly.

This topic is closed to new replies.

Advertisement