Jump to content

  • Log In with Google      Sign In   
  • Create Account

Methods for drawing the sky


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
17 replies to this topic

#1 Norman Barrows   Crossbones+   -  Reputation: 2126

Like
0Likes
Like

Posted 13 February 2013 - 06:54 PM

I'm working on drawing the sky in an outdoor FPS/RPG type title. 

 

Needless to say, like everyone, i want it to look more real than reality itself, and take zero clock cycles to draw! <g>.

 

But seriously, i'm looking for a method or combo of methods that will yield beautiful sky texture like results, but be animated and particle based, driven by a weather simulation engine, AND be low overhead.

 

here's where i'm at right now:

For daytime, the screen is cleared to a uniform shade of blue based on time of day. the sun is alpha blended in. a skybox is used for night. the sun and skybox can be whipped into shape easily enough, its just tweaking textures and meshes. Clouds and sky color seem to be the real challenge.

 

for clouds, i'm currently using a system of 20 particles. each particle is an almost flat octahedron mesh. the texture is alpha tested with 2 clouds on a texture, and the texture repeated twice over the mesh, for a total of 4 clouds per mesh, and 80 clouds for all 20 particles. Clouds are at 3 different altitudes, and their altitude is sloped towards the horizon, so they are not drawn in 3 planes above the ground, but more like in 3 concentric shallow domes above the ground. This squeezes them into a far clip plane of 1000 while appearing to be further off. the effect is OK, but reminds me of road runner cartoons for some reason.  : P

 

I'm thinking i need to do a gradient from darker at the horizon to lighter straight up for the sky color, and alpha blend the clouds, but i'm concerned with possible performance issues. 

 

any suggestions for possible candidate techniques or approaches?

 

 


Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


Sponsor:

#2 tool_2046   Members   -  Reputation: 1061

Like
0Likes
Like

Posted 13 February 2013 - 07:35 PM

You can do much better than a simple gradient for the sky. Atmospheric scattering in real time has been around for over a decade. For cloud rendering, there are lots of approaches. Game Programming Gems 5 had a pretty decent article based on using a height field for clouds. There are particle based approaches as well. Yann L had some great posts of cloud rendering here many years ago. I've found vterraing.org to be a great resource for these kinds of things. Lots of papers on the subject.

EDIT: Having a hell of a time with the editor here! sad.png

Edited by tool_2046, 13 February 2013 - 07:40 PM.


#3 Lightness1024   Members   -  Reputation: 736

Like
0Likes
Like

Posted 14 February 2013 - 09:11 AM

Also there are libraries like SilverLining and Triton.

they are based on the old method from Dobashi et al. (dynamic simulation and rendering of clouds)

there is the classic mark harris, and above all there are the methods from Antoine Bouthors, like the 2008 paper Multiple scattering in clouds.

Also Lumion has impressive clouds (lumion free is downloadable to experience that).

there are many true volumetric methods that are making their way through recently.

there is a method for scattering using LPV that is pretty serious:

http://www.cse.chalmers.se/~uffe/multi_scatter.pdf

Also I'm pretty sure there is a future of voxel tracing for cloud rendering.

to make it simple you can also just skid some photos.

for the sky, well the shader is provided directly in the Neyret/Crassin paper so there is no blah blah possible on that.



#4 CC Ricers   Members   -  Reputation: 623

Like
0Likes
Like

Posted 14 February 2013 - 03:39 PM

How does atmospheric scattering work in a convincing way for flat worlds? I'm about to implement a sample of it, but it's in a basic setup- a square grid for the surface and a stationary sky dome, not a planetary sky sphere. It works and looks good enough close to the surface, but since the sky dome does not move in relation to the camera it starts to look odd the farther up you go.

 

I guess, as it is, this will have to do for now. I'm not setting out to do a full earth simulator but if it would be nice if the skydome looks like you can actually reach it, in high altitude settings.


My development blog: Electronic Meteor

#5 Norman Barrows   Crossbones+   -  Reputation: 2126

Like
0Likes
Like

Posted 15 February 2013 - 08:34 AM

I've found vterraing.org to be a great resource for these kinds of things.

 

Yeah, found that one yesterday, lots of good stuff there.

 

Also there are libraries like SilverLining

 

