Changing UI resolution scale messes up nodes snapping #109572

New Issue

Closed

opened 2023-07-01 00:14:35 +02:00 by fwfeet · 17 comments

fwfeet commented

2023-07-01 00:14:35 +02:00

System Information
Operating system: Windows-10-10.0.25393-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 536.23

Blender Version
Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-06-30 00:04, hash: e73a9a6a7d7b
Worked: Never AFAIK

Short description of error
When you have a node tree all snapped to grid and is perfectly organized, you move it and it all moves in an organized manner. But say you change your UI resoltuion scale, or line width; the perfectly organized node tree is not organized anymore 🥲. Now it may seem that this bug is really rare, but it's really infuriating when you open someone's file and you mess up the node tree in seconds by just moving.

Exact steps for others to reproduce the error
I created a small video that demonstrates the bug, but basically the steps are.

Create a well-organized node tree that is snapped to grid.
Change the UI resolution.
Observe your node tree not snapped to grid anymore.

**System Information** Operating system: Windows-10-10.0.25393-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 536.23 **Blender Version** Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-06-30 00:04, hash: `e73a9a6a7d7b` Worked: Never AFAIK **Short description of error** When you have a node tree all snapped to grid and is perfectly organized, you move it and it all moves in an organized manner. But say you change your UI resoltuion scale, or line width; the perfectly organized node tree is not organized anymore 🥲. Now it may seem that this bug is really rare, but it's really infuriating when you open someone's file and you mess up the node tree in seconds by just moving. **Exact steps for others to reproduce the error** I created a small video that demonstrates the bug, but basically the steps are. 1. Create a well-organized node tree that is snapped to grid. 2. Change the UI resolution. 3. Observe your node tree not snapped to grid anymore.

UI_BugReport.mp4

5.7 MiB

fwfeet added the

labels 2023-07-01 00:14:36 +02:00

Iliya Katushenock added the

label 2023-07-01 00:39:58 +02:00

Pratik Borhade commented

2023-07-03 08:42:41 +02:00

Member

Hi, thanks for the report. Maybe scale_factor is taken into consideration for snapping? I'm not sure if this is a bug or intended behavior.

Hi, thanks for the report. Maybe scale_factor is taken into consideration for snapping? I'm not sure if this is a bug or intended behavior.

Pratik Borhade added the

Nodes & Physics

labels 2023-07-03 08:43:05 +02:00

fwfeet commented

2023-07-03 09:02:15 +02:00

Author

I mean it might be intended behavior, but it's a bit weird since when you change a computer that has a different monitor it will "change" your file so it's really frustrating.

I mean it might be intended behavior, but it's a bit weird since when you change a computer that has a different monitor it will "change" your file so it's really frustrating.

Pratik Borhade commented

2023-07-17 12:45:39 +02:00

Member

Will confirm for now.

Will confirm for now.

Pratik Borhade added

and removed

labels 2023-07-17 12:45:53 +02:00

Leon Schittek commented

2023-08-23 23:28:35 +02:00

Member

This happens because the snap increment is based on U.widget_unit (see ED_node_grid_size()), which takes into account the dpi, UI scale and line width. Therefore it does not scale linearly with the resolution scale and doesn't match the the way the node editor itself scales.

Here's a graph showing how the scaling of U.widget in relation to the resolution scale (dpi of 96 and default line width) deviates from linear scaling:

So I think widget_unit just isn't a good fit for this, since it doesn't really represent the way the node editor scales with the resolution scale.
I can also reproduce this by just moving the blender window between my laptop screen and external monitor with different dpi. So I think it's fair to call this a bug.

This happens because the snap increment is based on `U.widget_unit` (see `ED_node_grid_size()`), which takes into account the dpi, UI scale and line width. Therefore it does not scale linearly with the resolution scale and doesn't match the the way the node editor itself scales. Here's a graph showing how the scaling of U.widget in relation to the resolution scale (dpi of 96 and default line width) deviates from linear scaling: ![widget_unit.png](/attachments/d46d4c2f-5f2d-4124-a138-5e338f80090b) So I think `widget_unit` just isn't a good fit for this, since it doesn't really represent the way the node editor scales with the resolution scale. I can also reproduce this by just moving the blender window between my laptop screen and external monitor with different dpi. So I think it's fair to call this a bug.

widget_unit.png

124 KiB

Harley Acheson commented

2023-08-24 00:46:14 +02:00

Member

@lone_noel - ...U.widget_unit ...takes into account the dpi, UI scale and line width... just isn't a good fit for this...

Yes, U.widget_unit shouldn't be used for much at all. It is useful for us when calculating how wide an actual button is. And probably isn't terrible to use for large things like how wide a dialog is.

In almost all cases it could/should be replaced with (20 x UI_SCALE_FAC) and the result will be something that scales properly and smoothly with UI scale. The exceptions are few and far between, basically if the thing really should get bigger/smaller with changes to Line Width.

> @lone_noel - ...`U.widget_unit` ...takes into account the dpi, UI scale and line width... just isn't a good fit for this... Yes, U.widget_unit shouldn't be used for much at all. It is useful for us when calculating how wide an actual button is. And probably isn't terrible to use for large things like how wide a dialog is. In almost all cases it could/should be replaced with (20 x UI_SCALE_FAC) and the result will be something that scales properly and smoothly with UI scale. The exceptions are few and far between, basically if the thing really should get bigger/smaller with changes to Line Width.

Harley Acheson commented

2023-08-24 00:50:32 +02:00

Member

Do you mind attaching to this report a sample blend file with such a "well-organized node tree that is snapped to grid"? That way it can act as something to test with.

@costa Do you mind attaching to this report a sample blend file with such a "well-organized node tree that is snapped to grid"? That way it can act as something to test with.

fwfeet commented

2023-08-25 23:03:33 +02:00

Author

Sure a sample blend file, I organized just some ndoes on my main 4K monitor and then I moved the blender window to my secondary 1080p monitor and aligned it again.

@Harley Sure a sample blend file, I organized just some ndoes on my main 4K monitor and then I moved the blender window to my secondary 1080p monitor and aligned it again.

109572#.blend

783 KiB

Harley Acheson commented

2023-08-25 23:52:15 +02:00

Member

Sorry to be pedantic, but I want to make sure we are looking at the same things. So hoping you can load this blend file and then carefully describe the problems you see, more clearly than "not organized anymore".

When I view that file I know there are probably a lot of things that could potentially bug you. When changing scale and looking at the actual sizes and positioning of the nodes they behave as I would expect. As line thickness is changed (line width to thin or thick) I do see the nodes change their vertical sizes, but that is expected since the border areas around each input will change.

Separate from the node sizes and placement I am certainly seeing weirdness with the grid itself. As Leon mentions above the grid is changing with line width when it shouldn't. The spacing of the grid should only depend on UI_SCALE_FAC. It is the sizes of the grid dots that should only change with line width.

@costa Sorry to be pedantic, but I want to make sure we are looking at the same things. So hoping you can load this blend file and then carefully describe the problems you see, more clearly than "not organized anymore". When I view that file I know there are probably a lot of things that could potentially bug you. When changing scale and looking at the actual sizes and positioning of the nodes they behave as I would expect. As line thickness is changed (line width to thin or thick) I do see the nodes change their vertical sizes, but that is expected since the border areas around each input will change. Separate from the node sizes and placement I am certainly seeing weirdness with the grid itself. As Leon mentions above the grid is changing with line width when it shouldn't. The spacing of the grid should only depend on UI_SCALE_FAC. It is the sizes of the grid **dots** that should only change with line width.

fwfeet commented

2023-08-26 11:36:49 +02:00

Author

No problem at all, I didn't notice I wasn't clear enough. I created a video of the problem that demonstrates the issue. :)

