Updated to be compatible with 2.90x and with updated defaults based on recommendations, maintains compatibility with older files.

Apologies for the delay. Life has been a little messy. I am working on updating this to the new versions of Blender right away!

Please use the bug reporting template to report bugs, and provide all the information requested there:
https://developer.blender.org/maniphest/task/edit/form/1/

• Formatting and cosmetic changes
• Make the (not yet unimplemented) Nishita sky white in EEVEE
• Fix the warnings in passing xyz_to_rgb to GPU_uniform

The Cycles side of this looks basically fine, mainly up to @Clément Foucault (fclem) now to check the Eevee side.

• build intern/sky as a library, rename and move sources as required by the module standards
• add SKY_ prefix in public function names and types
• get rid of the warnings in IMB_colormanagement_get_xyz_to_rgb()

• This needs a CMakeLists.txt to create the corresponding library. intern/numaapi is a good example since it's also used by both Blender and Cycles. bf_intern_sky will then needed to be added in intern/cycles/app/CMakeLists.txt and source/blender/nodes/CMakeLists.txt as dependencies.
• Files should be renamed to just sky_*., since util_ makes little sense outside of that Cycles folder.
• The intern/sky folder needs to have separate include and source folders, for the public header files and internal implementation respectively.
• minimal_float3.h should also get a sky_ prefix, and only get used internally and not be part of the public API.
• Public functions names and types can also be changed to all get a SKY_* prefix.

• Reunify 'util_sky_model' for cycles and eevee (reduce code duplication)

In D7108#199586, @Marco (nacioss) wrote:

Hey, congrats for the work you did here

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.

Hi, I would really appreciate this feature, specially to play well with GLTF export pipelines

• Use the XYZ colorspace variant of the Hosek-Wilkie sky

If you want an OpenColorIO config with a different rendering space (and the XYZ role setup) for testing you can find one here: https://github.com/sobotka/ACES-1.2-Displays-Formatted/tree/blender-configuration

I haven't found a way to make blender use anything other than sRGB linear as its internal color format in eevee nodes but if it can really change then sure, let's use IMB_colormanagement.

(in the meantime I was checking if there is a way of to add uniforms in GLSL library functions (so for example, xyz_to_rgb() would only consume the uniform matrix once, even when used by 5 instances of the sky texture) and it seems than the set of builtins (gpu_codegen.c) is not easily extendable(?))

use 'imbuf_xyz_to_rgb' as uniform instead of literal constants

Archiving old task, we decided not to go with this design.

OK, will assume this is fixed then and close.
For the remaining question if this is a candidate for 2.83 LTS, please refer to T77851.
(and of course: for anyone still experiencing this in 2.90, please comment again here, we can always reopen)

I confirm that the problem, in my case, is solved in the most recent 2.90 build.

Thanks for the report, yes environment renderpass should follow cycles.

Since T77851: black and white textures eevee and cycle has been reported again, and that one is resolved in 2.90, could someone check again if this report is still valid in 2.90?

It looks like a bug, but it also seems to be a limitation.
@Clément Foucault (fclem), what do you think?

Would this capability to render 360* make it possible for Eevee to offer screenspace raymarching reflections that can be raymarched in 360* directions? So for example, behind the camera?

@Clément Foucault (fclem) Your commit fixes the slow shader compilation slowdown.

I found a solution to workaround for fading volumetrics in eevee on macOS with Vega. you can easily work this further and combine this with the texture node by smooth minimum combining it. hope this helps someone, since it drove me nuts:

Huh, this seems to be caused by glGetActiveUniformsiv. I don't have a quick test to see if that really is the culprit; but, there is another way to exclude the UBO uniforms which is a bit more involved.

Hi All, I also experience this kind of problem in the point of switching to eevee, will turn all materials to white. I already reported it a few months ago (sorry I don't know how to tag names). I also found a way on how to solve this problem quickly with out making a new blend file. I don't know why this solves the issue for me but it works all the time I get that problem in eevee.