I love this topic! It's like Christmas every day here!

@ far327: Not for me, I've spent something like 15 hours in the last 24 doing something related to cloud stuff and gotten precisely nowhere.

@ Anyone in the know: I have (yet another) question:

EyeForward - what basis is this in? World, view or screen, or what?

I think I'm stuck with the projection business. Here's my current code for getting a shadow map thing: (relevant bits only)

float4x4 m44world; //Transforms object space to world space.float4x4 m44view; //Transforms world space to view space.float4x4 m44proj; //Transforms view space to screen space.texture CloudTexture < string filename="sky\\cloudscloudy.dds"; >;float3 greyscale = float3(0.3,0.59,0.11);static const float nearZ = m44proj._43 / m44proj._33;static const float farZ = (m44proj._33 * nearZ) / (m44proj._33 - 1.0f);static const float CoordOffset = sin(f4Time.x/3600)*5;static const float4x4 m44worldviewproj = m44world * (m44view * m44proj);static const float4x4 m44invworldviewproj = pow(m44worldviewproj,-1);	//Depth calculations.	float depth = tex2D(DepthSampler, IN.UVCoord).x;	depth = pow(abs(depth), 0.05f);	depth = (2.0f * nearZ) / (nearZ + farZ - depth * (farZ - nearZ));	//Converting a point in screen space to world space.	// Coord is the viewport position at this pixel in the range -1 to 1.  	float4 Coord = float4(IN.UVCoord.x * 2 - 1, (1 - IN.UVCoord.y) * 2 - 1,depth,1);	Coord = mul(Coord,m44invworldviewproj);	Coord = Coord/Coord.w;		float4 tex = tex2Dproj(TextureSampler, Coord);	tex.rgb = dot(greyscale,tex.rgb) / 3;	if (tex.r < LumCutoff || depth == 1)		tex.rgb = 0;    return tex;

If I comment out the transformations to Coord, I get http://i617.photobucket.com/albums/tt255/WrinklyNinja1/Oblivion%20Bugs/Oblivion2010-02-0621-14-59-58.jpg. If I leave them in, I get http://i617.photobucket.com/albums/tt255/WrinklyNinja1/Oblivion%20Bugs/Oblivion2010-02-0621-13-41-82.jpg. What am I doing wrong? Anyone know?

Can't be set through the shader. The compile call made in the plugin's code must be changed.


I think the view vector should be in view space. Correct me if I'm wrong though.

Would you be dividing your world space coords (H) by .w one too many times ? The tex2Dproj intrinsic should do that for you. Apologies if this sounds stupid - I'm yet to dabble with texture projection.

Nope. If I comment out that line it still comes up the same. It's to do with the transformation, that's where it's going wrong, but I just don't know what is going wrong. And it didn't sound stupid to me, anything's worth a shot.

I'll keep mucking around, hopefully I'll strike gold eventually.

Thanks Marshmallow. I'll check those values out. Is that all that v3 changed, tweaking some of the values in the .ini to decrease brightness/create a more realistic look, or were there performance/quality improvements as well?

So in theory, correct me if i'm wrong, you could potentially make v2 Godrays look the same as v3 by tweaking some values in the .ini as you have mentioned above and come out with the same end product?



The shader is very cool looking, but, is there a way to use the edgeAA and not get the black outlines with it? I'm not sure if the black borders (reminds me of the look of Borderlands,) is what edgeAA does or not. All I know of EdgeAA is what I have seen of it in Crysis, and what I have noticed there is that it blurs the edges to make it appear more smooth. I did not notice the black borders in Crysis EdgeAA that I see with the edge detection shader here, is there a way to maybe keep the EdgeAA and get rid of the black outlines?

If that even makes sense heh :shifty: , I don't know the technical details about it. Thanks

The cel shader and edgeAA are mutually exclusive. Just set flgEdgeAA to 1 and flgEdgeMask to 0 - That should enable edgeAA and disable the black borders.

Re-post of the screenshots : http://s659.photobucket.com/albums/uu320/shademe/shader%20stuff/?action=view¤t=enb2010_1_17_11_5_32.jpg | http://s659.photobucket.com/albums/uu320/shademe/shader%20stuff/?action=view¤t=enb2010_1_17_11_5_40.jpg | http://s659.photobucket.com/albums/uu320/shademe/shader%20stuff/?action=view¤t=enb2010_1_17_11_6_28.jpg | http://s659.photobucket.com/albums/uu320/shademe/shader%20stuff/?action=view¤t=enb2010_1_17_11_6_37.jpg

