•      Sign In
• Create Account

Banner advertising on our site currently available from just \$5!

# Procedural Skys - A Different Approach

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.

8 replies to this topic

### #1jjanevski  Members   -  Reputation: 200

Like
0Likes
Like

Posted 23 July 2008 - 03:33 PM

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: http://www.gamedev.net/community/forums/topic.asp?topic_id=100346 http://www.gamedev.net/community/forums/topic.asp?topic_id=86024 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 http://jj.homebrewheaven.net [Edited by - jjanevski on July 23, 2008 10:02:48 PM]

Sponsor:

### #2Tom  GDNet+   -  Reputation: 352

Like
0Likes
Like

Posted 23 July 2008 - 03:51 PM

That's 110KB, not 11MB.

### #3jjanevski  Members   -  Reputation: 200

Like
0Likes
Like

Posted 23 July 2008 - 03:54 PM

Whoops yeah... :\ just checking if you actually read.

### #4joe_bubamara  Members   -  Reputation: 100

Like
0Likes
Like

Posted 23 July 2008 - 06:54 PM

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.

### #5FilouGK  Members   -  Reputation: 530

Like
0Likes
Like

Posted 23 July 2008 - 08:41 PM

http://www.phys.uu.nl/~0307467/docs/skydomes.htm
http://es.geocities.com/kenchoweb/skydomes_en.pdf

### #6hanstt  Members   -  Reputation: 259

Like
0Likes
Like

Posted 23 July 2008 - 09:13 PM

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.

### #7Reitano  Members   -  Reputation: 635

Like
0Likes
Like

Posted 23 July 2008 - 09:36 PM

Hello,

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

### #8jjanevski  Members   -  Reputation: 200

Like
0Likes
Like

Posted 24 July 2008 - 06:23 AM

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.
------------------------------------------------------------visit my: homepage

### #9jjanevski  Members   -  Reputation: 200

Like
0Likes
Like

Posted 26 July 2008 - 10:50 AM

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

Cheers...

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