Archived

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

ycwn

about "a practical analytic model for daylight"

Recommended Posts

greetings! i have implemented the skylight section of the above paper and i thought that some of you would be interested in what i found. color conversion: using the following equations (found in another thread) i converted from Yxy to XYZ: X = x * Y / y Z = (1 - x - y) * Y / y no scaling down or exposure applied yet and Y remains as is. then from XYZ to RGB using the following conversion: R = 3.240479 * X - 1.537150 * Y - 0.498530 * Z G = -0.969256 * X + 1.875991 * Y + 0.041556 * Z B = 0.055648 * X - 0.204043 * Y + 1.057311 * Z the matrix is rec. 709 (D65) but i think any can be used with similar results nothing new until here now because the above RGB values would be way out of range they have to be scaled down. to do that find the color with the greatest magnitude and then scale all values by something like: brightness / rgb_max the above color can be found by using the perez equation with theta=theta_sun and gamma=0 good values for brightness are 2.0-2.5 for the sun this can be used to simulate moonlight as well! just put the sun where the moon is () and set brightness to anything between 0.10 and 0.20 problems: if you implement this you will find that for small negative altitude angles of the sun, the sky is quite bright and at some point the sky goes completely black (somewhere between -9deg and -10 for tubidity 4 and -4 and -5 for turbidity 6) to solve this just use the brightest color with theta_sun=90deg (sun_altitude=0deg) if the sun lies below the horizon. this will give a nice fade to black as the sun falls behind the horizon now for greater negative values of the altitude you will notice that the sky takes a bluish color that happens because Yzenith / F(0, theta_sun) goes negative, inducing strange calculations in the XYZ->RGB matrix to solve just clamp Yzenith / F(0, theta_sun) to zero if negative. or you can use this as an optimization hint and skip all further calculations

Share this post


Link to post
Share on other sites

i run the equations twice (in software)
once for the the sun and once for the moon
and then scale and add the results in a
vertex program (primary color sun and
secondary color moon)

it not yet dynamic, although it can be made
since it needs about 26ms for 8256 vertices
and the motion of the celestial bodies is
quite slow (one degree/four minutes in realtime)

it looks very good, and this is why i posted
it doesnt saturate in daytime nor does it look
very dark at sunset with the same brightness
(no need to re-adjust it)

it is also very fast:
160-200 fps at night with about 9000 stars
rendered as point primitives and about 500
fps without them (athlon xp 2100/GFfx5600)

sorry that i cant post any screenshots
but i dont have online space

when i tried to implement it, i had no idea
what to do with the Yxy values. so i searched
the forums and experimented with what i found
now i posted the results so others may come and
experiment with them

minor problem:
extreme turbidities make sky completely white
<~1.5, >~12

Share this post


Link to post
Share on other sites
you have always online space to share files

go to my page, go to free.. feel free to load on it what ever you want..

i really want to see those pics..

"take a look around" - limp bizkit
www.google.com

Share this post


Link to post
Share on other sites

davepermen:
thank you very much!

pickups:
ATI made an implementation of the equations
(simplified?) in hardware. i dont know if
they used the ones from this paper or not.
i think the sky color in the paper looks
better than the one ATI has implemented.
i cant say much about the aerial perspective
part since i haven't tried anything yet, but
the model in the paper seems a bit expensive
and ATI's looks equally good

the screenshots were taken at 800x600
with turbidity=3. had to comment out
the stars and moon for the first two

1. Noon
sun is 45deg above horizon


2. Sunset
sun exactly at 0deg. higher turbidity values
give more red around the sun


3. Moonrise
sun at -45deg, moon at 0deg
it's color should be yellow or orange
stars are point primitives with glow around
brighter ones. data taken from the bright star
catalog http://amase.gsfc.nasa.gov/amase/MissionPages/YALEBSC.html
(above link doesn't appear valid. see this: http://starplot.org/datafiles.html)
"a physically based night sky model": vterrain.org, under atmosphere


4. Full moon
moon at 45deg. you can see orion on the right



[edited by - ycwn on July 8, 2003 8:42:41 PM]

Share this post


Link to post
Share on other sites
Nice looking screenshots. I''ve got a couple of questions if you''ve got time to answer them:

Is the sun just the result of the vertex colouring or do you blend something on top of the sky dome as well?

How do you tesselate the sky dome? Is it tesselated more finely around the sun or is the tesselation uniform across the dome?

I''m curious because when I did the sky in the game I''m working on I looked at this paper but ended up going with something much simpler (just some hand coded colouring for several times of the day and blending between them) and I found that the sun didn''t look very good if I baked it into the vertex colours unless I tesselated the sky dome (actually a sky sphere in my case) very finely, so I ended up adding the sun as a blended texture on top. There was a particular problem as the sun moved around the sky (which it does at a greatly exagerrated rate) as you could see the tesselation quite clearly around the sun as its position changed.

Share this post


Link to post
Share on other sites
quote:
Original post by ycwn

minor problem:
extreme turbidities make sky completely white
<~1.5, >~12



Try running the vertex colours through an exposure function, as this is probably due to saturation of the colour values.

Share this post


Link to post
Share on other sites

thanks!

mattnewport:
in these shots the sun results only from vertex colors
i plan to blend lines (so the sun seems to shine) but
they dont look good yet. the tesselation is uniform
now that i think of it you could be right

pickups:
exactly

jamessharpe:
it should adapt automatically, so this means there''s
a division by zero (or something) somewhere

Share this post


Link to post
Share on other sites