Eevee: Subsurface radius not affected by nodes plugged into input #58026

New Issue

msalv · 2018-11-24T01:17:08+01:00

msalv commented

2018-11-24 01:17:08 +01:00

System Information
windows 10 64, gtx 1060 6gb

Blender Version
Broken: 7eb9091e96

In Eevee, plugging a vector or rgb input to the "Subsurface Radius" socket of the Principled BSDF node doesn't update the color or radius of the scattering properly, as opposed to leaving the socket empty and typing a radius directly into the node, which works fine. It seems to update based on a greyscale value instead of a color based on each axis of the vector, and it seems to multiply the radius of the socket when it was unplugged, instead of substituting it with it's own

Maybe related, if instead of Principled BSDF you use a Subsurface Scattering shader, something similar happens, except the radius doesn't update at all.

(left: bug, right: correct)

Exact steps for others to reproduce the error

Open the blend file and play the animation, or change directly the values of the subsurface radius in either material.
subsurfacebug.blend

**System Information** windows 10 64, gtx 1060 6gb **Blender Version** Broken: 7eb9091e96f In Eevee, plugging a vector or rgb input to the "Subsurface Radius" socket of the Principled BSDF node doesn't update the color or radius of the scattering properly, as opposed to leaving the socket empty and typing a radius directly into the node, which works fine. It seems to update based on a greyscale value instead of a color based on each axis of the vector, and it seems to multiply the radius of the socket when it was unplugged, instead of substituting it with it's own Maybe related, if instead of Principled BSDF you use a Subsurface Scattering shader, something similar happens, except the radius doesn't update at all. ![ezgif-1-4f983ad3be31.gif](https://archive.blender.org/developer/F5698453/ezgif-1-4f983ad3be31.gif) (left: bug, right: correct) **Exact steps for others to reproduce the error** Open the blend file and play the animation, or change directly the values of the subsurface radius in either material. [subsurfacebug.blend](https://archive.blender.org/developer/F5698500/subsurfacebug.blend)

msalv commented

2018-11-24 01:17:08 +01:00

Added subscriber: @moisessalvador

Brecht Van Lommel commented

2018-11-24 22:50:31 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2018-11-24 22:50:31 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2018-11-24 22:50:31 +01:00

Brecht Van Lommel self-assigned this 2018-11-24 22:50:31 +01:00

Brecht Van Lommel commented

2018-11-24 22:50:31 +01:00

It's a documented limitation currently:
https://docs.blender.org/manual/en/dev/render/eevee/materials/nodes_support.html

What is and is not supported could be better communicated in the UI, but for now it's not considered a bug.

It's a documented limitation currently: https://docs.blender.org/manual/en/dev/render/eevee/materials/nodes_support.html What is and is not supported could be better communicated in the UI, but for now it's not considered a bug.

msalv commented

2018-11-25 00:45:46 +01:00

Aw that's a shame. Even without texture support, it would be nice to have this work with single colors, otherwise it forces me to duplicate and make unique nodegroups to change the color inside of each

Brecht Van Lommel commented

2018-11-25 01:00:37 +01:00

Added subscriber: @fclem

Brecht Van Lommel commented

2018-11-25 01:00:37 +01:00

Ideally node groups would still work. @fclem, would that be considered a known limitation or bug?

Clément Foucault commented

2018-11-25 01:11:39 +01:00

Well this is a limitation. The radii need to be constants in order to pre-compute the kernel weights.

The only way to support nodegroup / non textured input would be to make the SSS nodes search/evaluate upstream nodes when generating GPU shader which is really not trivial. Also that would make it very non-intuitive because it would work for a really small set of cases and not others.

Well this is a limitation. The radii need to be constants in order to pre-compute the kernel weights. The only way to support nodegroup / non textured input would be to make the SSS nodes search/evaluate upstream nodes when generating GPU shader which is really not trivial. Also that would make it very non-intuitive because it would work for a really small set of cases and not others.

msalv commented

2018-11-25 11:43:11 +01:00

It could still be limited to just the most immediate node plugged to it, with that node having a constant to fallback if something else were to be plugged to it in return, not evaluating further. Another way of handling it is like unreal engine does, where the scattering is it's own data type that can't do operations with the regular vector3's, that would make the socket another color and nothing else but that data type could be plugged into it

michael campbell commented

2021-04-13 17:32:10 +02:00

Added subscriber: @3di

michael campbell commented

2021-04-13 17:32:10 +02:00

@fclem The radius vector appears to be user editable rather than being a constant. I'm not sure why it would matter if the value is changed on the node or passed in via the socket.