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âŚ
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?
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.
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.
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.
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
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.
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.
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