Please try the latest official Blender 2.83.5
https://www.blender.org/

Your is a feature request, not a bug.
You can join the conversation here if you want https://devtalk.blender.org/t/new-sky-texture/12708

Before, the period you are talking about, the sky intensity was messed up because of some internal hacks. Now it follows physically based units, so if you don't have physically based lighting in your scene then you better have to update it, otherwise just decrease the Strength of the Background Node on which the Sky Texture Node is connected.

Known limitation for now. But the other 2 models work.

It's not broken, this is how it works.
The new Nishita sky texture has now physically based RGB values, meaning you are getting proper sky intensity from the environment. If you want to downexpose the scene then just use the Exposure value under the Color Management section in the Render settings.

Yes i can reproduce it

Can't reproduce with RTX 2080ti.
Please try to update the Nvidia drivers of the GPU to the latest (your drivers seem outdated) and try again.

Closing as a week has already passed without any updates.

Please attach the blend file here, and try with the latest 2.83.3 official release and maybe give a try with the latest 2.90 Beta build here https://builder.blender.org/download/

Please try the latest 2.90 Beta build to see if the issue has been already solved here https://builder.blender.org/download/

What Blender version are you experiencing the issue on?
Try the latest 2.83.3 official release https://www.blender.org/
Or try the latest build here https://builder.blender.org/download/
Also please give us information about what AMD Radeon GPU model you are using.

Can't reproduce on Blender 2.83.3 official.

Please give more information about the issue, and if possible write in English here.

I can reproduce, @Clément Foucault (fclem) maybe for you.

Update the Nvidia GPU drivers to the latest and try again:
https://www.nvidia.com/Download/index.aspx

Closing as it's a known limitation of the implemented model, checked the code and it doesn't seem to have issues at all, the code is equal to the official Hosek/Wilkie code.
And on top of that, the ground is not meant to be accurate at all.
Maybe @Thomas Dinges (dingto) can say something since he implemented it.

@pratik solanki (dragoneex) This is for you

This is not a bug.
The Sun lamp Strength value is in W / m^2 (irradiance) and so to "match" the sky texture sun values you should put values between 500 and 900 in the Strength.

Please attach all the required hardware information along with a step by step description of how to reproduce the issue, blender version used and maybe a blend file.

• Optimize surface intersection function and cleanup comments

Yes it's a bug, thank you for reporting.
@Lukas Stockner (lukasstockner97) could it be related to the sampling part?

• Better comments

Can't reproduce either, and very probably it has been already fixed by https://developer.blender.org/rB7fcb6bc59c85beab36dbfcec91d0cfaf5291f029

Yes it's a known limitation of SSR, it reflects some pixels based on what is already on screen rather than doing raytracing like Cycles does.

Fixed by https://developer.blender.org/rB6a3c91f7adc8005fc19c58a4e8a219ae22eab4c0

Well, the Nishita sky model is still missing to be implemented in Eevee.

Please provide here the HDRI file you are trying to import.

Please share the files with the issue, otherwise it's hard to test.

It happens only in Multiscatter GGX though, not with GGX selected.

Closing as i'm not developing the add-on anymore.

Do you mean Blender is quitting as soon as you click on the "UV Editing" workspace on the top?
I can't reproduce, so try this thing: download the latest build from today, Load Factory Settings and then try again.

• Rebase master changes (due to https://developer.blender.org/rB9de09220fc5fcae72bba203c641f67e75eb7ebc5)
• Format code style

There is already a patch for Eevee to port the Sky models from Cycles here https://developer.blender.org/D7108
I think this patch review can be closed.

Hey, congrats for the work you did here, i'm the Nishita Sky guy and would like to talk with you about porting the model in Eevee, do you have an email or something so i can contact you? Otherwise here's my email wolf.art3d@gmail.com
Anyway as said by Clement, the porting of Nishita should be a different patch.

• Show Vector input if Sun Disc is unchecked

This choice is made because when the sun component is disabled there is no reason to keep the Vector socket hidden

I would prefer to maintain this patch full of all the changes as i don't have commits access yet, probably in the future will make separate fixes as it should be, but again i need commit rights for that.
Said that, i'm not sure how to do the Altitude bump.
Also there is this bug that needs to be fixed: https://developer.blender.org/T78324

• Cleanup: Lukas changes

Ok, i can reproduce it now, it does only with CUDA + CPU, will dig in the code soon, thank you a lot for the report ;) .
Meanwhile, avoid using such low Sun Size values.
EDIT: Using values from 0.4 to above works well

Does it happen with other scenes too? i mean, try without the sky, if the issue persists then the problem could be related to GPU rathen than the sky.

Can't reproduce the issue, try to update the Nvidia drivers, do you get any issues with CPU rendering?

• code cleanup
• remove Vector input from the UI
• fix: old files saved with older sky methods got 0 as parameters for Nishita

There are couple of things I'm missing here.

First is the atomic nature of changes. If changes are not dependent on each other they should happen in separate commits. This helps on multiple levels:

• Review becomes way easier and faster
• Helps with presentation to users
• Helps finding source of possible regression more easily

Please can you attach the blend file here? I would like to give a look at the issue.

missed to update the OSL part

In the next commit i'm going to fix it, for now a temporary solution is to set the Altitude to 1.
The issue is produced by the fact that at Altitude 0 the ray between the camera and the sky could be intersecting with the Earth surface, and so producing math issues.

@Brecht Van Lommel (brecht) waiting for your review

I don't get the same issues but i get a weird behaviour when changing the resolution %.
At first i got a completely black plane and no particles or whatever, then i got the particles only, then it rendered the whole smoke

Could it be because you used an Octane for Blender add-on or build and saved the file with it?

Do you have a file with the issue or is it happening with the default scene? If not then could you please try to Load Factory Settings to see if it fixes it?

I can confirm the issue on WIndows 10 with RTX 2080ti

You are right, i can confirm on both 2.83 and 2.90

I confirm on Windows 10 with RTX 2080ti.
Opening the file in 2.83 works, in 2.90 it seems buggy

Please could you provide the notepad file you are talking about?