Ambient occlusion not working inside visual shader sampler2D

[mddm1]

Ambient occlusion not working inside visual shader sampler2D

[clayjohn]

Could you please upload an MRP to make this easier for contributors to troubleshoot?

An MRP is a project that is as small as can be while still reproducing the bug you are reporting. We include the MRP in the bug reporting template as including one greatly increases the chance that a contributor will be able to reproduce the bug you reported and be able to fix it.

[Chaosus]

Ah, seems like a similar problem was fixed for varying recently (#93205) - AO is built-in, and texture name should not overwrite it, I will fix this.

[mddm1]

I don't know what this means but this is the output error

E 9-> uniform sampler2D AO : hint_default_black;

All the shader bindings for the given set must be covered by the uniforms provided. Binding (0), set (3) was not provided.
drivers/vulkan/rendering_device_vulkan.cpp:5912 - Parameter "us" is null.

[mddm1]

@clayjohn I uploaded an MRP.

[Chaosus]

Oh, the fix for this is not a trivial, because if we add a prefix to the parameter it will break a lot of user code such as expressions, uniform names, custom shaders etc. I think it's too dangerous and may not worth at all. @clayjohn what do you think?

[clayjohn]

Oh, the fix for this is not a trivial, because if we add a prefix to the parameter it will break a lot of user code such as expressions, uniform names, custom shaders etc. I think it's too dangerous and may not worth at all. @clayjohn what do you think?

Can't we do what the textual shader compiler does and add the same prefix to all user variables (including those in expression nodes)? Or do we not do any parsing of expression nodes?

If we can't do something to make any name work, then we should add an error when a user tries to name an input the same as an existing built in.

[Chaosus]

Can't we do what the textual shader compiler does and add the same prefix to all user variables (including those in expression nodes)? Or do we not do any parsing of expression nodes?

This is a necessary measure for input ports, scaling it to built-in parameters may be cumbersome... Anyway, it will break compatibility with the uniform names, so the user code in set_shader_parameter will need to be changed if the user accesses the shader through code.

If we can't do something to make any name work, then we should add an error when a user tries to name an input the same as an existing built in.

I guess that only thing we can do with this.