New Sky Texture

Well, a supervisor or client doesnt care about this, nor should they.
Its amazing to have a physically based base, but there will always be a need of adjustments, especially in the creative industry.
So i agree with Atair, a sun multiplier would be great.

i know that feeling bro… :wink:

I will use this for now workaround for now, not elegant but it works:

1 Like

Well, it doesn’t work really because you are always getting a “white” sun that way.

Question to everyone:
Do you all want a Sun intensity multiplier in the Node?

6 Likes

Oh damn, you are right, my bad.

Without a sun intensity multiplier i wouldnt use the new sky texture like this in my daily work.
Im certain that i need the ability to adjust the sun intensity to meet clients needs/wishes.
Until then a hacked together nodegroup would be only solution, wich is fine for me personally … a direct solution would be way more comfortable though.

3 Likes

As ugly as it can be, a little nodetree is preferable I think.

1 Like

If we’re going to have sun disk size, we might as well. Sun disk size is also only used for alien skies and art directors who don’t like the physically correct result.

The Barcelona animation that’s in the release notes currently has some pretty obvious “sliding” ripples on the water surface. Now that we have proper 4D noise in Cycles, might be good to fix that for the sky demo.

If it isn’t too hard to implement, then this would be a nice feature to have.

Also due to the nature of how the sun disc gets sampled, we are thinking about completely removing the Vector input. As of now if you connect something to it the sky will be sampled with a MIS map of 4096 x 2048 meaning that sometimes the sun doesn’t get sampled. This leads to rendering issues like missing sun lighting. So we are seriously thinking to remove the Vector input

remove the vector input and expose all the properties as inputs so the node can be included in groups and exposed to group interface.

Already asked for that.

1 Like

Hi @nacioss,

Thanks for working on this! Can you provide any more details as to the specifics of the model you used? For example, your thread says this is the Nishita model, but is it the 1993 single-scattering model or the 1996 multi-scattering model? In addition, Nishita doesn’t include a solar disc in the model, so what did you end up using for that?

Lastly, can you provide any detail about how you’ve verified sun irradiance/radiance and sky irradiance/radiance at different times of day and in different turbidities? If not, is there a way to adjust the individual contributions of both?

If you’d like more details on how to verify your sky model, please look at https://arxiv.org/abs/1612.04336 or https://www.yiningkarlli.com/projects/skydomecompare/Kider2014.pdf. If verifying physically-accurate values is a bit out of reach at the moment, I’d be happy to take a stab at it in the future. This will be increasingly important as people start using physical camera values and expect the sun/sky to give proper absolute exposure to scenes.

3 Likes

It’s Nishita sky model 1993 single scattering, but improved in the sense that i added the Sun disc and Ozone Absorption features from other various scientific papers.

Definitely! thank you, very appreciated :slight_smile:

1 Like

Yeah I know. But it’s a really bad reason for not exposing them. Things are allowed to create physically incorrect results in cycles and the parameters need to be exposed to be able to include them in node group interfaces. It’s just how blender works.

I will repeat, given the nature of how the model works, it’s not possible to expose the inputs as input sockets, sorry for that.

1 Like



It looks like the sky texture breaks Optix Denoiser when you point camera directly to the sun. it produces glitches both In the viewport and the render.

1 Like

Then how are there value sliders on the node itself?

Also the older sky methods like Hosek/Wikie don’t expose them as input sockets.
That’s because the model we implemented precomputes a 512 x 128 sky texture every time there is a UI change, this means that we can’t expose the sliders as input sockets because the model itself asks for just 1 and only 1 input value, meaning you can’t put a grayscale texture in it, because it simply can’t accept multiple values, that’s how it works.

maybe a thought for a later update if this above happens:
Vray has a very useful ‘Horizon Offset’ which is needed as we rarely have scenes that extend to the horizon and this leads to an ‘unnatural’ horizon line…
It is easy to do with a mapping node for now, but if things change…

since sampling the tiny sun disc turned out to be problematic for the MIS (Multiple Importance Sampler), me and @lukasstockner97 are considering to remove the Vector input completely.
Horizon shifting is a specific use case feature and we won’t add it