The reason this bug is so annoying is because my system has a 4K monitor and a FHD, sometimes I create my nodetree on the 4K and sometimes on the other. I use grid snapping all the time so everything is aligned and organized, but if I move the nodes to another monitor the whole alignment and organization is messed up everything will move and won't sync with the previous grid.
Another reason is when I work on another computer it will mess up the aligned to grid nodetree.

@Harley No problem at all, I didn't notice I wasn't clear enough. I created a video of the problem that demonstrates the issue. :) The reason this bug is so annoying is because my system has a 4K monitor and a FHD, sometimes I create my nodetree on the 4K and sometimes on the other. I use grid snapping all the time so everything is aligned and organized, but if I move the nodes to another monitor the whole alignment and organization is messed up everything will move and won't sync with the previous grid. Another reason is when I work on another computer it will mess up the aligned to grid nodetree.

109572#.blend

783 KiB

Harley Acheson commented

2023-08-27 20:37:59 +02:00

Member

I think I understand this issue now, but would love someone to confirm the following ideas, like @lone_noel.

First, an aside. I do think we should change the grid size so that it does not change with line width. That would look something like this:

diff --git a/source/blender/editors/include/ED_node_c.hh b/source/blender/editors/include/ED_node_c.hh
index ad100f511cc..62dca4b5700 100644
--- a/source/blender/editors/include/ED_node_c.hh
+++ b/source/blender/editors/include/ED_node_c.hh
@@ -30,7 +30,7 @@ enum NodeBorder {
 };
 ENUM_OPERATORS(NodeBorder, NODE_RIGHT)
 
-#define NODE_GRID_STEP_SIZE U.widget_unit /* Based on the grid nodes snap to. */
+#define NODE_GRID_STEP_SIZE (20.0f * UI_SCALE_FAC) /* Based on the grid nodes snap to. */
 #define NODE_EDGE_PAN_INSIDE_PAD 2
 #define NODE_EDGE_PAN_OUTSIDE_PAD 0 /* Disable clamping for node panning, use whole screen. */
 #define NODE_EDGE_PAN_SPEED_RAMP 1
