Page MenuHome

Hosek/Wilkie sky model weird coloration
Closed, InvalidPublicTO DO


System Information
Widnows 10, ATI HD7750

Blender Version

Short description of error
Hosek/Wilkie sky model has wrong "greeny" sun glow coloration. It's visible with turbidity set to 2, 4 and 6. That halo should be white-blue. Ground color can be set from 0.0 to 1.0 so it should be always "grey" but when turbidity is set about 8 changing ground albedo causes ground coloration from pink to blue. Besides original model allows to set RGB ground color, in blender only monochromatic albedo can be set.
Here is original model documentation and none of this can be seen (please take a look @ page 9 for albedo setting):
I think that original sky model was introduced in blender in 2012 but model was updated later and not updated in blender.
Additionally some enhancements could be made:

  • Sun color node. That would control temperature and intensity of sun depending on angle and turbidity to get near-natural complete sun-sky lighting (now we have to eyeball sun temperature and intensity). That could also control "limb darkening" effect as in original model: (from: ):

  • Allow direct visibility of sun lightsource to allow bloom/glare do their job and make nice sunstars directly in compositor

Exact steps for others to reproduce the error
Please open attached file. It's simplest "cube" scene with two cameras pointing sky and ground. Just render and see.

Related Objects

Event Timeline

Alex P (eneen) created this task.EditedJan 17 2017, 5:43 PM

Here is a video showing how it should look (not mine):

I think it's related:
Luxrender currently has option for custom ground color, really nice feature for larger scenes where there is need to model plane to hide sky leaking from ground. It works independently to albedo.

sun is not available maybe but in luxrender(spectral) it is

ArHosekSkyModel.h Version: 1.4a, 2013-02feb

Solar Radiance Function

For each position on the solar disc, this function returns the entire radiance
one sees - direct emission, as well as in-scattered light in the area of the
solar disc. The latter is important for low solar elevations - nice images of
the setting sun would not be possible without this. This is also the reason why
this function, just like the regular sky dome model evaluation function, needs
access to the sky dome data structures, as these provide information on
in-scattered radiance.

CAVEAT : in this release, this function is only provided in spectral form!

RGB/XYZ versions to follow at a later date.

luxrender allows optional show only
atmosphere, atmosphere+sun, sun-noSky(innacurrate, lacks attenuation)

but allowing to specify as separate objects would that allow for multi-importance optimizations?

the werid below-ground color

isn't that irrelevant?
i don't think anything below the horizon is supposed to be real data,
from the paper it seems it a model-function(faster,efficient) that is designed to fit their simulated(slow) data


(blocky ico-polysphere is ground-color)

no it essentially means reflected-color here (same as 3 separate albedo's for RGB), not fully implemented in blender
, and recently in luxr1.6

Marco (nacioss) closed this task as Invalid.Jul 25 2020, 12:26 PM
Marco (nacioss) claimed this task.
Marco (nacioss) added a subscriber: Marco (nacioss).

Closing as it's a known limitation of the implemented model, checked the code and it doesn't seem to have issues at all, the code is equal to the official Hosek/Wilkie code.
And on top of that, the ground is not meant to be accurate at all.
Maybe @Thomas Dinges (dingto) can say something since he implemented it.