Appropriate colours for gensky

G’day everyone! It’s been a long hiatus since I’ve touched Radiance, but I’m thrilled to see the community so active! I’ve recently been curious about Blender’s recently implemented multiple scattering sky texture, and curious if I could replicate it in Radiance (i.e. the artistic beauty aspect).

Ignoring for the moment multiple scattering itself (but I am very curious how the mist type can play into this), from my understanding, gensky generates a sky brightness distribution function, but this omits colour.

Currently, I only know of “artistically picking” an RBG here so long as grey(r,g,b) = 1. Here’s a super minimal definition:

!gensky -ang 2.51 -120.4 +s

skyfunc glow skyglow
0
0
4 .684 1.077 1.419 0 # These RGB are such that grey(r,g,b) = 1

skyglow source sky
0
0
4 0 0 1 180

# Just solid black ground for now, only interested in sky.
void glow groundglow
0
0
4 0 0 0 0

groundglow source ground
0
0
4 0 0 -1 180

I’ve rendered it using -e human.

Any suggestions on how to improve on this? Here’s a side by side comparison of Blender (left) and Radiance (right) (note: the fisheye projection probably isn’t identical, but close enough).

Apart from the obvious colour differences, there also seems to be an “ambient” sky brightness in Blender, whereas if I use -e human the Radiance sky exposure seems to be far too contrasty (strong gradient towards black) to what seems “right”. See top (human) vs bottom (auto):

image

image

Any mist hints would also be appreciated, would love to play with it!

Hi @Dion_Moult ,

Have you considered using the Utah sky model? This model already includes fairly accurate sky coloring.

Another solution is to use Taoning Wang’s new(ish) genssky, which creates spectral skies using an atmospheric scattering model. Even if you render in RGB, you will gain some benefit from its more accurate representation.

Best,
-Greg

The GenUtahSky code is here: GitHub - markstock/GenUtahSky: Radiance implementation of Preetham, Shirley, Smits model for sky color, plus more
Here’s my own implementation of a global mist-based sky: GitHub - markstock/genmistsky: Generate a multi-layered participating atmosphere for Radiance
FYI genssky is included in Radiance 6.0.

1 Like

I should add that genutahsky and genssky are close to drop-in replacements for gensky. Genmistsky is a little more challenging, runs slower (it does the scattering calculation per ray and not precomputed), but allows for crepuscular rays.

1 Like

Love that you snuck “crepuscular” in there… I believe genssky also calculates sub-horizon solar scattering at dawn and dusk. It would be interesting to do some comparisons. Taoning’s talk from the 2024 workshop is here.

-G

2 Likes

Thank you so much for all the great comments. I’ll love to work through a side by side comparison of all options. It looks as though the UtahSky is based on Preetham, Shirley, Smits in 1999. Whereas genssky seems to be more modern (Precomputed Atmospheric Scattering, Bruneton et all, 2008).

I must be doing something wrong, because surely these two should be identical (Sydney, Australia, 8am local time 21st June 2026):

$ gensky 6 21 8 -y 2026 -a -34.03520 -o -151.10557 -m -150 +s
...
solar source sun
0
0
4 0.789085 0.591605 0.165373 0.5
...

$ genssky 6 21 8 -y 2026 -a -34.03520 -o -151.10557 -m -150 -n 12
...
solar source sun
0
0
4 0.812935 0.053715 0.579873 0.533
...

In fact, for genssky specifying any different value of -a and -o and -m have no impact on the source vector (always hardcoded to 0.812935 0.053715 0.579873), only changing the time positional argument affects it.

In GenUtahSky, which uses libnova, a similar command returns:

# ./getsunvec 6 21 8 -y 2026 -a -34.03520 -o -151.10557 -m -150
# observer at -34.0352 deg lat, 151.106 deg long, 10 m ASL
# local time: 2026-06-21  8:00:00
# UTC: 2026-06-20 21:55:34
# using Astronomy for atronomical data
...
solar source sun
0
0
4 0.797983 0.583047 0.152573 0.5244

Maybe the genssky doesn’t process one of the additional argument? Edit: or maybe my code doesn’t process those arguments correctly!

Yes, it looks like there’s an issue with options processing in genssky, where it’s computing the solar angles before getting the options it needs to do that. I will write to @Taoning_Wang to ask him to look into it.

Thanks!
-Greg

@Taoning_Wang implemented a fix for the options parsing issue in genssky, and the new version has been checked into CVS. We are now trying to figure out some unrelated build issues on github, but we’re hoping to have that resolved and put out a new patch release sometime this week or early next.

Cheers,
-Greg

The corrected version of genssky is now part of the official 6.0.2 patch release, found here.

-Greg