Unique way of rendering clouds...

Published May 14, 2010
Advertisement
Hey guys, I was working on my cloud system earlier today and decided to rollback to my old billboarded solution ... this is temporary until I get some more time. I have to put all my focus on the gameplay and more important parts of the visuals/engine so I can finally release "Armored Warfare".

Here is how the clouds are looking, I sort of came up with this hack/cheat of improving standard billboarded clouds in the last few hours...
NEW...


I didn't take any screenshots of the old billboarded clouds, so I'm going to reference this one from my online gangster game [ Urban Empires ]
OLD...this screenshot is from 2007.


My old clouds looked 'alright', but I wasn't satifisied because there was really no form of light scattering, or 'silver lining' on the clouds. I was thinking I could possibly fake it using several channels of the billboarded cloud texture.

This is an example of one of the 4 clouds I created. The way the channels are generated is sort of complicated, if anybody is interested I'll type it up. The most important part of it all is channel G, which is multiplied by the dot(sun,cloud_normal) so it produces a glow/lining on the clouds when the sun is behind the cloud.


Here is the pixel shader code I wrote to render the clouds, very friendly indeed...
//CloudAtlasSampler = texture contatining clouds//	Alpha channel = Cloud transparency//	Red channel = Blurred cloud center darkening value//	Green channel = Cloud lining/rim value//	Blue channel = unused / saved for future effects//Input.Lighting = normal vector of billboarded cloud//g_SunVector = Sun's worldspace vector//The "*0.75" "*0.9" are unique color scaling values for my game engine, to float4 CloudPixelShader( CloudVS_Output Input ) : COLOR{	  	float3 SunColor = float3(1,1,1);	float4 Texture = tex2D( CloudAtlasSampler, Input.TexCoord.xy );	float3 RimLighting = abs(dot(g_SunVector, -Input.Lighting))*Texture.ggg*SunColor;	return float4(((max(0.9,Texture.rrr)*0.75)+(0.5*RimLighting))*0.9,Texture.a);}


Some pics of the result ... not bad for the nearly non-existant FPS hit. Plus they are lit dynamically, and scroll around the world. This would be a good base to render some truely volumetric clouds over.





And here is a debug shot, to show how low poly and cheap the whole effect is, IMO it looks pretty good, though is obvioulsy not 100% realistic.



Until next time...

- Dan
0 likes 8 comments

Comments

Jason Z
That's a nice little effect. I would agree that the silver lining is what gives it a nice touch, and it looks like the performance would be smokin' fast. Nice work!
May 15, 2010 01:28 AM
Matias Goldberg
"Sun goes here" billboard LOL.
Makes me remember a flash parody that placed "HI-Res Kick-ass particle fx here" just out of laziness.

Interestingly I was having similar ideas about the cloud "scattering" I didn't have the time to put in practice yet.

Sorry I will insist (again), looks I always post replies in old threads, I'm just interested in knowing how do you cope with the 100km terrain (the 3 technical questions)

Keep up the lovely work!
Looking forward for a demo now ;)

Cheers
Dark Sylinc

PS: This will be the last time I bother with the question, this time I made sure I'm answering to a recent thread ;)


Edit: I see your blue channel is unused. I suggest to use it to colour it a bit. If you pay attention to the sky, clouds aren't grayscale, they have slight variations of grayish blue.
I also suggest to use the specular colour component of the sun in relation with the relative (faked) position of the cloud and the sun direction so that clouds with a high value in G channel closer to the sun get coloured by it's colour (which would be orange-reddish at dawn)
Also your Alpha and G channels from your texture could benefit from a "Spread noise" filter from GIMP
May 15, 2010 01:48 PM
dgreen02
Quote: Original post by Matias Goldberg
"Sun goes here" billboard LOL.
Makes me remember a flash parody that placed "HI-Res Kick-ass particle fx here" just out of laziness.

Interestingly I was having similar ideas about the cloud "scattering" I didn't have the time to put in practice yet.

Sorry I will insist (again), looks I always post replies in old threads, I'm just interested in knowing how do you cope with the 100km terrain (the 3 technical questions)

Keep up the lovely work!
Looking forward for a demo now ;)

Cheers
Dark Sylinc

PS: This will be the last time I bother with the question, this time I made sure I'm answering to a recent thread ;)


Edit: I see your blue channel is unused. I suggest to use it to colour it a bit. If you pay attention to the sky, clouds aren't grayscale, they have slight variations of grayish blue.
I also suggest to use the specular colour component of the sun in relation with the relative (faked) position of the cloud and the sun direction so that clouds with a high value in G channel closer to the sun get coloured by it's colour (which would be orange-reddish at dawn)
Also your Alpha and G channels from your texture could benefit from a "Spread noise" filter from GIMP


Hey, sorry for missing the questions, I'll answer them here....

As for the cloud Blue channel, I've got some ideas of scrolling noise I can add to them, also there are already many ideas I've had to improve this system in just the last day :-o I'll have an update on it all in a few days.

I've already created/completed the 1,000,000 tree rendering system the same day I did the above ^^^ cloud stuff - it's [grin][grin] to say the least.

Alrighty as for your other 3 questions
Quote: 1)The first screenshot after "100km x 100km terrain...it's huge", does it have full shading on it? How many textures are being applied?
2) How do you cope with floating point errors at 100km? Do you use doubles?
3) How do you create the terrain? Is it a heightmap texture? What resolution do you use? a 4096x4096 heightmap means 25m per pixel. That's not much detail. How do you overcome that? Or it doesn't really affect the looks?


1) Yes it has full shading on it, I'm running a few 'tricks' and spent many days tweaking the splatting and texturing methods, I'm only using 9 of 16 texture samplers now. There are two levels of detail on the terrain, the lowest level has very high resolution normal maps, etc. Once I get it even more polished I'll post some down-and-dirty screenshots. Overall it looks very good so far and I took special care to assure there was more than enough texture/normal map detail everywhere on the terrain. Plus I use detail textures as well.

2) I use a custom system to scale the near/far planes dynamically based on the camera's height off the ground, it removes all major shimmering/fighting artifacts. World size is 102,400 x 102,400 units. 1 unit = 1 meter.

3) Yes the terrains are heightmaps, size 2049x2049 ... it runs extremely fast I can render the terrain 4 times per frame ( scene, water reflection, shadow map, post-process texture ) no multiple render target usage, because I need full Multisample antialiasing on the scenes. If you've ever played a game like ARMA/Flashpoint the terrain is similarly detailed. I go one step further and add procedural noise and highly tessellate the near sections of the geomipmapped terrain. But that might not even be necessary especially with the 1,000,000 object foliage system I just added, you can hardly see the terrain lol.

Hope I could answer your questions!

- Dan
May 15, 2010 04:56 PM
Matias Goldberg
Thanks a lot!

Quote: Original post by dgreen02
As for the cloud Blue channel, I've got some ideas of scrolling noise I can add to them, also there are already many ideas I've had to improve this system in just the last day :-o I'll have an update on it all in a few days.

Yeah I understand you. Happens the same to me
Sometimes I wish I could multiply by 4 and try many ideas then go back to be just one again.

Thanks a lot for the answers. Just one thing:

Quote:
2) I use a custom system to scale the near/far planes dynamically based on the camera's height off the ground, it removes all major shimmering/fighting artifacts. World size is 102,400 x 102,400 units. 1 unit = 1 meter.

Actually, that's not what I was thinking of. Rendering is here, the easy part.
I meant how do you cope with the logic & physics side of it.
If your Unit::m_position has a value of, for example, (92685.898f, 76485.294f, 23654.076f), it's surprisingly low the accuracy you'll get. Updating the position with low values (i.e. high fixed framerate) could cause some flickering, not to mention inaccuracies with collision detections. Doubles shouldn't have problems.

Also, Havok starts complaining when the world is > 12km; and AFAIK it can't be solved without having access to the source code:
Quote:
HAVOK: .\BroadPhase\3AxisSweep\hkp3AxisSweep.cpp(939): [0xF034DE45] Warning : Your broadphase extents is bigger than 12k meters, this can lead to a performance penalty, try to reduce the broadphase size or use the 32 bit broadphase

How did workaround this problem? May be there's a way to quickly switch to 32-bit broadphase that I'm not aware of, or you just have the source code

Cheers!
Dark Sylinc
May 15, 2010 05:59 PM
dgreen02
I center the world at 0,0,0 so it ranges from -52000 to 52000 on xz axis, and 1000 to 10000 on the y-axis so the numbers you quoted woudnln't occur. I think I had to change my havok collision detection to 32-bit a while ago...IIRC it was necessary to get the old build working. Back in the old build of Armored Warfare ... I even got it working by just naively sending all 2+ million collision triangles to Havok and letting them sort it out.

I am still not re-implementing physics until I get certain other parts of the game world back together .... I have been thinking a lot about collision detection and Havok, basically I'm going to build a dynamic set of collision triangles around all physically active objects in the world. I will post more on this when I have results.

This is also why I'm leaving the door open for other physics solutions such as Bullet.

I don't understand why logic would be an issue in this situation, all of my values are well within floating-point range, and there seems to be more than enough precision ( I have written my own terrain ray-casting/collision detection, and early entity movement code to prototype things ).

I will keep you guys posted on it all.

- Dan

EDIT - Yes I do have 32-bit broadphase enabled, it doesn't require source code - it's very simple change, this should help you -
Quote:
//32-bit broadphase support
#include <Physics/internal/collide/broadphase/hkpBroadPhase.h>

//Enable 32-bit broadphase
hkpBroadPhase::Enable32BitBroadphase broadphaseHelper;
May 15, 2010 10:18 PM
Matias Goldberg
Swweeeettttt! I could kiss you (though you're a guy, so let's better not). You deserve cookie!

Thanks a lot.
My concerns about the precision is not about the floating point range (you clearly are when you're between -52k; 52k), but rather the lower digits (i.e. 49158.2357f vs 49158.2362f), or adding 0.5f * 1/60.0f (where 1/60.0f could be the framerate and 0.5 velocity) to 49158.2357f

Cheers
Dark Sylinc
May 16, 2010 10:38 AM
dgreen02
Quote: Original post by Matias Goldberg
Swweeeettttt! I could kiss you (though you're a guy, so let's better not). You deserve cookie!

Thanks a lot.
My concerns about the precision is not about the floating point range (you clearly are when you're between -52k; 52k), but rather the lower digits (i.e. 49158.2357f vs 49158.2362f), or adding 0.5f * 1/60.0f (where 1/60.0f could be the framerate and 0.5 velocity) to 49158.2357f

Cheers
Dark Sylinc


Yup, I've already got joystick support and a flying dropship among other things ... it seems to handle just fine @ 75hz to 100hz even at the boarder of the map. Hopefully there will not be any issues. :-o We'll see how it works when I move away from my own temporary physics code back to Havok ( or maybe Bullet, but I've already got 100% havok support ).

Also glad the 32-bit code snippet ^^^ could help.

- Dan
May 16, 2010 03:38 PM
Matias Goldberg
He always mentioned around 3 test computers, IIRC the fastest one had a GeForce 8800 GTX or GT
The CPUs were all Core 2 Duo, can't remember if he had a quad core

We could say it's "aging high end".
Let's remember graphic settings are configurable so it can adjust to slower machines.
May 22, 2010 11:22 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement