Perhaps renaming the older option to <name> + legacy, would at least guide new user to which is best to use?
2 Likes
Yes that describes my workflow just about 
The sun position addon fixes this partly, as it links a sun lamp to the sky texture orientation.
The Nishita sky implementation really is great. But as it doesnât work in Eevee, I am going to have to stick to Hosek-Wilkie for most projects for now.
You donât really have to, if you have a little bit of money to spend:
^ This is also a nice proof that thereâs no reason Nishita sky should not work with Eevee
6 Likes
You know how conservative Blender development is. Backward compatibility is broken once in a decade, or probably less often. The new sky has just settled. Giveâem the needed time 
3 Likes
Agreed, Nishita being in every way superior to older models, there seems to be no point keeping those except misleading users.
1 Like
The RGB to BW node still exists in the UI despite the fact that itâs been auto-inserted under the hood since like 2014. Thereâs no conceivable reason why youâd ever want to manually place one in a shader graph in any modern version of Blender. And the compatibility code to auto-remove it from old scenes is no more complicated than whatâs already done for squared roughness and the old displacement workflow.
Yet the shader is still there in the âConverterâ menu all the same.
Weâll loose the old sky models in about decadeâŚmaybe.
This may have been mentioned before, but i do not have time read all of the threads here. I have been playing around with the Nishita sky texture, Blender 2.90. I see that elevation only goes to 90 Deg. It seams I can only do a sunrise or sunset animation. I would like to go from sunrise to sunset. Will there be a greater degree, more than 90 DEG, sun elevation setting in the future to do sunrise to sunset animation? If I am missing something, please let me know.
Thanks
The problem in doing that is that when it goes above 90 degrees the sun would reach the opposite hemisphere, meaning that the Sun Rotation should change too, and that would create misconceptions.
When I used to use Maxwell Render, sky model seemed similar to Nashita model. I could do sunrise to sunset animations with it. Do you have a plan to implement a way to achieve this?
Itâs already achievable, just use an objectâs rotation as a driver for the Elevation and Rotation values.
Iâve found that the add-on âSun positionâ can help with this.
To enable it, go the user preferences, select the tab âAdd-onsâ then search for and enable âSun positionâ. Now you should have a menu in the âWorldâ panel of the âProperties editorâ giving you control over the sun.
Itâs probably not exactly what youâre looking for, but I hope it helps in some way.
Is there a way to hack this to work âin 3Dâ by which I mean that very tall objects (kilometers or tens of kilometers tall) observe a different sky and sun elevation at different elevations of the object, sampled every X meters of elevation and averaged between the samples? Think of the smoke/vapor trail of a space rocket that launched after sunset / before sunrise. Or mountain tops still enjoying the sunset skies after the sun has set at sea level.
Thanks for this great addition to Blender! As for my two cents regarding the default values and the whole lighting debate, why not have separate default files called, say, âGeneral Outdoorâ and âGeneral Indoorâ?
There is only one sky, and that is the accurate one.
Nope, just do that in 3d, by which I mean add a Volume Scatter object.
Sorry, I left out the important part: the default files would affect the default exposure and any other parameters that may differ in most cases between indoor and outdoor. The sky must remain realistic in any case.
2 Likes
I know Iâm late to the convo but I wasnât following this development until the sky shader made it into 2.90.
First, I absolutely LOVE this new sky model, Iâm going to be using this all the time, I can already tell. The old sky model was just so bad in comparison that I never found a use for it.
So thankyou so much for creating this, I really appreciate it, this is going to be so useful and allow for creating so many wonderful pieces of art in Blender, itâs absolutely game changing.
Second, on the topic of the brightness and whether to be physically correct or not, I believe the right decision was made. I was surprised for about 10 seconds when I used the new sky and found how bright it was but I immediately just figured âWell itâs daylight, daylight is very brightâ and I adjusted my scene exposure settings to suit. It wasnât a big deal and Iâm glad the decision was made to be physically correct. But I appreciate that concerns were raised about the usability, it was right to have those concerns but in this case I think it was better to be accurate.
Third, @nacioss if you can bring this sky shader to Eevee, along with turning the sun disc option into a drop down (none, texture, directional light), with directional light automatically manipulating a scene sun light with the correct directional values, colours, intensity, etc, so we can have real time viewport shadows generated from the sky shader⌠You can have my first born child.
9 Likes
A small papercut. The unit of altitude is a distance and per convention it should be a property marked as it and use the convention of 1 unit = 1 meter. This would allow users to input in what ever unit they want, for example typing in â1200mâ, â1.2kmâ or â10 milesâ would all correctly autoconvert.
22 Likes
Would I be able to add this with the mix shader to make a âtwin sunsâ?
Great work by the way! I Love it!
Does anybody experienced bugs related to keyframing the node elevation/rotation parameters?
I canât provide the file but hereâs what happened:
I have a few frames for multiple views of an interior render, where I switch the camera (via markers), and change the sky elevation/rotation.
Rendering still frames (F12) is ok, while rendering animation (Ctrl+F12) resets the sky parameters to some default in each frame!
Another issue: I can even see the undesired keyframed values change when I switch between frames! The only way to keep them stuck in the correct value (keyframed , yellow) is to have another - unconnected - nishita sky texture around in the world shader.
UPDATE:
seems like the bug only occurs if the nishita sky nodeâs Name is set to âSky Textureâ. If I change to whatever the values stick to their correct values when I switch framesâŚ
Interesting⌠please if you can provide the file i would be grateful
Really I cannot now. Iâll try to reproduce in a âfreeâ versionâŚ
1 Like