New here. Followed this thread and many others with some interest in recent weeks. Thanks nacioss for the great work.
Will the work being committed here be usable by other renderers within Blender? I believe that each renderer has its own implementation of sun and sky lighting but what you’ve done here is really cool. I’ve been using ProRender within Blender and some of the sun + sky behaviors are a little strange and seem consistent with a couple of the complaints that were lodged about the Cycles sun + sky early in the thread, before the new ones were implemented. Sorry if noobish question.
Hi @CarlsBad. This sky is specific to Cycles but it wouldn’t be impossible to port to other open source renderers if somebody were sufficiently motivated.
Hi there, I used the new sky texture in 2.9 alpha and it worked great. Now I tried to use it in 2.9 beta and I guess the intensity changed, because I’m getting very blown-out results. What is the correct Exposure setting to replicate the 2.9 alpha state?
In case anyone has issues with the sun disc disappearing from sun angles of 14.4° and higher, due to contantly being scaled down, in the latest 2.90 build (while working with a file already containing the sky texture made with an older 2.90 build) just delete the existing sky texture node and re-add it with the same settings as you used it before. then everything works as expected.
That depends really. It’s fine to use Strength parameter too. It really depends if one wants to simulate more realistic exposure range or not. In some cases, people will want to retain the intensity of their already existing scene lights exactly the way they are, but just introduce the skylight to that scene. In such case, it’s perfectly okay to use the Strength value instead of exposure, as it’s much easier to adjust just that one parameter, than to adjust exposure and then fix intensity of every single light already present in the scene.
Thank you for sharing this paper, it’s interesting and based on previous Sky models.
The Nishita model we implemented in Blender is using single scattering for now, but for sure will work to implement multiple scattering soon, probably in Blender 2.92… we will see.
Though, it should not be hard to do as the actual implementation has light scattering functions all ready for the upgrade.
A new video has popped up on official Blender channel where Pablo showcases the two old, unfinished and unusable sky models in Eevee:
I already mentioned it in some of my posts above, but I am gonna repeat it. Those old, unfinished models left in completely unusable state should be deprecated and removed. If even official Blender staff tasked with creating content for official Blender YouTube channel does not know which model to use, then how can you expect an average new user to make a right choice?
Nishita is default anyway so not a problem for the final user.
The old Preetham and Hosek / Wilkie sky models are correctly implemented (checked the code, unless i’m missing something), and are sharing the same code, so the removal of one implies the removal of the other.
I really think it’s cool to have a list of multiple sky models I mean, is there any other program out there that does that?
How are they correctly implemented? They don’t have any physical sun to go with it. So you end up with a Physical sky which has some hard coded atmospheric scattering based on a sun light which is non existent. What’s the workflow there? You create a Preetham or Hosek sky texture, then you twist this weird sphere vector knob around, then you put in a “Sun” lamp which you try to randomly turn around to roughly match the sky direction, and then input some random, eyeballed, non physical sun luminosity value which is completely unrelated to the luminosity used for atmospheric scattering of that sky model, and then you kinda hope it will not look bad? I mean the sun won’t even change color based on angle.
There’s literally no feasible workflow to get it right. Physical sky model ALWAYS requires a sun component it’s tied to. Without sun, both these sky models should return solid black as there are no photons hitting the atmosphere.
I mean just look at that video, he doesn’t even know what is he doing. He’s just randomly twisting the knob and getting this weird random gradient that doesn’t even preserve the horizon line straight, and he is getting this weird illumination of impossible sky model which scatters a light source that does not exist in the scene throughout the atmosphere. It’s just insane…
Not everyone is tech artist or super focused on realism, for a lot people “randomly twisting the knob” until they get something what they like is enough…
doing abstract work ( or when experimenting ) for me is to search for a happy accident, doing random things untill i got something unspectedly beautifull is a way to work
disagree with nishita being the default not causing issues for the user, as there is no eevee equivalent, the sky shader will still seem to not work at first glance, would love to see a nishita eevee equivalent, even if its not as accurate
Yes, exactly. The sun component is missing, which makes the Physical Sky model unusable. The point of using the Physical Sky models is to simulate time of the day lighting scenario, which can not be achieved without the Sun Component.
And yes, you can in a very clumsy convoluted manner link Sun lamp direction to drive the Preetham/Hosek sky direction, but you can not:
Achieve having the properties of the sun lamp such as intensity and sun disc size (which is not even visible) affecting the Sky atmosphere scattering.
Achieve having the sky atmosphere scattering affecting the color of the sun light depending on the time of the day (from slightly yellow at the zenith to deep orange near the horizon).
There is really no point in having a physically based sky texture that can not simulate at least physically plausible sky. That’s why Preetham and Hosek sky models should either be finished, or removed. Otherwise the only purpose they serve will be as a trap for new, unsuspecting users.
Honestly, I’d rather have just one model - yours, working in both Cycles and Eevee. Right now, the sky model selector in the sky texture presents users with 3 choices: Right/Wrong/Wrong. Even if both models were fixed (which they most likely won’t), the users would still be presented with 3 choices: Better/Worse/Worse. In general, if a new feature exceeds older one, the right way to got about it is to use it as a replacement, instead of offering it as an alternative. A poor choice of keeping both better and worse options around for the sake of legacy compatibility leads to both cluttered user interfaces as well as steep, confusing learning curves.
I mean, is there any other program out there that does that?