Fix #104219: Node links are sometimes created from the wrong socket #104420

Closed
Hans Goudey wants to merge 5 commits from HooglyBoogly:fix-node-editor-sort-socket-locations into blender-v3.5-release

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.

5 Commits

Author SHA1 Message Date
Hans Goudey 132aaff965 Add comment about coordinate space 2023-02-28 11:14:22 -05:00
Hans Goudey f37e71fade Merge branch 'blender-v3.5-release' into fix-node-editor-sort-socket-locations 2023-02-28 08:32:27 -05:00
Hans Goudey 4bcda9cc2d Fix #104219: Node links created from wrong socket after selection
Nodes are sorted based on the selection. In some cases (even depending
on processor speed, nodes can be selected and reordered, and another
operation can run before the next redraw). That gives a window where
operators mapped to the same input as selection can run with invalid
socket locations (which aren't updated after the nodes are reordered,
since they are stored in a separate array).

To fix this, move the socket locations from the node editor runtime
data to the node tree, tag them as invalid when the nodes are
reordere, and check for that status in a few more places.

A better longer term solution is not reordering nodes based on
UI status and instead storing the UI drawing order separately.
2023-02-27 18:14:10 -05:00
Hans Goudey d629dd98ec Revert "Fix #104219: Node links are sometimes created from the wrong socket"
This reverts commit ae4c5a493c.
2023-02-27 18:09:18 -05:00
Hans Goudey ae4c5a493c Fix #104219: Node links are sometimes created from the wrong socket
For reasons described in more depth in the new code comment,
reordering nodes can sometimes invalidate the socket locations
in a way that makes random connections after a node is selected.

A better change would probably be to stop reordering nodes and
store their "UI order" separately instead, but that's more involved.
On its own, storing socket locations in a SoA format probably isn't
worth this complexity, but I think it's useful to have something like
this working so more data can be stored this way in the future.

I think the reproduce-ability of this bug depends on Blender's
performance, since I had a much easier time recreating it in a
debug build with a bunch of extra nodes added to the file.
2023-02-07 13:14:19 -05:00