Twilight
with ozone:
without ozone:
Sunset
with ozone:
without ozone:
This is what you can achieve right now!
Twilight
with ozone:
without ozone:
Sunset
with ozone:
without ozone:
This is what you can achieve right now!
@nacioss Itās great improvement for the Sky Texture so far!
I would like to make a suggestion: ability to choose the sun position by day, time, latitude and longitude. I understand this is just an equation converting to elevation and rotation. This would be helpful to simulate sun path during a day. As an architect this kind of feature would be great!
If we put so many things into a node, then the UI would be no more simple. There are already add-ons that do it like https://blendermarket.com/products/real-sky
Lukas Stockner committed the patch that solved the sun flickering issue!!!
It also solves the white spots produced by the high strength of the sun hitting the surfaces, so now much less noise is produced!!
And as a side thing, the patch solved an issue i wasnāt aware of making the twilight color, again, different, but more accurate really !
Great! I was noticing the sky somewhat violet in your previous examples, I was wondering if it could have something to do with my cheap monitor, but it looks correct now.
Thanks nacioss and Lukas!
Yeah again, that was mine error, sorry about all the trouble really, but now for sure the sky is accurate (unless there is another hidden mistake i did).
By the way now you can all make amazing renders using it https://blender.community/c/graphicall/2mbbbc/
Waiting for Brecht to review the code so we can commit in master!
These are the results you get now:
I love how far this has come along! These skies look amazing!
This is a demo showing what the New Sky Texture is capable of
That looks phenomenal. Canāt wait for it to be included.
do you mean that strange behaviour @Alaska reported with those extensive tests?
and here you mean no more fireflies?
And what about this? was it still on blender mis side or was it a bug in your node?
@lsscpp The patch seems to have fixed both the issue I reported and fireflies.
Note: I have not tested āevery possibleā sun angle to see if the sun flickering issue is fully resolved. However, testing in previously problematic areas show no issues so Iām 99% confident it has been resolved.
We donāt really know. The issue seemed to be different depending on the compiler used. However, the patch that Lukas has committed seems to have resolved this issue. Once again, Iām only 99% confident this issue has been fixed as I havenāt tested āevery possibleā sun angle.
Thank you man, this is so fantastic! My next beer will be ācheersā for nacioss, lukas and you!
@nacioss Thanks for your fantastic work on the Nishita sky model!
I only have a few usability requests: Could you pls not hardlock the Sun elevation and Sun rotation?
It would make animating them so much easier! (maybe a softlock instead?)
And: could you open all the numeric variables for input?
Thanks again for your work <3
Unfortunately itās not possible to expose the parameters as input sockets because of how the model works (it generates a sky texture based on those only once). About the sun rotation parameters, I think itās good the current solution, waiting for Brecht to review the code now, so we will see.
Could you pls not hardlock the Sun elevation and Sun rotation?
You should be able to create a driver per each of those values to drive them and then also create a couple of value input nodes and drive those with the same property values in case you want those values to drive some other nodes as well.
Unfortunately itās not possible to expose the parameters as input sockets because of how the model works (it generates a sky texture based on those only once).
I suspected that the input sockets were closed for a good reason, still wanted to mention it. Thx for the clarification! <3
About the sun rotation parameters, I think itās good the current solution, waiting for Brecht to review the code now, so we will see.
Just dumping my thoughts:
The locked sun rotation (and even sun elevation) is just a minor annoyance.
With the elevation I kinda see where the hardlock is coming from. 0Ā° is ground level, 90Ā° is zenith. - but still then, a softlock would be sufficient to communicate the physical meaning to the user. imho.
With the suns rotation hardlock its a bit more questionable. No apparent meaning to the starting position anyways.
And everyone grasps the concept and the workings of angles in degree. Nothing really to save the user from.
An additional mapping node is the work around for trouble-free animation curves right now.
You should be able to create a driver per each of those values to drive them and then also create a couple of value input nodes and drive those with the same property values in case you want those values to drive some other nodes as well.
This wont work around the hardlock any better then f-curves could, unfortunately. But thanks for the input! <3
Keying a mapping node would still be more convenient, thats how I did it in the end.
You had me at the new texture model but then I scrolled the altitude slider and just fell in love.
Quick question : would a sun lamp be more optimized for Cycles than the disk in the texture (in terms of noise reduction)? I donāt notice a difference personally but I didnāt test thouroughly.
Good question and my quick answer is nope, there shouldnāt be any noticeable difference, because thanks to Lukas the sun disc is handled invisibly like a sun lamp
ļ¼( ź©āÆź© )ā§ĖĀ°