You will.

I was working on the same thing too, but for Morrowind.
http://i51.photobucket.com/albums/f386/vtastek/morrowind/Morrowind2010/cloud%20shadows/cloudtest.gif

I don't know about the projections and such, so I don't know if I can help you. But I have a working code. Blending is the hardest part for me. But I think blending is nice now. The real problem is now something I put in the code to fade it as it goes further from camera. Funny thing is, it works opposite way. Close stuff is always in full shadow, and far away is properly lit-shadowed. And I have no idea how to reverse this(I can't remove it either, what should I put instead?). I'm multiplying it with distance(eye to world). I guess it should be x/distance where x is the max distance which I don't know.

Some math help?

@Jamrock990
Version 3 of godrays is for "HDR on" Oblivion. The new effect is less powerful, now it looks like sunshafts instead of sunglare. But it is only simple tweaks to the same shader. I will test and made separate shaders for Bloom version, HDR version and no Bloom-HDR version as well as power-subtle ones(6 shaders total). Which case fits you best?

I think you're right, and I have a proof: in the Godrays shader:

static const float3 sd = -f4SunDir.xyz;static const float d=dot(f3EyeForward,sd);static const float3 sunview_v=mul(sd/d,m44view);

If I've got it right, m44view is the transformation matrix from the world basis to the view basis. The dot product is an specific case of the inner product for Euclidean space. The inner product operates within the inner product space, which is a vector space, which can have a number of linearly independent spanning sets that are its bases from which vectors can be described that are specific to that vector space. If you've got two different bases, these could be part of the same vector space, but they wouldn't be linearly independent, as this would mean that they themselves are a basis, which contradicts the definition of a basis, so since they're linearly dependent. Since they're linearly dependent, they aren't orthonormal, which means they can't act as the axes in a Euclidean space, and so they can't be used as the bases for two vectors in a dot product. Alternatively, they could be linearly independent, in which case they would be in different vector spaces, and so the vectors using these bases wouldn't even be able to be used in the same inner product.

Plugging the code into that, it means that the SunDir and EyeForward vectors must be in the same basis, as they are dot-producted. Therefore since it's explicitly stated in Scanti's readme for DepthTest that the SunDir vector is in the camera (view) space, so must the EyeForward vector.

This actually started off as a disproof, but then I realised I'd read the readme wrong. :facepalm: So there you go.

@ vtastek: Could I possibly see the code for that shader?

If I'm not showing it, it is because I write the ugliest code in the world.

static const float2 invtexproj = 2 * float2( 1 , - rcpres.x / rcpres.y ) * tan(radians(fov * 0.5));

float3 eyevec = float3(mview[0][2],mview[1][2],mview[2][2]);eyevec += invtexproj.x * (Tex.x-0.5) * float3(mview[0][0],mview[1][0],mview[2][0]);eyevec += invtexproj.y * (Tex.y-0.5) * float3(mview[0][1],mview[1][1],mview[2][1]);float3 xpos = eyepos + depth * eyevec;float sunraypath = (xpos.z/sunvec.z);float gdist = length(xpos.xyz - eyepos.xyz);float shadows = tex2D(s3, (xpos - sunvec * sunraypath ).xy / 100000).b * gdist * saturate(exp(gdist*400)) * cauststr / 50;

This is actually meant for underwater caustics.

PS. I haven't figured scrolling into it, suggestions? But it changes according to sun angle and opacity.

Here is the blend code, very tricky stuff:

float4 source = tex2D(s1, tex);float4 blend = tex2D(s2, tex);blend = 1- blend;float4 final = source * blend;final = (1-blend) * source + final * 0.3;return final;

This should give some opacity. But it may darken the image a little.

Thanks.
I've confirmed that it is indeed the function using all the time. That function is being called 5 times per frame during normal gameplay in my test case, with only one call per frame of those taking any real time. The significant one is called by ShadowSceneNode during some hierarchical work on the scene graph managed by an NiCullingProcess, and accounts for about about 14 milliseconds of each frame in my test case, occasionally spiking upward to much higher values during unusual circumstances.

update:
BSShaderAccumulator::vtable_entry_0x14 appears to be spending much of its time on:
calls to 7F8DB0 - maybe 30% of its time
calls to 7ACF40 - maybe 25% of its time, called from multiple places, multiple times per frame
calls to 7F9410 - maybe 5% of its time
calls to 7ABAC0 - maybe 3% of its time

So, it looks like this is where the trail finally forks. I've been tracing where Oblivion spends its time through quite a few layers of calls so far, and at each previous one (except maybe the very top) most of the time turned out to be concentrated on to a single call.

I've been working on two different projection functions, and I'm not sure which is right (or at least most right). Here they are:

//This works, but is relative to player (view space), but the origin is not at screen centre.float4 RotatingCloudShadow(VSOUT IN) : COLOR0{    //Depth calculations.    float depth = tex2D(DepthSampler, IN.UVCoord).x;    depth = pow(abs(depth), 0.05f);    depth = (2.0f * nearZ) / (nearZ + farZ - depth * (farZ - nearZ));        // Coord is the viewport position at this pixel in the range -1 to 1.      float3 Coord = float3(IN.UVCoord.x * 2 - 1, (1 - IN.UVCoord.y) * 2 - 1,depth);    Coord = Coord*Coord.z;        float4 tex = tex2D(TextureSampler, Coord.xy + CoordOffset);    tex.rgb = dot(greyscale,tex.rgb) / 3;    if (tex.r < LumCutoff || depth == 1)        tex.rgb = 0;    return tex;}//In view space.float4 TestShadow(VSOUT IN) : COLOR0{    //Depth calculations.    float depth = tex2D(DepthSampler, IN.UVCoord).x;    depth = pow(abs(depth), 0.05f);    depth = (2.0f * nearZ) / (nearZ + farZ - depth * (farZ - nearZ));        //SSCoord is the position vector of the pixel in screen space.     float3 SSCoord = float3(IN.UVCoord.x * 2 - 1, (1 - IN.UVCoord.y) * 2 - 1,0);    //DepthCoord is the position vector of the pixel's depth from the pixel.    float3 DepthCoord = float3(0,0,depth);    //r is the position vector of the point in view space. Using trig:    float3 r = sqrt( pow(SSCoord,2) + pow(DepthCoord,2) );    r = r*r.z;    float4 tex = tex2D(TextureSampler, r.xy + CoordOffset);    tex.rgb = dot(greyscale,tex.rgb) / 3;    if (tex.r < LumCutoff || depth == 1)        tex.rgb = 0;    return tex;}

The first function doesn't make much sense to me, and the second is the result of me drawing out a 'screen' and the vectors of everything. That results in the origin for the texture being the centre of the screen, whereas the first method gives an origin somewhere else (top left, I think). Which is the correct method, and how do I then transform this into world space, as I assume it's in view space as it is, given that it's a 3D vector and the transformation matrices are all 4x4?

EDIT: A http://www.youtube.com/watch?v=4TbZvB2I89E of the first function being used to get the shadows, before being blended to the original frame. I'll get a video up for the second method too.

And the second function http://www.youtube.com/watch?v=8ACC8no2HYQ.

I`m amazed and impressed by your learning curve wrinklyninja, it has only been a few days since you decided to pick up this project and it looks like you already nailed it :foodndrink:
Thanks for the latest video :icecream:

It's been a few days since I got anywhere with it. And my learning curve ain't that great, it's just that I've spent most of the last couple of days on it, and a fair bit of time since Wednesday, which is when I started I think. It's like shooting into the dark - I don't really know what I'm doing in context, and I'm lucky if I hit anything. It's the shotgun approach to modding.

If your stuck on something, maybe post a few questions on this forum:

- http://www.gamedev.net/community/forums/

Maybe the answers you are looking for can be found on this site:

- http://www.gamerendering.com/

Looks like I have a lot of reading ahead of me...

I might just leave it till later.

So given that I can't do that, I'm better off, until the plugin is updated, changing the half to float, yes? I'm betting this isn't as simple as changing every instance of the word half, to the word float?

Never mind, what I sad was not correct after some more thinking about it.

I forgot that I posted this a while back in a other OGE thread:

- http://www.youtube.com/watch?v=QoFSY4s46Yw

Found some articles (not sure if it has 100% relevant info):

- http://nis-lab.is.s.u-tokyo.ac.jp/~nis/abs_sig.html#sig93 "A Simple, Efficient Method for Realistic Animation of Clouds"
http://nis-ei.eng.hokudai.ac.jp/~doba/anime/sig00_cloud.mpg

- http://www.gamedev.net/reference/articles/article2093.asp

Much info on clouds:

- http://www.vterrain.org/Atmosphere/Clouds/

Yes, and it is actually that simple. Though you'll have to make sure you change every variable declaration containing half in the type to float, so the following should change:
half -> float
half2 -> float2
half3 -> float3
half4 -> float4
not sure if this exists, but if it does: half4x4 -> float4x4

@ strupekutter: The problem is that I'm not doing a proper job of the whole cloud business, because I can't. I'm just using a random sky texture, and simplifying it into a greyscale image where black is no shadow and grey is shadow, and then projecting that onto the world.

I can't do it properly because I can't access the real sky textures, and I've been told before that raycasting or raytracing from the sun position is not really an option for shadows, so I can't do that to get real textures projected onto the ground in world space. In any case, I'm not familiar with ray stuff really, so it's not a problem in this case.

My problem is currently with the transformation from (what I think is) view space, where everything is relative to the camera position, to world space, where everything is relative to an origin in the world, and so is fixed from the player's perspective. At the moment, the cloud textures I'm projecting rotate with the player, and follow the centre of the screen, where I want them to be fixed at a point in the world independent of player movement, much like you don't see houses rotate and move when you turn around.

However, whenever I try a transformation, the projection breaks, giving me a world covered in shadow. Once I get an answer as to which of my two above functions are correct, then I can go on to worrying about that. First I've got to see if my view space coordinates are right.

Thanks shademe! Exactly what I was looking for, I can see the differences in the shots too. Looks great.



I use HDR in the game options (no bloom.) It's just when I compared the two versions on my various save games. I saw numerous shafts/glare on v2. When I loaded up v3 I saw nothing but the 2d sun and a glimpse of a sun shaft. I have no experience in shading or anything that you guys are doing here, but, I love the results.

I could do well with v2 Godrays w/ some of the tweaks mentioned i'm sure. But, in my opinion the best looking would be something in between v2 and v3. v3 seemed almost non-existent to me (I read it was a bit more time of day sensitive, so maybe my save games weren't reflecting that,) and v2 seemed a little too bright only during certain times of the day. Otherwise I loved it, and I have yet to try out the tweaks mentioned but I will have some time after the Superbowl tonight. Go Saints!

IMHO, the v2 Godrays is more spectacular so far from what I have seen, albeit a bit too bright at certain times. I had a save game right as the sun was coming up, and on v2 it was beatiful, you had the sun glare as it should be, not too extreme and also the sunshafts going around my weapon. It looked great. Then on v3 there was no glare, and I saw a remnant of a shaft coming my way but it was almost unnoticeable from not having any Godrays at all.

Just trying to throw in an example, sorry if it sounds harsh or anything, can't say again how much I love this stuff. Just my opinion on how I think it could be made better visual wise, I can't translate that into code like you guys but I can try to help with getting it to look great . Maybe you agree with me v3 was a little too subtle and v2 was a little much?

-J

EDIT: I noticed in v3 you added these two values.

float morningshaft = 0.22;
float eveningshaft = 0.22;

What do these do exactly if you don't mind? Do they affect the amount/intensity of the sunshafts in morning/evening?

Time for yet another code dump. I've chosen on a coordinate system, thanks to a helpful set of slides that showed me how to do it properly. Here's the shader file in full:

//Cloud Shadow Shader by WrinklyNinja - trying to learn how to do stuff.//TWEAKABLE VARIABLES.float ShadowIntensity = 0.25;//Controls how dark the cloud shadows are.float LumCutoff = 0.27;//Controls how bright a cloud has to be to cast a shadow.float CloudSpeed = 7200;//Controls the speed of cloud movement. Higher is slower.float FOV = 75;//Your FOV, obviously.//END OF TWEAKABLE VARIABLES.float4x4 m44world; //Transforms object space to world space.float4x4 m44view; //Transforms world space to view space.float4x4 m44proj; //Transforms view space to screen space.float3 f3EyeForward; //Forward unit vector of camera.float2 rcpres;float4 f4Time;texture Depth;texture thisframe;texture lastpass;float t =  tan(radians(FOV * 0.5));static const float aspect = rcpres.x/rcpres.y;static const float CoordOffset = sin(f4Time.x/3600)*3;texture CloudTexture < string filename="sky\\cloudscloudy.dds"; >;float3 greyscale = float3(0.3,0.59,0.11);static const float nearZ = m44proj._43 / m44proj._33;static const float farZ = (m44proj._33 * nearZ) / (m44proj._33 - 1.0f);sampler FrameSampler = sampler_state{    texture = ;    AddressU = CLAMP;    AddressV = CLAMP;    MINFILTER = POINT;    MAGFILTER = POINT;};sampler PassSampler = sampler_state{    texture = ;    AddressU = CLAMP;    AddressV = CLAMP;    MINFILTER = POINT;    MAGFILTER = POINT;};sampler DepthSampler = sampler_state{    texture = ;    AddressU = CLAMP;    AddressV = CLAMP;    MINFILTER = POINT;    MAGFILTER = POINT;};sampler TextureSampler = sampler_state{    texture = ;    AddressU = WRAP;    AddressV = WRAP;    MINFILTER = POINT;    MAGFILTER = POINT;};struct VSOUT{    float4 vertPos : POSITION;    float4 UVCoord : TEXCOORD0;};float4 ProjectShadow(VSOUT IN) : COLOR0{        //Depth calculations.    float depth = tex2D(DepthSampler, IN.UVCoord).x;    depth = pow(abs(depth), 0.05f);    depth = (2.0f * nearZ) / (nearZ + farZ - depth * (farZ - nearZ));        float4x4 m44invworld = pow(m44world,-1);    float4x4 m44invview = pow(m44view,-1);    float4x4 m44invproj = pow(m44proj,-1);        //Normalise screen space coordinates, and add depth.    float3 NormCoord = float3(IN.UVCoord.x * 2 - 1,1 - IN.UVCoord.y * 2,1/t);    //Transform to view space.    NormCoord.x *= aspect;    //Transform to world space.    NormCoord = mul(m44invview,NormCoord);    //Transform to model space.    NormCoord = mul(m44invworld,NormCoord);        //Transform camera pos. Starts off in view space.    float3 EyeForward = f3EyeForward;    //Transform to world space.    EyeForward = mul(m44invview,EyeForward);    //Into model space.    EyeForward = mul(m44invworld,f3EyeForward);        NormCoord = EyeForward + depth*NormCoord;    NormCoord *= NormCoord.z;    float4 tex = tex2D(TextureSampler, NormCoord.xy - f4Time.x/CloudSpeed);    tex.rgb = dot(greyscale,tex.rgb) / 3;    if (tex.r < LumCutoff || depth == 1)        tex.rgb = 0;    return tex;}float4 Combine(VSOUT IN) : COLOR0{    float4 frame = tex2D(FrameSampler, IN.UVCoord);    float4 shadowpass = tex2D(PassSampler, IN.UVCoord);    frame.rgb -= shadowpass.rgb * ShadowIntensity;    return frame;}technique t0 {    pass p0    {         PixelShader = compile ps_2_0 ProjectShadow();    }        pass p1    {        PixelShader = compile ps_2_0 Combine();    }}

And accompanying http://www.youtube.com/watch?v=5TgqYMGVuSM. World and model space projection is messed up, but if I comment out the transformations into them, and project in view space, you get that video.

Is there any way of getting the clouds to stay fixed, so they don't move with the camera, without world space stuff, because I don't think I'm ever going to get that to work?

EDIT: Nearly time for new thread, I'll make one now before I go to bed.

I have a miscellaneous question... I remember in Morrowind, when using MGE's shaders, the whole screen was affected, including the UI... but the OBGE shaders have no such effect... why is this? Or am I wrong about something?

OBGE and co. have an option to affect the UI, but for stuff like this it isn't switched on, Timeslip managed to get two different ways of applying the shader, one affecting, the other not.

EDIT:

http://www.gamesas.com/bgsforums/index.php?showtopic=1074452