Enhance VisualShader UX/UI

[jcandres]

Describe the project you are working on

VFX demo reel.

Describe the problem or limitation you are having in your project

VisualShaders are a powerful, intuitive tool but the workflow could improve a lot. I've collected a list of problems I've found, mostly related to space and navigation problems. A lot of them are small issues that build into each other so I'm including them in a single proposal since they are related.

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

Space / organization problems:

• An organization tool to group and label nodes is much needed. Similar solutions have been proposed for visual scripting:
  

• There is no preview viewport, so the VisualShader editor and the main editor viewport compete for screen space.

• The new "minimap" works against the workflow. It takes up screen space and its low resolution makes for a subpar navigation tool.
  My proposed solution for these two problems is repurposing the minimap as a preview tool that would work as a scene camera, or simply using the existing editor view in preview/cinematic mode.
  
  (Sorry for the typo)

• Node ports have unintuitive snapping. This takes up space and is error prone. Currently their active area has a zero-pixel vertical margin, and the horizontal offset is awkward and forces nodes to keep a "safety distance" to prevent errors.
  

• Custom nodes return their port values to their defaults after restarting Godot, without warning (!). This means you could work for hours then suffer silent data loss. The only way to prevent this is plugging a uniform or constant node into the port. Custom nodes look and behave like built in nodes, so it's expected that they keep the manually edited data.
  

• Node connections are too "soft" and wobbly. This may sound superfluous, but they make connections a lot harder to read.
  This is a very crude mockup, but I hope it serves to illustrate how much readable it becomes when using straight lines:
  
  A more ideal solution would be to simply sharpen the connector's curves: https://user-images.githubusercontent.com/6877923/83576832-f2486500-a532-11ea-9d2a-a6b75b980813.png

Usability problems:

• It's missing a few higher-level nodes, in particular UV manipulation, particle system imput. This means (A) you must create manually a bunch of nodes for each new shader, very tedious and takes up much needed space (B) you must create a script for a custom node, but that has some problems exposed below.
  I feel like these are the most needed nodes:
  • A UV panning/scrolling node. UV + speed_vec3 * TIME.
  • A UV scaling node. (UV - pivot_origin_vec3) * scale_factor_vec3 + pivot_origin_vec3
  • A particle input node, ideally a vec4 passing INSTANCE_CUSTOM. Accessible from both vertex and fragment; currently it's acccessible from a expression node in the vertex shader section. INSTANCE_CUSTOM is too useful not to use.
  • A random value generator. Right now the way to do this is creating a script that passes a random value into the shader, but that's not possible for particles, and a messy solution otherwise.
• Dragging and dropping an texture into the visualshader creates a Texture function. This means the easiest way to include a texture is the less optimal, since a Texture node doesn't have a sampler port for reusing it, and is created with a procedural name that can't be changed. It would be much better if the default was a TextureUniform node.

Godot 4 specific problems. It may be a bit early but I want to point out a few issues I've found:

• In Godot 4, editing Materials doesn't use an exclusive view in the inspector, making the process overwhelming and extremelly confusing. For example when editing a particle material, the inspector holds data for the particle-system, the particle-material, the particle-draw-pass, and the material of the draw-pass, all at once. And if you scroll a bit further down the inspector you get more fields for the particle-system (transform, matrix, etc). Even with color coding this is way too confusing and disorganized. The current "modal" edition works great and keeps organization crystal clear.
• In Godot 4, uniform nodes take up way too much screen space, specially floats - the most commonly used uniform type. A solution would be making nodes collapsable, or at least hiding secondary options under a popup.
  
• In Godot 4, right click opens up a contextual menu anytime there's a node selected. Not sure if this is a bug, but this breaks the workflow. Ideally right click should be used for adding nodes, and the copy-pasting menu restricted to clicks made on selected nodes.

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

See above.

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

I can't see how. The exception would be the proposed nodes for UV panning/scaling. Those could be scripted, but custom nodes have some problems and creating them isn't as easy as normal scripts, since their errors are handled in a different way.

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

Visual Shaders are the easiest and most intuitive way to create visual effects, and anyone using them would benefit from this changes. Some of the changes are already implemented, they simply need to be more accessible to users (ex. exposing INSTANCE_CUSTOM).

[YuriSizov]

Please, open individual proposals for the issues specified. Most of them can be discussed at length on their own and it would be a clutter to discuss it all here. Some of the described issues already have proposals, I believe, while others can be reported as bugs.

[Calinou]

There is no preview viewport, so the VisualShader editor and the main editor viewport compete for screen space.

See godotengine/godot#45165, which was ultimately scrapped.

[Chaosus]

I give an opinion:

An organization tool to group and label nodes is much needed. Similar solutions have been proposed for visual scripting:

Comment node already was added to 4.0 branch. Maybe I should backport it for 3.4...

There is no preview viewport, so the VisualShader editor and the main editor viewport compete for screen space.

Well, you have that preview in the inspector:

Maybe in the future version, we will add a separate preview window to the visual shader. I think it's a minor priority issue for now.

The new "minimap" works against the workflow. It takes up screen space and its low resolution makes for a subpar navigation tool.
My proposed solution for these two problems is repurposing the minimap as a preview tool that would work as a scene camera, or simply using the existing editor view in preview/cinematic mode.

