Add portals (set/get variable) to the visual shader editor

[SubtleMetaphor]

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

When working with the Shader Editor (creating shaders visually using nodes) it can become quite tangled or difficult to organize.

Here's an example from Unity's shader editor (which does not support portals/variables), where things have gotten frustratingly entangled:

Describe the feature / enhancement and how it helps to overcome the problem or limitation

One feature that some tools or engines have is the ability to create a "portal" inside the shader editor. Essentially a node for setting a variable, and later getting it at some stage. It is, in a way, similar to the varyings implementation in Godot. However, varyings is a way for the vertex shader to communicate with the fragment shader, and that is not what this is. There may be portals that only exist within the vertex shader, or only within the fragment shader. Using a varying for this is not ideal for a lot of situations where you want higher fidelity (by only using fragment shader), or where you only want the data to exist within the vertex shader.

(Screenshot of a shader made in Amplify Shader Editor for Unity, which does support setting/getting variables.)

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Here's close up shots of portals/variable set/get.

(From this screenshot in Amplify Shader Editor, vertexBitangent is set, and then used in the "line" below it.)

(Here's a screenshot from Unigine's shader editor, which does support portals.)

If this enhancement will not be used often, can it be worked around with a few lines of script?

N/A

Is there a reason why this should be core and not an add-on in the asset library?

N/A

[Chaosus]

Isn't it a duplicate of #7730 ? (same functionality)

[SubtleMetaphor]

Isn't it a duplicate of #7730 ? (same functionality)

No. That suggestion is like defining a function. My request is more like setting a variable and then referencing it.

[tetrapod00]

I've found this feature pretty useful in other engines.

The problem with this is determining the execution order of setters and getters in complex graphs. Visual shaders get "compiled" down to a single text shader that executes in linear order. For simple cases, like a set and a get in one chain of the graph, it's easy enough. But if you set and get a variable multiple times (as you would in a text shader), but across mutliple "branches" of the graph, then you can run into situations where there is no clear execution order.

An obvious solution would be to allow variables to be written to once, and read from multiple times. Then the set is placed as early as possible. But that can still run into illogical or inconsistent setups if you set and get multiple variables, I think.