Took a look at that yesterday too. Probably too expensive.   : (

But that is the kind of thing i need.

 

Also I'm pretty sure there is a future of voxel tracing for cloud rendering.

 

yeah, voxels are point cloud data. raytraced voxels or point cloud data will probably be the ultimate evolution of how to draw clouds.

 

have you seen that team in Australia who has a point cloud rendering engine with insanely high resolution and unlimited scene complexity?

 

 

 

 

 

one important thing i forgot to mention:

the game is a fps title, not a flight sim, so the player can't fly through the clouds, just look up at them. So they don't need the full volumetric effect.

 

 

 

is there a popular solution commonly used ? or is everyone sort of doing whatever method(s) or using whatever library to draw clouds?


Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


#6 bwhiting   Members   -  Reputation: 753

Like
0Likes
Like

Posted 15 February 2013 - 02:24 PM

http://reset-game.net/?p=284

 

Might not be much help to you but... NICE!



#7 Hodgman   Moderators   -  Reputation: 30384

Like
0Likes
Like

Posted 15 February 2013 - 07:41 PM

have you seen that team in Australia who has a point cloud rendering engine with insanely high resolution and unlimited scene complexity?

The one that's been in development over for 14 years by a questionable man with a severe victim complex? Don't get your hopes up.



#8 Norman Barrows   Crossbones+   -  Reputation: 2126

Like
0Likes
Like

Posted 16 February 2013 - 10:06 AM

have you seen that team in Australia who has a point cloud rendering engine with insanely high resolution and unlimited scene complexity?

The one that's been in development over for 14 years by a questionable man with a severe victim complex? Don't get your hopes up.

 

 

Yep, that's the one.

 

This was a scientific data processing company that specialized in point cloud data from stuff like underground radar geological surveys, etc.   

 

apparently they came up with a search algo that allows one to quickly determine which points to draw. the resolution is insanely high since its based on scientific apps (something like 25 or 100 or more points per INCH), and they're drawing entire Aztec type CITIES in real time. Unfortunately being a scientific company, they don't seem to really know what to do with this and make it work for games. I suspect that ram requirements for scene data are high. also, its probably only good for static scenes. Last I heard, they spent a YEAR writing a tool that converts a poly model to a point cloud model that they can then search with their algo. 

 

Based on what i saw and read, it looked like it was yet another case of academia or science thinking they has something useful for games, when they have no clue about what games need.

 

what is it with people from other industries thinking they know how to do our jobs better than we do?


Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


#9 Lightness1024   Members   -  Reputation: 736

Like
0Likes
Like

Posted 16 February 2013 - 11:51 AM

well I have done real time clouds in my time as well. its not yet out in the product so its kind of a serious leak, i'm trying to take the dullest image i have and take off all the products giveaways so I can still kind-of post it here...

its working with fractal marching.

vivienclouds.jpg



#10 Norman Barrows   Crossbones+   -  Reputation: 2126

Like
0Likes
Like

Posted 17 February 2013 - 10:32 AM

well I have done real time clouds in my time as well. its not yet out in the product so its kind of a serious leak, i'm trying to take the dullest image i have and take off all the products giveaways so I can still kind-of post it here...
its working with fractal marching.

 

Very nice! I appreciate the extra effort you went to to show us that.

 

When i was looking over the resources at vterraing.org i noticed a lot of algos based on fractals.

 

Any idea what kind of drawing times your looking at?

 

Right now, i'm only using 20 particles and 20 drawcalls of 8 tri's each with no alphablend. I suspect I don't have a lot more clock cycles to spend on clouds.

 

I assume the clouds can move in real time based on wind speed and direction info from a weather engine, correct?

 

what about red sky at night? does your system do that as well?

 

so far it looks like atmospherics and maybe a fractal based cloud system may be the answer.


Edited by Norman Barrows, 17 February 2013 - 10:40 AM.

Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


#11 Lightness1024   Members   -  Reputation: 736

Like
1Likes
Like

Posted 19 February 2013 - 09:05 AM

Yes my clouds can move, in lower resolution, after any move is done, the high resolution bakes itself into an half cube (upper sky dome) using tiled rendering.

its too slow for pure real time, it would lower the system to around 1 or 2 FPS in full res full real time.

The biggest issue is the number of times the fractal needs to get evaulated per pixel. knowing the fractal is made by iterating reading a noise texture with UV coords that multiply exponentially (octaves). I calculated that at max quality one pixel = 1800 texture reads. Of course it only works so great because the texture is so small it can get in the cache. But I even suggest using registers (constant buffers) to pass an even smaller noise base, that could help I guess.

Though, in my technique the shader was so complex, on DX9 it was difficult to compile because I would exceed the max number of registers very often.

Because of the presence of loops, and dependence on variables outside the loops, creating arrays with size that multiplies with the nested loops...

Anyways, the night, sunset and dawn are handled with a mix of empirical tunings and the effects from the aerial perspective (rayleigh). The empirical stuff is mainly the intensity of the sun light, and the sky light that I use as a second source from the top. Normally you should evaluate the irradiance of the sky as a 3D function (encoded into spherical harmonics or as an lookupable envmap) but a single scalar is more than enough in the sky case because of its uniformity across the hemisphere.

The quality of the technique is that the light direction change really change the volume impression we get of the clouds. Though it is not using scattering formulas, its already slow enough :) instead it uses empirical formulas.

