Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redesign the graph editor for visual shaders #85017

Merged
merged 1 commit into from
Feb 22, 2024

Conversation

Geometror
Copy link
Member

@Geometror Geometror commented Nov 17, 2023

grafik

Depends on #83785. (merged)
Depends on #86158. (merged)
Although it does not depend on #83510, it would make sense to merge that PR first. (merged)

This PR aims to improve the VisualShader workflow especially when working with complex graphs where it's important that you're able

to quickly parse the graph and get an overview about what each part does (at least roughly). As color is a very powerful instrument to guide your eyes and aid with comprehension of complex structures, we need to carefully apply it.

Comparisons

Comparison using a complex node graph (thanks to @TheRensei for the shader which was very useful for testing/iterating):

Current:
godot windows editor dev x86_64_lXxlqxNNZK

This PR:
jJVZVN8tEr

Detailed changes

  • Use dotted grid pattern by default
  • Refreshed VisualShader node design
    • Adjust margins to gain some "space to breathe"
    • Add dropshadow to text for better contrast/readability
  • Color VisualShader nodes (header/titlebar) by category. Implements Color VisualShader nodes by category godot-proposals#7745.
    • Category colors do not match exactly with the top ones in the "Add node" dialog since those sometimes aren't well suited for coloring the graph in a sensible manner. For certain nodes it might make sense to move them in the dialog as well.
      • e.g. inputs, parameters and constants all have the same color
      • e.g. VaryingGetter is colored like other input nodes and VaryingSetter is colored like the output node despite the fact that both nodes can be found in the "Special" category in the "Add node" dialog (tbh I would move them in the dialog too)
      • no common category (only contained DerivateFunc which is colored like the utility nodes)
  • Rework the connection type colors to improve the clarity of large graphs (and to match Blender where it's possible/reasonable, lowers "readjustment overhead" between Godot and Blender)
  • Category and connection colors can be customized via editor settings
    • Default and Legacy (old connections colors + no distinct colors for categories) theme presets
    • Custom color theme allows setting each color manually
      Pasted image 20231117150123
  • Optimization: Fix creating a new MSDF font theme for every node
  • Set the minimum width of a graph node based on the preview size to avoid a resize when toggling the review

Since this is huge change we need to make sure that everything fits, so feel free to give it a try and let me know what you think and what could be improved. There are still some things to be discussed such as the color of Vector3/4 connections (maybe having two colors for Vector3, one for color related nodes and the other one for general vector nodes).

Thanks to everyone who gave such nice and valuable feedback during GodotCon.

Production edit: closes godotengine/godot-roadmap#12

@Calinou
Copy link
Member

Calinou commented Nov 17, 2023

This looks great! I wonder if the margin headings could be reduced though, as they look massive at the default zoom level currently (they take half the space in single-property nodes).

I understand this was done to make heading colors visible at low zoom levels, but maybe a different approach can be used to highlight these at low zoom levels instead.

@YuriSizov YuriSizov changed the title VisualShader UI redesign Redesign the graph editor for visual shaders Nov 17, 2023
@Smaloki
Copy link

Smaloki commented Nov 17, 2023

I understand this was done to make heading colors visible at low zoom levels, but maybe a different approach can be used to highlight these at low zoom levels instead.

Maybe at a certain point while zooming out, the header colour could simply be extended to the entire node?

With a sufficiently low zoom factor, the text stops being readable anyway. At that point, the nodes might as well be represented by coloured rectangles. An instant switch without transition might be a little sudden though.

@aaronfranke
Copy link
Member

I see that this PR changes the colors for various types. The type colors should be kept in sync with the icon colors, so I would suggest either changing both or neither.

@Geometror
Copy link
Member Author

Geometror commented Dec 22, 2023

Rebased. The connection rim was split from this PR and is now part of #86158 (which this PR depends on).
Also I changed some of the type icon colors (a few are still missing), although I'm not so confident about this since the type icons are used outside of the VS domain at various places in the editor (I think), which makes this a more extensive change than I'd like it to be.

@Geometror
Copy link
Member Author

Rebased and added a new category and color for particle nodes:
Pasted image 20240209141820
This should be ready to review now :)

@aaronfranke
I started changing the colors of the icons but then I realized that these icons are used all over the engine. Since the connection colors here can be changed (and are part of the VS theme) this didn't make much sense to me. I'd suggest we decide on this later and change them in a followup PR (IMO those icons need an overhaul anyway :)).