diff --git a/source/blender/editors/space_node/node_draw.cc b/source/blender/editors/space_node/node_draw.cc
index e72de7a93b7..7ebd989e9a9 100644
--- a/source/blender/editors/space_node/node_draw.cc
+++ b/source/blender/editors/space_node/node_draw.cc
@@ -130,7 +130,8 @@ struct TreeDrawContext {
 
 float ED_node_grid_size()
 {
-  return U.widget_unit;
+  return 20.0f * UI_SCALE_FAC;
+  //return U.widget_unit;
 }
 
 void ED_node_tree_update(const bContext *C)

With the above the snapping grid stays put as you change line width, with only the grid dots changing size. However, this change does not affect this bug report at all...

If you look at the video carefully, everything is spaced nicely at the start. The resolution scale is then changed at 0:04, and at that point the nodes resize and they are all still perfectly aligned. Following is a capture from the video at 0:04 when the nodes are at the new size, with the same nice spacing:

It is only when all the selected nodes are moved together that the spacing changes weirdly at 0:05. So it isn't the sizing of these that is broken but what happens when multiple items are moved when snapping is set to Grid. And that behavior shown is currently by design.

The nodes are not sized to be perfect multiples of the grid size. When we move ONE node at a time it will snap nicely to the grid. But select multiple nodes and move them and we snap each individual node to the grid. This means that some of the nodes will pass a snapping point when others are not near them. This will necessarily cause the nodes to move individually and that will mean that they will move closer and further apart.

I only see two solutions to this. The first is don't have snapping set to grid if you want to move multiple selected items and want them to remain with the same spacing.

The other would be for us to change what happens when snapping multiple items to the grid and only consider ONE node, the active one. I think that might cause more trouble that it is worth though. The active node might be in the middle of the pack and therefore where it is snapping might not make a lot of sense. Perhaps only snap based on the node at the top-left of a selection, but selections aren't always so neat as illustrated here. Selecting just two nodes, far from each other, you might want to be able to snap to locations relative to both.

So I think my advice would be to not move multiple selected nodes while snapping to grid and expect them to keep the same relative distances from each other.

I think I understand this issue now, but would love someone to confirm the following ideas, like @lone_noel. First, an aside. I do think we should change the grid size so that it does not change with line width. That would look something like this: ```Diff diff --git a/source/blender/editors/include/ED_node_c.hh b/source/blender/editors/include/ED_node_c.hh index ad100f511cc..62dca4b5700 100644 --- a/source/blender/editors/include/ED_node_c.hh +++ b/source/blender/editors/include/ED_node_c.hh @@ -30,7 +30,7 @@ enum NodeBorder { }; ENUM_OPERATORS(NodeBorder, NODE_RIGHT) -#define NODE_GRID_STEP_SIZE U.widget_unit /* Based on the grid nodes snap to. */ +#define NODE_GRID_STEP_SIZE (20.0f * UI_SCALE_FAC) /* Based on the grid nodes snap to. */ #define NODE_EDGE_PAN_INSIDE_PAD 2 #define NODE_EDGE_PAN_OUTSIDE_PAD 0 /* Disable clamping for node panning, use whole screen. */ #define NODE_EDGE_PAN_SPEED_RAMP 1 diff --git a/source/blender/editors/space_node/node_draw.cc b/source/blender/editors/space_node/node_draw.cc index e72de7a93b7..7ebd989e9a9 100644 --- a/source/blender/editors/space_node/node_draw.cc +++ b/source/blender/editors/space_node/node_draw.cc @@ -130,7 +130,8 @@ struct TreeDrawContext { float ED_node_grid_size() { - return U.widget_unit; + return 20.0f * UI_SCALE_FAC; + //return U.widget_unit; } void ED_node_tree_update(const bContext *C) ``` With the above the snapping grid stays put as you change line width, with only the grid dots changing size. However, this change does **not** affect this bug report at all... If you look at the video carefully, everything is spaced nicely at the start. The resolution scale is then changed at 0:04, and at that point the nodes resize and they are **all still perfectly aligned**. Following is a capture from the video at 0:04 when the nodes are at the new size, with the same nice spacing: ![image](/attachments/fee55e71-e18c-43f9-9be5-c61b9eb45e85) It is only when all the selected nodes are moved together that the spacing changes weirdly at 0:05. So it isn't the sizing of these that is broken but what happens when multiple items are moved when snapping is set to Grid. And that behavior shown is currently by design. The nodes are not sized to be perfect multiples of the grid size. When we move ONE node at a time it will snap nicely to the grid. But select **multiple** nodes and move them and we snap _each individual node to the grid_. This means that some of the nodes will pass a snapping point when others are not near them. This will necessarily cause the nodes to move individually and that will mean that they will move closer and further apart. I only see two solutions to this. The first is don't have snapping set to grid if you want to move multiple selected items and want them to remain with the same spacing. The other would be for us to change what happens when snapping multiple items to the grid and only consider ONE node, the active one. I think that might cause more trouble that it is worth though. The active node might be in the middle of the pack and therefore where it is snapping might not make a lot of sense. Perhaps only snap based on the node at the top-left of a selection, but selections aren't always so neat as illustrated here. Selecting just two nodes, far from each other, you might want to be able to snap to locations relative to both. So I think my advice would be to not move multiple selected nodes while snapping to grid and expect them to keep the same relative distances from each other.

641 KiB

fwfeet commented

2023-08-27 21:51:28 +02:00

Author

I did some more investigation and I found a weird problem that happens without even moving without moving the nodes.
Here I just scale the resoltion scale between 0.5 and 2.0 and You can see the spacing between the nodes changes.

I did some more investigation and I found a weird problem that happens without even moving without moving the nodes. Here I just scale the resoltion scale between 0.5 and 2.0 and You can see the spacing between the nodes changes.

1095702_2.mp4

5.8 MiB

Leon Schittek commented

2023-08-28 23:45:23 +02:00

Member

Thanks for the investigation, @Harley.

I think I understand this issue now, but would love someone to confirm the following ideas, like @lone_noel.

First, an aside. I do think we should change the grid size so that it does not change with line width. [...]

Yeah, this seems good!

With the above the snapping grid stays put as you change line width, with only the grid dots changing size. However, this change does not affect this bug report at all...

I think your analysis of the current behavior is spot on, but I think your patch above actually does pretty much fix, what the bug is about.

Yes, the nodes are snapped individually and when they are placed freely on the canvas, the different alignment with the grid can cause them to move closer or further apart.

But once all the nodes are aligned with the grid, they do keep snapping to the grid in sync (barring some potential rounding edge cases, I suppose...)

What the video shows is how nodes that are aligned to the grid, suddenly aren’t anymore after changing the scale/line width, which causes them to realign (and sometimes change spacing) when snapping during transform.
Since your patch would keep the nodes and the grid aligned, when changing the resolution scale/line width/dpi, they also wouldn’t change spacing during transform afterward.

So I think my advice would be to not move multiple selected nodes while snapping to grid and expect them to keep the same relative distances from each other.

Yeah, it’s a bit unfortunate limitation right now.
I can think of a way to keep the snapping of multiple individually snapping nodes in sync, but looking at the transform operator that doesn’t seem to be easily implementable with how it’s currently set up.

Thanks for the investigation, @Harley. > I think I understand this issue now, but would love someone to confirm the following ideas, like @lone_noel. > > First, an aside. I do think we should change the grid size so that it does not change with line width. [...] Yeah, this seems good! > With the above the snapping grid stays put as you change line width, with only the grid dots changing size. However, this change does **not** affect this bug report at all... I think your analysis of the current behavior is spot on, but I think your patch above actually *does* pretty much fix, what the bug is about. Yes, the nodes are snapped individually and when they are placed freely on the canvas, the different alignment with the grid can cause them to move closer or further apart. **But** once all the nodes are aligned with the grid, they *do* keep snapping to the grid in sync (barring some potential rounding edge cases, I suppose...) What the video shows is how nodes that are aligned to the grid, suddenly aren’t anymore after changing the scale/line width, which causes them to realign (and sometimes change spacing) when snapping during transform. Since your patch would keep the nodes and the grid aligned, when changing the resolution scale/line width/dpi, they also wouldn’t change spacing during transform afterward. > So I think my advice would be to not move multiple selected nodes while snapping to grid and expect them to keep the same relative distances from each other. Yeah, it’s a bit unfortunate limitation right now. I can think of a way to keep the snapping of multiple individually snapping nodes in sync, but looking at the transform operator that doesn’t seem to be easily implementable with how it’s currently set up.

Leon Schittek commented

2023-08-28 23:52:10 +02:00

Member

@costa wrote:
I did some more investigation and I found a weird problem that happens without even moving without moving the nodes.
Here I just scale the resoltion scale between 0.5 and 2.0 and You can see the spacing between the nodes changes.

Yes, this is expected behavior. Nodes don't have a fixed height. They are as tall as they need to be to contain the layout of the buttons. Since the buttons are based on the widget_unit which scales incrementally rather than strictly linearly, the height of the nodes varies a bit.

I'd love it, if in the long run we changed the layout system for nodes so that they are sized more consistently. Changing the UI preferences shouldn't make it so people have to adjust their node layouts.

>@costa wrote: > I did some more investigation and I found a weird problem that happens without even moving without moving the nodes. > Here I just scale the resoltion scale between 0.5 and 2.0 and You can see the spacing between the nodes changes. Yes, this is expected behavior. Nodes don't have a fixed height. They are as tall as they need to be to contain the layout of the buttons. Since the buttons are based on the `widget_unit` which scales incrementally rather than strictly linearly, the height of the nodes varies a bit. I'd love it, if in the long run we changed the layout system for nodes so that they are sized more consistently. Changing the UI preferences shouldn't make it so people have to adjust their node layouts.

Harley Acheson commented

2023-08-29 00:03:02 +02:00

Member

I'll post a PR about the node snapping grid sizing issue. But I don't think I can do so as a fix for this, mostly because they was showing the changes from the movement of multiple nodes and not just about changing size. There are quite a few sizing issues here as you've noticed. LOL

I'll try to make another PR that removes the consideration of line width for node positioning. I've tried before and it got a bit tricky as there are some places where line width has to be considered, just because the wires and the connections get larger. I think the strategy has to include comparing screenshots of the result at exactly 1x and 2x resolution scales to make sure those don't change at all. Might help.

@lone_noel I'll post a PR about the node snapping grid sizing issue. But I don't think I can do so as a fix for this, mostly because they was showing the changes from the movement of multiple nodes and not just about changing size. There are quite a few sizing issues here as you've noticed. LOL I'll try to make another PR that removes the consideration of line width for node positioning. I've tried before and it got a bit tricky as there are some places where line width has to be considered, just because the wires and the connections get larger. I think the strategy has to include comparing screenshots of the result at exactly 1x and 2x resolution scales to make sure those don't change at all. Might help.

Harley Acheson referenced this issue

2023-08-29 02:32:22 +02:00

UI: Node Grid Adjustments for Line Width #111640

fwfeet commented

2023-11-09 12:24:13 +01:00

Author

@Harley Hey, I can't find the # but I if I remember I think you fixed it, right?

@Harley Hey, I can't find the # but I if I remember I think you fixed it, right?

Harley Acheson commented

2023-11-09 13:19:06 +01:00

Member

I did fix the only part of this report that is fixable. The snapping now scales positions correctly with UI scale, and the line width now only changes the sizes of the dots. That fixes most weirdness reported here.

Not fixed, but not fixable, is something also shown in this report. Nodes are snapped individually, so moving multiples at once while snapping is on will change spacing as they move as different items snap as they hit snapping points. This is pretty normal. About the only way to change this is to snap only one node when moving multiples, but many people would dislike that. So basically don’t expect to move multiple items together with snapping on and expect them to keep relative distances static - each item snaps

I did fix the only part of this report that is fixable. The snapping now scales positions correctly with UI scale, and the line width now only changes the sizes of the dots. That fixes most weirdness reported here. Not fixed, but not fixable, is something also shown in this report. Nodes are snapped individually, so moving multiples at once while snapping is on will change spacing as they move as different items snap as they hit snapping points. This is pretty normal. About the only way to change this is to snap only one node when moving multiples, but many people would dislike that. So basically don’t expect to move multiple items together with snapping on and expect them to keep relative distances static - each item snaps

Harley Acheson closed this issue

2023-11-09 13:19:10 +01:00

Blender Bot added

and removed

labels 2023-11-09 13:19:49 +01:00

Leon Schittek commented

2023-11-09 19:13:44 +01:00

Member

Not fixed, but not fixable, is something also shown in this report. Nodes are snapped individually, so moving multiples at once while snapping is on will change spacing as they move as different items snap as they hit snapping points.

In general this is true, but specifically for moving nodes (rather than rotating or scaling) it can be fixed by applying the snapping to both the initial node location as well as the offset nodes are moved by. Basically first aligning all nodes to the grid so they can then be moved as a block.

I wonder if we really want this though. I'm kinda fond of being able to adjust specific spacing for nodes that aren't aligned with the grid, yet. Even though it can be a bit finicky.

example diff


diff --git a/source/blender/editors/transform/transform_convert_node.cc b/source/blender/editors/transform/transform_convert_node.cc
index 2d18269d22f..71e63ddd6ac 100644
--- a/source/blender/editors/transform/transform_convert_node.cc
+++ b/source/blender/editors/transform/transform_convert_node.cc
@@ -150,6 +150,11 @@ static void createTransNodeData(bContext * /*C*/, TransInfo *t)
 /** \name Flush Transform Nodes
  * \{ */
 
+static blender::float2 snap(blender::float2 v, blender::float2 increment)
+{
+  return blender::math::round(v / increment) * increment;
+}
+
 static void node_snap_grid_apply(TransInfo *t)
 {
   using namespace blender;
@@ -172,7 +177,6 @@ static void node_snap_grid_apply(TransInfo *t)
   FOREACH_TRANS_DATA_CONTAINER (t, tc) {
     for (const int i : IndexRange(tc->data_len)) {
       TransData &td = tc->data[i];
-      float iloc[2], loc[2], tvec[2];
       if (td.flag & TD_SKIP) {
         continue;
       }
@@ -181,13 +185,13 @@ static void node_snap_grid_apply(TransInfo *t)
         continue;
       }
 
-      copy_v2_v2(iloc, td.loc);
+      const float2 inital_location = float2(td.iloc);
+      const float2 transformed_location = float2(td.loc);
+      const float2 offset = transformed_location - inital_location;
 
-      loc[0] = roundf(iloc[0] / grid_size[0]) * grid_size[0];
-      loc[1] = roundf(iloc[1] / grid_size[1]) * grid_size[1];
+      const float2 snapped_location = snap(inital_location, grid_size) + snap(offset, grid_size);
 
-      sub_v2_v2v2(tvec, loc, iloc);
-      add_v2_v2(td.loc, tvec);
+      copy_v2_v2(td.loc, snapped_location);
     }
   }
 }