It's a subjective point of view. The minimap works as intended, if you don't need it you can disable it (and users likes it if you look at the original issue godotengine/godot#43416). No need to touch it and destroy the @pycbouh work, we can add a button for the preview tool separately.

Node ports have unintuitive snapping. This takes up space and is error prone. Currently their active area has a zero-pixel vertical margin, and the horizontal offset is awkward and forces nodes to keep a "safety distance" to prevent errors.

GraphEdit issue, related to visual shaders indirectly.

Node connections are too "soft" and wobbly. This may sound superfluous, but they make connections a lot harder to read.
This is a very crude mockup, but I hope it serves to illustrate how much readable it becomes when using straight lines:

GraphEdit issue, related to visual shaders indirectly.

Custom nodes return their port values to their defaults after restarting Godot, without warning (!). This means you could work for hours then suffer silent data loss. The only way to prevent this is plugging a uniform or constant node into the port. Custom nodes look and behave like built in nodes, so it's expected that they keep the manually edited data.

Check again. This should be fixed by godotengine/godot#47827 (it's cherry-picked to 3.3.x branches).

It's missing a few higher-level nodes, in particular UV manipulation, particle system imput. This means (A) you must create manually a bunch of nodes for each new shader, very tedious and takes up much needed space (B) you must create a script for a custom node, but that has some problems exposed below.
I feel like these are the most needed nodes:
A UV panning/scrolling node. UV + speed_vec3 * TIME.
A UV scaling node. (UV - pivot_origin_vec3) * scale_factor_vec3 + pivot_origin_vec3

Devs mostly + @reduz (creator of the Godot) are against a bunch of high-level functions since they bloat the engine - you can create them by using VisualShaderNodeCustom mechanic or use external plug-ins: like https://github.com/arkology/ShaderV (exist in AssetLib) or https://github.com/Maujoe/Godot-Visual-Shader-Node-Library. You can propose your functions to them or create your own library. You can also use an Expression node to easily do such manipulations.

A random value generator. Right now the way to do this is creating a script that passes a random value into the shader, but that's not possible for particles, and a messy solution otherwise.

Particles are separate history and as part of godotengine/godot#42248, I've planning to add a simple random generator.

In Godot 4, uniform nodes take up way too much screen space, specially floats - the most commonly used uniform type. A solution would be making nodes collapsable, or at least hiding secondary options under a popup.

Yeah, that's a reasonable point to change. But please, report as a separate issue in order to comfortability to close it (when fixed of course).

In Godot 4, right click opens up a contextual menu anytime there's a node selected. Not sure if this is a bug, but this breaks the workflow. Ideally right click should be used for adding nodes, and the copy-pasting menu restricted to clicks made on selected nodes.

Please, report as a separate issue.

[jcandres]

I will open different issues as suggested. Sorry for the mess, I didn't want to spam with lots of small yet related issues.

@Chaosus Thanks for the lengthy reply.

An organization tool to group and label nodes is much needed. Similar solutions have been proposed for visual scripting:

Comment node already was added to 4.0 branch. Maybe I should backport it for 3.4...

That would be awesome. Right now editing complex (or simply large) shaders is a nightmare unless you are super organized.

There is no preview viewport, so the VisualShader editor and the main editor viewport compete for screen space.

Well, you have that preview in the inspector:
Maybe in the future version, we will add a separate preview window to the visual shader. I think it's a minor priority issue for now.

I see. The problem with the "matcap preview" is that it doesn't really help when dealing with complex meshes, and it displays the matcap with the seam looking towards the camera -- very helpful to detect tiling errors on a solid material but useless for other type of materials, for example billboards with transparent edges.

Custom nodes return their port values to their defaults after restarting Godot, without warning (!). This means you could work for hours then suffer silent data loss. The only way to prevent this is plugging a uniform or constant node into the port. Custom nodes look and behave like built in nodes, so it's expected that they keep the manually edited data.

Check again. This should be fixed by godotengine/godot#47827 (it's cherry-picked to 3.3.x branches).

Double-checked and it's still happening. I'm using 3.3.stable.

It's missing a few higher-level nodes, in particular UV manipulation, particle system imput. This means (A) you must create manually a bunch of nodes for each new shader, very tedious and takes up much needed space (B) you must create a script for a custom node, but that has some problems exposed below.
I feel like these are the most needed nodes:
A UV panning/scrolling node. UV + speed_vec3 * TIME.
A UV scaling node. (UV - pivot_origin_vec3) * scale_factor_vec3 + pivot_origin_vec3

Devs mostly + @reduz (creator of the Godot) are against a bunch of high-level functions since they bloat the engine - you can create them by using VisualShaderNodeCustom mechanic or use external plug-ins: like https://github.com/arkology/ShaderV (exist in AssetLib) or https://github.com/Maujoe/Godot-Visual-Shader-Node-Library. You can propose your functions to them or create your own library. You can also use an Expression node to easily do such manipulations.

I'm totally in favor of reducing bloat. In fact I believe there's already too many nodes, specially since Godot 4 introduces typed uniforms. In particular I believe VisualShaderNodeColorOp nodes should be cut, specially since some are redundant (basic math operations like min, max, abs... that have already their own node).
I proposed those two UV manipulation nodes in particular because they are a fundamental tool, used frequently, and are hard to create (for example, the ShaderV equivalent nodes are buggy).
I didn't know about Maujoe's project, thanks for the recommendation.

A random value generator. Right now the way to do this is creating a script that passes a random value into the shader, but that's not possible for particles, and a messy solution otherwise.

Particles are separate history and as part of godotengine/godot#42248, I've planning to add a simple random generator.

Thank you so much :)

[Chaosus]

Double-checked and it's still happening. I'm using 3.3.stable.

This should be fixed in 3.3.1

[fire]

Having this issue split would help me and ensure each bit is resolvable on its own. I can comment on the magnetic feature of the node input ports. However it’s hard to give each proposal its proper attention merged together.

[QbieShay]

Can you re-assess this proposal on 4.0 RC2?

[Calinou]

Closing per QbieShay's comment. Please check whether the reported issues are still valid in 4.2.dev5 or later, or continue the discussion in #7860.