About the parameters, there are literally tens of them (~50), but I reduced it to 10 "master" parameters that drives the other ones with empirical ramps that I adjusted to be "cute". So the user can move the sun, time of day, or change the quantity of coverage, and it any combination it remains controlled and the best consensus. It took days to adjust.



#12 Norman Barrows   Crossbones+   -  Reputation: 2126

Like
0Likes
Like

Posted 20 February 2013 - 05:30 PM

Lightness1024:

 

Most impressive.

 

about how many man-hours of development time do you estimate have been spent on the system so far?

 

>> About the parameters, there are literally tens of them (~50), but I reduced it to 10 "master" parameters that drives the other ones with empirical ramps that I adjusted to be "cute". So the user can move the sun, time of day, or change the quantity of coverage, and it any combination it remains controlled and the best consensus. It took days to adjust.

 

Understandable. I had to write a small simulation routine that ran the weather engine for 300 game years to make sure it didn't go into terminal global warming or cooling. That and the world map generator were probably the hardest things to make in the game (well, avian AI has been a pain too). the weather engine required two weeks to balance - and its only like 2 screens of code! That weather engine will drive the clouds.

 

I've been able to glean quite a bit of info from your description: baking, constant limits, all those HLSL issues, etc. Stuff a good engineer ought to keep in mind / look out for when pursuing such a design. Most helpful. Thanks again. 


Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


#13 Lightness1024   Members   -  Reputation: 736

Like
0Likes
Like

Posted 21 February 2013 - 09:26 AM

In 2006 I wrote a little weather engine with a little state machine, and it was capable of interpolating between sets of uniforms that the artists could save as presets and presented as "weather condition" in the interface, then a randomizer would make a sequence with a probability function that was evaluated using a special "distance" function between the weather state. (that made that some condition were far from other and thus rarely chosen as following each other. like snowy would rarely come after bright clear)

It was an internship at Etranges Libellules. the 6 years non disclosure is expired so I can say all I want :)

here a picture:

shot2-soir.png

 

In terms of rendering it is super primitive, it has a perlin noise for the clouds applied on a single flat layer, and a smoothstep (hermite) would apply a contrast curve on the alpha of the cloud to vary the density. All that driven by the weather engine. but like I said, a very small and unimpressive one.

But at the time I was super happy of my sky dome technique, it worked without any shader, just a few layers of dome layers rendered with additive blending, and the correct color gradient adjustments with help of reference photos at different moments of the day, and yay ! no cost of scattering to pay. but of course, no fog/aerial perspective on objects...

 

For the aforementioned, and also much more recent technique and better looking, the man hour would be around 50 days * 8 hours. (so ~400 man hours.)



#14 Norman Barrows   Crossbones+   -  Reputation: 2126

Like
0Likes
Like

Posted 21 February 2013 - 02:46 PM

But at the time I was super happy of my sky dome technique, it worked without any shader, just a few layers of dome layers rendered with additive blending, and the correct color gradient adjustments with help of reference photos at different moments of the day, and yay ! no cost of scattering to pay. but of course, no fog/aerial perspective on objects...

 

The gradient effects are excellent for no shaders.

 

For the aforementioned, and also much more recent technique and better looking, the man hour would be around 50 days * 8 hours. (so ~400 man hours.)

 

That would be about a month at my current schedule. Probably more like 6 weeks in reality. More time than I ought to be spending on just clouds, I still have to do the final models and animations for 100-150 animals, and all the audio. The title has been in development now for about 13 months, and I hope to have it completed in another 2 or 3 months. I'm doing the final graphics last, hence my interest in techniques for drawing "final graphics" clouds (as opposed to "placeholder").

 

