Hosek/Wilkie sky model weird coloration #50458

New Issue

Alex P · 2017-01-17T17:43:59+01:00

Alex P commented

2017-01-17 17:43:59 +01:00

System Information
Widnows 10, ATI HD7750

Blender Version
2.78a

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):
http://cgg.mff.cuni.cz/projects/SkylightModelling/HosekWilkie_SkylightModel_SIGGRAPH2012_Preprint_lowres.pdf
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: http://cgg.mff.cuni.cz/projects/SkylightModelling/ ):
http://cgg.mff.cuni.cz/projects/SkylightModelling/SunCloseup_005_06.jpg
http://cgg.mff.cuni.cz/projects/SkylightModelling/SunCloseup_0025_07.jpg
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.

**System Information** Widnows 10, ATI HD7750 **Blender Version** 2.78a **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): http://cgg.mff.cuni.cz/projects/SkylightModelling/HosekWilkie_SkylightModel_SIGGRAPH2012_Preprint_lowres.pdf 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: http://cgg.mff.cuni.cz/projects/SkylightModelling/ ): http://cgg.mff.cuni.cz/projects/SkylightModelling/SunCloseup_005_06.jpg http://cgg.mff.cuni.cz/projects/SkylightModelling/SunCloseup_0025_07.jpg - 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.

Alex P commented

2017-01-17 17:43:59 +01:00

Changed status to: 'Open'

Alex P commented

2017-01-17 17:43:59 +01:00

Added subscriber: @Alex-9

Alex P commented

2017-01-17 17:45:13 +01:00

sky_bug.blend

Here is a video showing how it should look (not mine):
https://www.youtube.com/watch?v=DKjquLIe-d4

[sky_bug.blend](https://archive.blender.org/developer/F435369/sky_bug.blend) ![sky_bug_t02.jpg](https://archive.blender.org/developer/F435362/sky_bug_t02.jpg) ![sky_bug_t04.jpg](https://archive.blender.org/developer/F435365/sky_bug_t04.jpg) ![sky_bug_t06.jpg](https://archive.blender.org/developer/F435364/sky_bug_t06.jpg) ![sky_bug_t08_g10.jpg](https://archive.blender.org/developer/F435368/sky_bug_t08_g10.jpg) ![sky_bug_t08_g06.jpg](https://archive.blender.org/developer/F435367/sky_bug_t08_g06.jpg) ![sky_bug_t08_g00.jpg](https://archive.blender.org/developer/F435363/sky_bug_t08_g00.jpg) ![sky_bug_t08_g03.jpg](https://archive.blender.org/developer/F435366/sky_bug_t08_g03.jpg) Here is a video showing how it should look (not mine): https://www.youtube.com/watch?v=DKjquLIe-d4

Aaron Carlisle commented

2017-02-02 06:39:58 +01:00

Added subscriber: @Blendify

Aaron Carlisle commented

2017-02-02 06:39:58 +01:00

Moving to the todo list for now.

Aaron Carlisle commented

2017-02-02 06:41:23 +01:00

Added subscribers: @Sergey, @ThomasDinges

Alex P commented

2017-05-26 11:38:50 +02:00

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.

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.

tonemgub commented

2017-06-23 20:28:21 +02:00

(Migrated from localhost:3001)

Added subscriber: @tonemgub

tonemgub commented

2017-06-23 20:28:21 +02:00

(Migrated from localhost:3001)

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?

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?

tonemgub commented

2017-06-23 20:40:41 +02:00

(Migrated from localhost:3001)

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

albedo

(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

> 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 > albedo ![ground sky.exr](https://archive.blender.org/developer/F640311/ground_sky.exr) ![color-ground.png](https://archive.blender.org/developer/F640310/color-ground.png) ![ground sky.jpg](https://archive.blender.org/developer/F640309/ground_sky.jpg) (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

tonemgub commented

2017-06-23 21:48:57 +02:00

(Migrated from localhost:3001)

innac shd.blend

[innac shd.blend](https://archive.blender.org/developer/F640375/innac_shd.blend)

Marco commented

2020-07-25 12:26:44 +02:00

Added subscriber: @nacioss

Marco commented

2020-07-25 12:26:44 +02:00

Changed status from 'Confirmed' to: 'Archived'

Marco closed this issue

2020-07-25 12:26:44 +02:00

Marco self-assigned this 2020-07-25 12:26:44 +02:00

Marco commented

2020-07-25 12:26:44 +02:00

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 @ThomasDinges can say something since he implemented it.

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 @ThomasDinges can say something since he implemented it.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Hosek/Wilkie sky model weird coloration #50458

Solar Radiance Function