@Geometror Geometror marked this pull request as ready for review February 9, 2024 14:13
@Geometror Geometror requested review from a team as code owners February 9, 2024 14:13
@Geometror
Copy link
Member Author

@Calinou The header heights are that big for another reason: More space for selecting/grabbing the nodes. Especially at high zoom levels (but not exclusively) this improves the flow since you don't need such a high click accuracy - reducing missclicks. Changing the height dynamically depending on the zoom levels might prove quite difficult and could cause all sorts of problems, so I'd rather not do this. (unfortunately I don't have any other ideas to highlight them at low zoom levels)
However, we could add an editor setting for the height I guess.

@Calinou
Copy link
Member

Calinou commented Feb 9, 2024

I guess it makes sense to keep the heading heights this way then.

@aaronfranke
Copy link
Member

aaronfranke commented Feb 10, 2024

@Geometror In that case I would suggest using the old colors, so that the colors stay in sync until such an icon redesign overhaul can be completed.

Also, to comment on one of the colors in your redesign specifically: I'm not a fan of using white or light-gray lines for data. In visual scripting languages, the color white is used for sequencing, including in Godot 3's VisualScript, Unreal Blueprints, The Mirror's visual scripting, and more. I would prefer to avoid inconsistency between visual scripts and visual shaders by ensuring that all data types are using a non-white color.

@Geometror
Copy link
Member Author

Geometror commented Feb 10, 2024

@aaronfranke Well, changing the connection colors is an integral part of this redesign, I tried the new header colors together with the old connection colors and it looked horrible. For example, for scalar values it's gray which isn't a saturated color on purpose since scalar connections are the most common type and therefore prevalent in most shader graphs. Having those colored (especially in the cyan used before) makes the graph way too colorful and hurts readability (since it interferes with the header colors). You're right, the color white is often used in scripting languages for control flow/sequencing, but on the other side, it is also used for data (or specifically scalar types) in Blender, Material Maker and the the Unreal material editor (Unity uses colors, but very desaturated). As this redesign is primarily inspired by Blender (to reduce fricition/cognitive overhead) I went with gray.
VisualScript is not part of the engine anymore, I don't think we should strive for consistency with something that's not even there (and has a different purpose), but rather go for consistency with equivalent tooling.
Plus, we could still use white for control flow in Visual Scripting (extension) since it's way brighter than this gray.

Copy link
Member

@Calinou Calinou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested locally (rebased on top of master fb10e67), it works as expected. It looks great 🙂

One issue I noticed is that if you use the Black (OLED) editor theme preset, unselected nodes will blend with the background:

image

To combat this, there is a Draw Extra Borders editor setting that is automatically enabled when choosing this theme preset. When this setting is enabled, I suggest adding a gray 1-pixel border around unselected GraphNodes like we do on LineEdit, for instance.

@Geometror
Copy link
Member Author

@Calinou While adjusting the theme for the OLED preset, I realized that the contrast of the node borders is generally pretty low. So I played a bit with it:

image

What do you think?

(I took the following two screenshots before adjusting the port offset)
Here's how it looks like with the OLED preset now:
image
And the white theme was a bit broken since the dark font color doesn't work well with the header colors (which were choosen in a way that works for both light and dark themes), so I fixed that as well:
image

@Geometror
Copy link
Member Author

While at it, I improved the visibility of selected nodes. This was pretty bad at low zoom levels before.

image

image

@Geometror Geometror force-pushed the vs-redesign branch 2 times, most recently from f62003b to 9ba9274 Compare February 21, 2024 20:01
@akien-mga akien-mga merged commit 213c835 into godotengine:master Feb 22, 2024
16 checks passed
@akien-mga
Copy link
Member

Thanks!

@Jeangowhy
Copy link

Well done!

@MangoDragonHub
Copy link

I don't know if this is in the new version but does this new version of the node system support comment grouping for chunks of nodes? It's just an organization thing. For example, you highlight a group of nodes for one part of the script and press a shortcut key (C), that puts that section in a comment bubble. Its easier to see what part of the shader is doing what.

@Mickeon
Copy link
Contributor

Mickeon commented Mar 5, 2024

Do you mean something like this #88014 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

9 participants