Advertisement Jump to content
Sign in to follow this  

Procedural Skys - A Different Approach

This topic is 3829 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all. Yes it's me again to provoke more graphics related posts from this community. As many of you may already know (or may not know) I am programming a 3D terrain engine for the PSP. Quick rundown on specs for hardware perspective: 1-333mhz CPU 133-166mhz GPU (in depth: here) Before anyone starts throwing links my way about good procedural sky threads etc. Let me explain myself. ;) I have looked through: They are full of info yes, but for what I am doing, they seem like total overkill. Right now what I have is a skydome (hemisphere) created with math and triangle strips. What I would like to do is color the skydome based on the TOD (Time Of Day). I would determine the TOD based off of the PSP's internal clock. From all the math and other calculations that I can see this could be a major cpu killer, especially since I don't need photorealism on a small screen (480x272). What I was thinking is just approximate the colors of the sky and store the color value for every vertex somehow and update the sky every hour or so. This seems like it be a waste of data storage though. Right now I'm using 144 vertices for my skydome, multiply that by 24 hours (store colors for each hour to update) * 32 bit vertex color 144 * 24 * 4 bytes (32 bits) = 13 824 ~13.8Kb I am also using directional lighting and I am hoping to change the angle and color of this lighting based on the sun/moon. Any ideas, info, or techniques would be very welcome. :) Thanks again for help and interest. --Jonathan Janevski [Edited by - jjanevski on July 23, 2008 10:02:48 PM]

Share this post

Link to post
Share on other sites
Do you really need 4 bytes for color? You could probably use 3 only; since you probably don't need transparency for a skydoome; or you maybe use 4th byte for something else?

useing 3 bytes will get you somewhere around 10kb.

Share this post

Link to post
Share on other sites
There are a few things you can do to compress the storage:
*) Non uniform zenith angle, use more detail at the horizon, can reduce # verts to at most 60-70.
*) Reuse color sets, use one "day color set" and one "night color set" for several hours, 8 color sets should suffice.
*) As joe_bubamara stated, you don't need 32 bits precision, or even 24 bits since you interpolate, you will get all possible colors anyway.
*) From the good old links by filousnt, skip azimuth dependence for color and modulate brightness.

Let's say you have a 12*5 skydome, 8 color sets, 16 bits of color precision and zenith only dependence. With all the above it'd take 5*8*2 bytes = 80 bytes. For the entire skydome, 12*5*8*2 bytes = 960 bytes. A couple of years ago I specified 4 angles for azimuth and interpolated between, 4*5*8*2 bytes = 320 bytes.

Share this post

Link to post
Share on other sites

Have a look at this paper:

It describes a method to obtain the spherical harmonics coefficients for the sky radiance modeled using the Preetham model, as a function of the sun angle and the sky turbidity.

SH coeffs = f(sun angle, turbidity)
sky color(x,y,z) = SH( SHcoeffs, x, y, z)

The function SH evaluates the harmonics in a certain direction x,y,z.
The function f that returns the SH coefficients is based on a lookup table. This table, according to the paper, is 131kb for 7 bands and 28kb for 4 bands. I guess 4 bands might be enough for you as you are running the simulation on a tiny screen.
You can further cut down on the size by removing dependency on the turbidity for example.

The site contains the source code for the function f. Use google to find formulas for SH. If something is unclear don't hesitate to ask me.

Stefano Lanza

Share this post

Link to post
Share on other sites
Sorry for being "over thorough" but this is my first time around and I just need to make sure of everything. :)

I drew up a little picture to make sure I (and others) are all referencing things in a correct coordinate system.

I am not sure what denotation is used in game programming for the zenith and azimuth angles. I know that in mathematics azimuth is theta and zenith is phi, but in physical application azimuth is phi, and zenith is theta.

This paper on "sky color using gradients maps" seems to be very interesting and effective.

To combine this with what coelurus said I understand the following:

* use an image (.bmp or whatever) and store the color for every zenith angle (each vertex)
* to save on space store the colors for 8 times of day or so, and use 16, or even 8 bit color precision
* have a function that takes a given zenith angle and time of day, and returns the RGB color corresponding to the given input via a LUT (our gradient map)
* to update the sky color just interpolate the current vertex color for the day set with the next

Reitano: I am not familiar with spherical harmonics. Perhaps I will look into this as well. Your method though does sound a bit similar to the one that I am describing. I will read the info you posted and look into it more to try and clear things up. :)

I guess the hardest part of all this would be gathering a nice collection of "sky color sets" that could be applied at different times of day and then interpolated between.

Share this post

Link to post
Share on other sites
Well, I got this sorted out. I actually overcomplicated the matter because I didn't fully understand this method. It's actually very simple and effective. Shout out to Superpig!

Just some screenshots for you guys:

Next agenda is to correct the directional light angle (as you can see) and the diffuse and ambient light colored based on the time of day. :)


Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!