In 2006 I wrote a little weather engine with a little state machine, and it was capable of interpolating between sets of uniforms that the artists could save as presets and presented as "weather condition" in the interface, then a randomizer would make a sequence with a probability function that was evaluated using a special "distance" function between the weather state. (that made that some condition were far from other and thus rarely chosen as following each other. like snowy would rarely come after bright clear)
It was an internship at Etranges Libellules. the 6 years non disclosure is expired so I can say all I want

 

In Caveman v3.0, the weather engine models rate of change of barometric pressure, warming from daylight, and warming from time of year. From these it derives barometric pressure, cloud cover, wind speed, wind direction, precipitation, water table, and flooding.


Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


#15 Lightness1024   Members   -  Reputation: 736

Like
0Likes
Like

Posted 22 February 2013 - 11:39 AM

The dobashi technique responds to humidity. i've implemented a prototype of it in ~10/15 hours, with cubic rendering (one cube per voxel), very slow and ugly. But the technique is good to generate interesting evolutions and shapes. and its totally controllable. Local humidities, pressures, temperatures... can all be fed from your weather engine.

There is a journal from Issanaya (flavien brebion) on this technique on gamedev in an old log entry. This was also showed off at GDC 2008 and there is a demo here:

http://www.simul.co.uk/truesky/multicore

It is totally using dobashi (13 years old paper), and frankly it is barely impressive when you know the technique. But the rendering is innovative and there are some ideas to be taken.

The time I took to make the fractal technique was a lot of fine tuning, polishing, optimizing and robustification towards large use cases. This may not come into account depending on the professionalism of the project. In any case, the man hour can totally be drastically reduced using a development spirit focused on time rather than quality.



#16 Norman Barrows   Crossbones+   -  Reputation: 2126

Like
0Likes
Like

Posted 22 February 2013 - 08:21 PM

The time I took to make the fractal technique was a lot of fine tuning, polishing, optimizing and robustification towards large use cases. This may not come into account depending on the professionalism of the project. In any case, the man hour can totally be drastically reduced using a development spirit focused on time rather than quality.


Instead of building the best graphics engine i can, then squeezing as much game as i can into the remaining clock cycles, i build the game first, then squeeze the best graphics i can into the remaining clock cycles - a "GAMES are for playing, PICTURES are for looking at" approach. My games usually have complex scenes and a lot of simulation going on behind the graphics (think flight sims and total war vs unreal tournament). so much so that (hold on to your hats folks...) I actually run them at a time of scale 15 fps instead of 30 fps, so i get 66 milliseconds per frame to do stuff instead of just 33 milliseconds. Way back when (1980's), when it came time to decide on a frame rate, testing showed 15 fps to be the slowest possible frame rate that didn't produce input lag. my life is an exercise in trying to shoehorn too much game into to little computer. I have a saying: "Put a Cray on every user's desk, and I'll build you a REAL game". In my current project, i can't even use skinned mesh bones animation. it too slow for the number of targets i need to draw (i'm shooting for 150-200 at once, the original version from 2000 could do 50 targets in real time FPS combat with little or no slow down). Because of all this, i usually have to settle for graphics that require less horsepower than state-of-the-art graphics do. I simply don't have the clock cycles to spare, unless i up the system requirements (which i try to keep as low as possible for maximum compatibility). So usually i'll do the best i can with the clock cycles that can be spared, hence my question about drawing times. Development time is seldom an issue. I do the graphics last so they don't become obsolete while doing the rest. I was about to license Rend386 when Microsoft bought the company, took it off the market, broke it, then released it as DirectX 1.0 a year later. This forced me to write my own perspective correct texture mapped poly engine. Took some time, but it was what was required in the way of graphics code, so i learned how to do it, and did it. just like everything else. And today I learn clouds! <g>

Edited by Norman Barrows, 22 February 2013 - 08:35 PM.

Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


#17 Norman Barrows   Crossbones+   -  Reputation: 2126

Like
0Likes
Like

Posted 26 February 2013 - 03:24 PM

Lightness 1024:

 

So i take it that your overall approach is to procedurally texture map the skybox. the textures are generated images of 3D clouds, and you update the skybox at about 2 fps, correct?

 

and the trick is the algo used to generate the textures eh?

 

cloud motion in your system is motion of the 3d images in the textures, not the textures moving, correct?

 

so the skybox is like a big movie screen for displaying your 3D cloud skyscapes.


Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


#18 Lightness1024   Members   -  Reputation: 736

Like
0Likes
Like

Posted 02 April 2013 - 09:21 AM

yes you are correct :)






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS