7e8fd2cc2c
EEVEE-Next can only store data for a single (global) closure at a time, which, when combined with ShaderToRGB nodes, requires extra care in the order that closures are evaluated. For example:  Here, after `ntree_shader_shader_to_rgba_branch` there will be 2 Diffuse nodes (the original and a copy for the ShaderToRGB branch). However, the generated code order will be something like this: ``` Diffuse (original) Diffuse (copy) ShaderToRGB // This resets closures Mix ``` So while the original node is technically "evaluated", the closure data is reset after ShaderToRGB. This patch updates the code generation to ensure closure evaluation is ordered taking ShaderToRGB branches into account, so the generated code looks like this: ``` Diffuse (copy) ShaderToRGB // This resets closures Diffuse (original) Mix ``` This also fixes ShaderToRGB support for AOVs, removes unused code, and fixes several bugs that I've found along the way that were harmless for EEVEE but broke EEVEE Next. Pull Request: https://projects.blender.org/blender/blender/pulls/117767
Blender
Blender is the free and open source 3D creation suite. It supports the entirety of the 3D pipeline-modeling, rigging, animation, simulation, rendering, compositing, motion tracking and video editing.
Project Pages
Development
License
Blender as a whole is licensed under the GNU General Public License, Version 3. Individual files may have a different, but compatible license.
See blender.org/about/license for details.