> Not fixed, but not fixable, is something also shown in this report. Nodes are snapped individually, so moving multiples at once while snapping is on will change spacing as they move as different items snap as they hit snapping points. In general this is true, but specifically for moving nodes (rather than rotating or scaling) it can be fixed by applying the snapping to both the initial node location as well as the offset nodes are moved by. Basically first aligning all nodes to the grid so they can then be moved as a block. I wonder if we really want this though. I'm kinda fond of being able to adjust specific spacing for nodes that aren't aligned with the grid, yet. Even though it can be a bit finicky. <details> <summary>example diff</summary> ```diff diff --git a/source/blender/editors/transform/transform_convert_node.cc b/source/blender/editors/transform/transform_convert_node.cc index 2d18269d22f..71e63ddd6ac 100644 --- a/source/blender/editors/transform/transform_convert_node.cc +++ b/source/blender/editors/transform/transform_convert_node.cc @@ -150,6 +150,11 @@ static void createTransNodeData(bContext * /*C*/, TransInfo *t) /** \name Flush Transform Nodes * \{ */ +static blender::float2 snap(blender::float2 v, blender::float2 increment) +{ + return blender::math::round(v / increment) * increment; +} + static void node_snap_grid_apply(TransInfo *t) { using namespace blender; @@ -172,7 +177,6 @@ static void node_snap_grid_apply(TransInfo *t) FOREACH_TRANS_DATA_CONTAINER (t, tc) { for (const int i : IndexRange(tc->data_len)) { TransData &td = tc->data[i]; - float iloc[2], loc[2], tvec[2]; if (td.flag & TD_SKIP) { continue; } @@ -181,13 +185,13 @@ static void node_snap_grid_apply(TransInfo *t) continue; } - copy_v2_v2(iloc, td.loc); + const float2 inital_location = float2(td.iloc); + const float2 transformed_location = float2(td.loc); + const float2 offset = transformed_location - inital_location; - loc[0] = roundf(iloc[0] / grid_size[0]) * grid_size[0]; - loc[1] = roundf(iloc[1] / grid_size[1]) * grid_size[1]; + const float2 snapped_location = snap(inital_location, grid_size) + snap(offset, grid_size); - sub_v2_v2v2(tvec, loc, iloc); - add_v2_v2(td.loc, tvec); + copy_v2_v2(td.loc, snapped_location); } } } ``` </details>

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

4 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#109572

No description provided.