-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
[VisualShader] Add reroute node and improve port drawing #90534
Conversation
Is this only valid for Visual Shaders is it a feature common to all graph nodes? Like should this be in the base class or in visual shaders. |
@fire Currently just for visual shader. This is rather simple to implement (the UI part) on the user side , so I don't think it's a good idea to expose it as a general node. Also, keeping it unexposed allows this to be merged sooner. Edit: I might have misunderstood you. I think both VSGraphNode and VSRerouteNode could be renamed to EditorGraphNode/EditorGraphRerouteNode, moved to their own file and used in the other graph editors (e.g. animation blend tree), without exposing them. But I think that can be done in a subsequent PR. |
This is a really good change! Great work on this @Geometror! I have a nitpick about the UX about the implementation: It would be quite cumbersome to add Reroute nodes how you show in the gif after a user wants to clean up a very complex graph. It would be great to reduce the friction to add a Reroute node inbetween a connection of two other nodes by e.g. double-clicking. That would be at least my view if I would use it later. |
Can this be Godot Built-in Node(rename VSRerouteNode to GraphRerouteNode)? IMO, most user who use GraphEdit&GraphNode need this node(include myself). |
If not double click it should at least be in the first context dialog (alongside Disconnect and Insert New Node) I agree this looks great! |
@CsloudX I see your point, but to be honest for now I don't think this makes a lot of sense. Implementing this exact reroute node in GDScript (VSRerouteNode) is literally 40 lines of code with the benefit of full flexibility; the much more sophisticated part is integrating it in your editor. This was even possible before with restrictions that would have required some workarounds, but that shouldn't be the case anymore with this PR. |
140352c
to
1c40beb
Compare
7a3528f
to
66f7fa7
Compare
Update:
vsr_demo1.mp4vsr_demo2.mp4
vsr_demo3.mp4 |
d468bb5
to
f3103ff
Compare
That seems fair enough. Having the option to add this node via Right-click menu is already easier then typing it into the |
f3103ff
to
83e8461
Compare
a46148c
to
aecf430
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally, it mostly works as expected. The main issue I noticed is that if you leave a reroute port connected with no input, it'll result in what I assume is an infinite or NaN value:
Testing project: test_vs_reroute.zip
Also, it might be worth speeding up the fade animation for the move icon that appears when you hover above the point's hotspot.
@Calinou Thanks for testing! I changed the animation duration to 0.3s. |
aecf430
to
a6532b9
Compare
If 2 reroutes are very close, the input will be wrongly picked by the port behind handle. godot.windows.editor.dev.x86_64_uLd8LWTkHU.mp4New reroute connection will always go right, even if connected to a node to the left. hVOvJL2exG.mp4And likely related to the above, you can't connect reroute to output port: godot.windows.editor.dev.x86_64_S0DpzD0dcQ.mp4Though I assume the above 2 are a limitation. EDIT: godot.windows.editor.dev.x86_64_KfEo9cAxJl.mp4 |
This is a limitation of GraphEdit and quite hard to fix. You'd need to move the top one first. But I doubt you will ever have two reroute nodes directly below each other.
This is technically also a limitation, but actually how the workflow was designed and consistent with other graph editors. Reroute nodes are expected to be connected from left to right.
Also a minor limitation, but also how it was designed to work (dangling/unconnected reroute chains are only an intermediate state). When you actually connect it to a valid output port of a normal node, the types of all reroute nodes are adjusted. |
23084f2
to
70120a6
Compare
Addressed all review comments and rebased. |
LGTM! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thank you for this work!
70120a6
to
6277684
Compare
Thanks! |
Bug, but seems already fixed in 4.4. |
Detailed changes:
TODO:
- [ ] Find a way to fade in the move handle when the mouse is above the port hotzone (might be hard to do)