New Sky Texture

[nacioss]

Added Sun Disc toggle!!

[AugustoCezar]

That is so nice! Congrets!

[mib2berlin]

Thanks YAFU, time to build.

Cheers, mib
EDIT: Works like a charm @nacioss and @YAFU

[LazyDodo]

I’ve never done linux builds before so unsure how well they will work, but if anyone wants to have a go at it:

New Sky Texture - Experimental Linux Daily Build — GraphicAll

[mib2berlin]

Do a short test and all seams fine on Opensuse Tumbleweed.

Cheers, mib

[LazyDodo]

@nacioss screenshot, but i needed it hosted somewhere so i can link it in the GA builds

[nacioss]

Added ground! This simply takes the horizon pixels and fade them down.

[AlexeyAdamitsky]

This is outstanding work. Thank you for implementing this!

[nacioss]

Added Sun Size parameter!!

[smilebags]

This is giving me Tatooine vibes. Nice work.

[Harleya]

Wow, this thread is awesome for new surprises. Not sure what will come next. Inferior mirage, mock mirage, green flashes? LOL. Seriously just kidding, this work is beautiful.

[rogper]

Hello @nacioss,
Thank you very much for your awesome work once again!

I’m a long time “Real Sky” user and the only thing that becomes a bit confusing to manage, are the negative exposure values (I’ve noted that you have a -2 value in the last screen), for two reasons and this is from my experience:

• Emission materials need to be set real high to have any effect on the scene, which makes them look over bright on the texture preview mode, specially when using Bloom;

• On the Compositor, the color curves and some color operation nodes get flipped. For example, brightening an image is a downwards curve and darkening an image is a upward curve ( due the exponential nature of them ) and, in the color corrector, if you set it to blue you actually tint the image of red or something similar .

I understand that this gives the most realistic results and mimics real life behavior… but ain’t there any way to go around this so that, at least the compositor color corrector nodes, don’t go counter intuitive?

Thanks for the Linux build @LazyDodo! It works here just perfect.

[silex]

@Harleya

Inferior mirage, mock mirage, green flashes?

[nacioss]

Anything related to compositing is not my fault.
Anyway, with just an exposure value of 0 you will get acceptable results with this sky texture, so i think you should have no worries about that, we will see how it will evolve.
Look at these results:

Nishita improved 2:44 minutes

Hosek-Wilkie 2:27 minutes

[silex]

I’ve tried Linux build: https://blender.community/c/graphicall/9mbbbc/
I cannot get it working on Debian Buster:

Also when I click on Preview in preferences - Blender crashes. In temp there is a crash file, but it’s completly empty.

[nacioss]

I see you are using CPU with OSL enabled. Disable it and it should work. Don’t try everything else other than the Ske Texture, it’s still in development stage so we are aware of that issue you mentioned

[silex]

Damn, I forgot to change settings from production, thanks for pointing out.
Anyway - little, to no progress. After disabling OSL, and with Cycles at ‘supported’ feature set most things are working correctly. The issue is that there are no gradients in the viewport:

[nacioss]

Not sure why, are you in orthographical mode? If so then press 5 on numepad

[Jason_C]

Emission materials need to be set real high to have any effect on the scene, which makes them look over bright on the texture preview mode, specially when using Bloom;

On the Compositor, the color curves and some color operation nodes get flipped. For example, brightening an image is a downwards curve and darkening an image is a upward curve ( due the exponential nature of them ) and, in the color corrector, if you set it to blue you actually tint the image of red or something similar .

Shaders shouldn’t give non-physical output just to work around the fact that texture-preview mode doesn’t have an exposure control. The “flipping” you see in the compositor is a result of having display-referred tools despite only working in scene-referred space. You really should just avoid the nodes that can cause those issues, they’re simply not designed for the way the rest of the compositor works. Keeping this distinction and letting pixels over 1.0 stay as they are is very important for things like Filmic or ACES to work the way they’re supposed to. ESPECIALLY if you’re making footage that’s destined for HDR10/Dolby Vision where a lot of those >1 values still won’t be clipped in the final deliverable.

I could see MAYBE doing this by just a simple gain change (ex, multiply the entire shader output by 0.25 or something) but even that seems unnecessary. And you can do it yourself in the shader if you really want it anyway. The way it works now is the correct way for more modern workflows, it should stay that way IMO.

P.S. thank you for the sun disk size, @nacioss! It’s perfect!