#### Archived

This topic is now archived and is closed to further replies.

# Sky Colours - A Practical Analytic Model for Daylight

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

## Recommended Posts

I''m trying to implement "A Practical Analytic Model for Daylight" to get vertex colours for a skydome, however I am getting very large values for the luminance. This is causing my vertex colour calculations to overflow(stored as unsigned chars), and gives colours that are undesirable. Can anyone tell me how I should scale the luminance value so it is in the correct range?

##### Share on other sites
Uhh... Why not just multiply them by a "brightness scale" percentage value? I''m not overly familiar with the paper (or whatever it is) in discussion though, so that solution may or may not be plausible.

Trent Polack
trent.codershq.com
trent@codershq.com
Author of Focus on 3D Terrain Programming

##### Share on other sites
First do all your math in floating point (floats or doubbles) then convert to unsigned chars at the end. If values go out of range (usualy around of sun) just clamp them. Also there are other ways to convert Xyz color to RGB than described in that paper (709 RGB with D65 white point matrix). [some screenshots from my implementation : http://www2.arnes.si/~ssdmtera/download0.htm]

You should never let your fears become the boundaries of your dreams.

##### Share on other sites
That''s exactly what I was doing - all the maths in floating point and then converting at the end, using the 709RGB with D65 whitepoint matrix.

What is the range that i should be clamping to, and in which colour space?

##### Share on other sites
Just tried clamping RGB floating point values to [0.0, 1.0] range - this gives a yellow! sky for most of the time and an orange band moves across it, and then returns to yellow.

EDIT: I think the problem may lie in the calculation of the Zenith Yxy values. I'm using the equations at the end of the paper, these are giving me values of ~3.4 for Y, x and y, which I know is obviously wrong since x and y must lie in [0,1].

EDIT: Duhh.. I was calculating theta for the sun wrong! I was mulitply Pi by 2 instead of dividing by 2, however I have now got a pure whiet sky, do I need an exposure function of some kind to bring the colours back in range?

[edited by - jamessharpe on June 2, 2003 1:51:06 PM]

[edited by - jamessharpe on June 2, 2003 1:59:24 PM]

##### Share on other sites
I am using an exposure ramp for luminance. The XYZ->RGB conversion is also D65 Whitepoint.

new_Luminance = 1.0 - exp(-(1.0/expsure) * Luminance);

I have source on my website, it uses the OpenSceneGraph as scene graph.

_DarkWIng_:
how did you get such a nice reddish sunset? Mine is to yellow.

eisscholle.de

[edited by - stephanh on June 2, 2003 2:47:32 PM]

##### Share on other sites
There are alot of parametrs to play around. I just found some that make sun red

But my exposure is a bit different. I gor from Xyz to HVS, use exposure function (exponential like yours or linear) in HVS space then convert back to RGB.

: I also do some kind of gamma correction after exposure so this gives a bit different colors also.

One question for you: how do you handle points that are under horizon? I was geting some wierd colors so I just used color from horizon (or a bit bellow it).

You should never let your fears become the boundaries of your dreams.

[edited by - _DarkWIng_ on June 2, 2003 4:04:44 PM]

##### Share on other sites
quote:
Original post by _DarkWIng_
There are alot of parametrs to play around. I just found some that make sun red

Hehe, i just played around with the parameters explained in the paper but haven''t got far. So there''s hope...thanks

quote:

But my exposure is a bit different. I gor from Xyz to HVS, use exposure function (exponential like yours or linear) in HVS space then convert back to RGB.

I also tried this some time ago, though i haven''t found a direkt conversion from Xyz/XYZ to HSV (i think we already had this in another thread)

quote:

One question for you: how do you handle points that are under horizon? I was geting some wierd colors so I just used color from horizon (or a bit bellow it).

The angles (from zenith) are limited to -PI/2 to PI/2. I simply don''t use angles (for the samples) out of that range and move the skydome as low as neccessary so i don''t see the edge. It''s a limitation of the model.

eisscholle.de

##### Share on other sites
Thanks for the help I''ve got it working now.
quote:

Original post by _DarkWIng_
There are alot of parametrs to play around. I just found some that make sun red

Are the parameters you need to adjust the perez coefficients for the chromaticity values, the XYZ to RGB matrix or both?

DarkWing : for your clouds are you using a separate plane or are you texturing the dome? I''ve got a perlin noise generator for my clouds and that''s produced good results, I was just wondering how to go about applying it onto my sky.

Also the night sky with this model isn''t very good - has anyone considered implementing a different model for the nightsky?

##### Share on other sites
I did play with perez coefficients but not for pictures on my site. They can give you some WIERD results (alien world skys). The most important values are turbidity, sun height and gamma correction.

Clouds are mapped to the dome. I projected points of skydome to virtual plane then mapped texture coordinats back to dome.

stephanh : I haven''t found direct XYZ to HSV conversion so I go from XYZ ro RGB then to HVS

You should never let your fears become the boundaries of your dreams.

##### Share on other sites
I have no idea as to how to go about projecting the clouds onto a virtual plane and then back to the dome. Could you please elaborate upon how to do this. For instance, is the plane located horizontally of vertically w.r.t the viewer, or is it formed at a tangent to the dome? Also is your spacing of vertices on your dome regular or is there a higher density towards the poles?

##### Share on other sites
Skydome is somehow exponential tesselated. Since color gradients near horizon are much more compressed then high in the sky you just have to put more triangles there.

The point of cloud plane is somthing like this: (It''s not the best approach but it works for me... for now)
Imagine a virtual cloud plane over skydome. You''ll have to experiment a bit how high you have to put it to make it look good. Then for each point of skydome:
-get a ray from origin to point
-find point where this ray intersects virtual cloud plane (simple ray-plane intersection)
-use X and Z (depends on your coordinate system) of this new point as S and T cordinats for texture mapping (you sometimes have to scale them down a bit)

To get clouds moving over the sky just change texture matrix each frame a bit.

The good point of this is you need only one pass & one texture unit to do this. The bad thing is you loose some flexibility.

You should never let your fears become the boundaries of your dreams.

##### Share on other sites
Okay, i understand now. So if I was to add some shading to the clouds based on multiple scattering I would do the same sort of thing - project it on to the plane and then map it on to the dome - yes?

##### Share on other sites
Right. You''ll just have to use same texture coordinats for all texture units..

You should never let your fears become the boundaries of your dreams.

##### Share on other sites
Wait, is it better to scale in HSV space (as Darkwing), RGB space (unlikely), or XYZ space (scale Y, as http://www.eisscholle.de/index.php?d=devel/openmountains&sub=daylight )? Or something else -- like assuming the eye is adapted to some spectrum and using a von Kries transformation (Fairchild, Color Appearance Models)?

##### Share on other sites
I found the old thread i was refering to above.
http://www.gamedev.net/community/forums/topic.asp?topic_id=100346

Seems one could get better results when scaling in HSV. Cannot comment on the last one, since i don't know what Kries transformations are.

But isn't it required to scale either Luminance or RGB before convertig to HSV? My conversion function RGB2HSV requires the RGB values in scale.

regards,
Stephan

eisscholle.de

[edited by - stephanh on June 6, 2003 1:59:24 AM]

##### Share on other sites
quote:
Original post by stephanh
But isn''t it required to scale either Luminance or RGB before convertig to HSV? My conversion function RGB2HSV requires the RGB values in scale.

No.

float max, min, delta, hue, saturation, value;max = max(R, G, B);min = min(R, G, B);value = max;saturation = (value != 0) ? ((max - min) / max) : 0;if (saturation == 0) hue = 0; // undefinedelse { delta = max - min; if (R == max) hue = (G - B) / delta; else if (G == max) hue = 2 + (B - R) / delta; else if (B == max) hue = 4 + (R - G) / delta; hue *= 60; if (hue < 0) hue += 360; hue /= 360;}// scale value either exponentially or linearly://  value = 1 - exp(-(1/exponentialScale) * value);//  value /= linearScale;skycolor = color "hsv" (hue, saturation, value);

##### Share on other sites
Er, not to beat a dead horse with the completely obvious, but scaling RGB linearly is the same as scaling the value in HSV coordinates.

##### Share on other sites
AP, if that were true then why is there not a direct matrix conversion between RGB and HSV. You are implying a linear relationship between RGB and HSV, but I don''t think that there is one, correct me if i''m wrong.

##### Share on other sites
Scaling V out of HSV is of course linear but otherwise you''re talking out of your ass

##### Share on other sites
quote:
Original post by jamessharpe
AP, if that were true then why is there not a direct matrix conversion between RGB and HSV. You are implying a linear relationship between RGB and HSV, but I don''t think that there is one, correct me if i''m wrong.

If you double each RGB coordinate, the hue and saturation do not change. Only the value doubles. This is not a linear change of coordinates.