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:

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

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.

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?

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

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.

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

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?