Incremental snapping is constant (not adapting to orthographic viewport scale) #56499

New Issue

Hjalti Hjálmarsson · 2018-08-22T16:00:07+02:00

2018-08-22 16:00:07 +02:00

System Information
Xbuntu / AMD

Blender Version
21f0906

Short description of error
When using incremental snapping in the viewport, it's always set to 1 meter regardless of whether you're zoomed into the viewport and 1 meter is far greater than your view. Basically it should adapt to the viewport like it used to do in 2.79.

Exact steps for others to reproduce the error
New file
go to orthographic side view
select the cube and zoom into it
move it in x-axis while holding down Ctrl
...it jumps between 0 and 1 even though your view might only be looking at something closer to 0.01 in size...

**System Information** Xbuntu / AMD **Blender Version** 21f0906 **Short description of error** When using incremental snapping in the viewport, it's always set to 1 meter regardless of whether you're zoomed into the viewport and 1 meter is far greater than your view. Basically it should adapt to the viewport like it used to do in 2.79. **Exact steps for others to reproduce the error** New file go to orthographic side view select the cube and zoom into it move it in x-axis while holding down Ctrl ...it jumps between 0 and 1 even though your view might only be looking at something closer to 0.01 in size...

Hjalti Hjálmarsson commented

2018-08-22 16:00:08 +02:00

Added subscriber: @Hjalti

Antoine commented

2018-08-22 18:31:11 +02:00

Added subscriber: @Martantoine

Antoine commented

2018-08-22 18:31:11 +02:00

This bug is also on windows 10 x64

Bastien Montagne changed title from ~~Incremental snapping is constant (not adapting to viewport)~~ to Incremental snapping is constant (not adapting to orthographic viewport scale)

2018-08-23 11:39:47 +02:00

Germano Cavalcante commented

2018-08-24 18:25:45 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2018-08-24 18:25:45 +02:00

Analyzing the code, it seens that this pre2.80 behavior came by accident.

The distance between the snap points is calculated by rv3d->gridview which is apparently a member created to draw the grid in blender 2.79.
On 2.80 the grid drawing was completely rewritten, and the gridview member became deprecated.

We can simulate the same behavior seen in 2.79 with this:
P771: Fix #56499

diff --git a/source/blender/editors/transform/transform.c b/source/blender/editors/transform/transform.c
index 142460bb7fa..6089b3db48d 100644
--- a/source/blender/editors/transform/transform.c
+++ b/source/blender/editors/transform/transform.c
@@ -4578,8 +4578,26 @@ static void initSnapSpatial(TransInfo *t, float r_snap[3])
 		RegionView3D *rv3d = t->ar->regiondata;
 
 		if (rv3d) {
+			View3D *v3d = t->sa->spacedata.first;
+			float grid_scale = ED_view3d_grid_scale(t->scene, v3d, NULL);
+
+			if (!rv3d->is_persp && RV3D_VIEW_IS_AXIS(rv3d->view)) {
+				/* Decrease the distance between grid snap points depending on zoom. */
+				float grid_subdiv = v3d->gridsubdiv;
+				if (grid_subdiv > 1) {
+					float grid_distance = rv3d->dist;
+					float lvl = (logf(grid_distance / grid_scale) / logf(grid_subdiv));
+					if (lvl < 0.0f) {
+						/* Negative values need an offset for correct rounding.
+						 * By convention, the minimum lvl is limited to -1 */
+						lvl = -1.0f;
+					}
+
+					grid_scale *= pow(grid_subdiv, (int)lvl - 1);
+				}
+			}
 			r_snap- [x] = 0.0f;
-			r_snap- [x] = rv3d->gridview * 1.0f;
+			r_snap- [x] = grid_scale * 1.0f;
 			r_snap- [x] = r_snap- [x] * 0.1f;
 		}
 	}
diff --git a/source/blender/makesdna/DNA_view3d_types.h b/source/blender/makesdna/DNA_view3d_types.h
index 317cde9009d..65b6192b9c8 100644
--- a/source/blender/makesdna/DNA_view3d_types.h
+++ b/source/blender/makesdna/DNA_view3d_types.h
@@ -96,7 +96,7 @@ typedef struct RegionView3D {
 	float tw_axis_min- [x], tw_axis_max[3];
 	float tw_axis_matrix- [x][3];
 
-	float gridview;
+	float gridview DNA_DEPRECATED;
 
 	float viewquat- [x];			/* view rotation, must be kept normalized */
 	float dist;					/* distance from 'ofs' along -viewinv- [x] vector, where result is negative as is 'ofs' */

Or we can change the default behavior to just consider the grid_scale.

Analyzing the code, it seens that this pre2.80 behavior came by accident. The distance between the snap points is calculated by `rv3d->gridview` which is apparently a member created to draw the grid in blender 2.79. On 2.80 the grid drawing was completely rewritten, and the `gridview` member became deprecated. We can simulate the same behavior seen in 2.79 with this: [P771: Fix #56499](https://archive.blender.org/developer/P771.txt) ```diff diff --git a/source/blender/editors/transform/transform.c b/source/blender/editors/transform/transform.c index 142460bb7fa..6089b3db48d 100644 --- a/source/blender/editors/transform/transform.c +++ b/source/blender/editors/transform/transform.c @@ -4578,8 +4578,26 @@ static void initSnapSpatial(TransInfo *t, float r_snap[3]) RegionView3D *rv3d = t->ar->regiondata; if (rv3d) { + View3D *v3d = t->sa->spacedata.first; + float grid_scale = ED_view3d_grid_scale(t->scene, v3d, NULL); + + if (!rv3d->is_persp && RV3D_VIEW_IS_AXIS(rv3d->view)) { + /* Decrease the distance between grid snap points depending on zoom. */ + float grid_subdiv = v3d->gridsubdiv; + if (grid_subdiv > 1) { + float grid_distance = rv3d->dist; + float lvl = (logf(grid_distance / grid_scale) / logf(grid_subdiv)); + if (lvl < 0.0f) { + /* Negative values need an offset for correct rounding. + * By convention, the minimum lvl is limited to -1 */ + lvl = -1.0f; + } + + grid_scale *= pow(grid_subdiv, (int)lvl - 1); + } + } r_snap- [x] = 0.0f; - r_snap- [x] = rv3d->gridview * 1.0f; + r_snap- [x] = grid_scale * 1.0f; r_snap- [x] = r_snap- [x] * 0.1f; } } diff --git a/source/blender/makesdna/DNA_view3d_types.h b/source/blender/makesdna/DNA_view3d_types.h index 317cde9009d..65b6192b9c8 100644 --- a/source/blender/makesdna/DNA_view3d_types.h +++ b/source/blender/makesdna/DNA_view3d_types.h @@ -96,7 +96,7 @@ typedef struct RegionView3D { float tw_axis_min- [x], tw_axis_max[3]; float tw_axis_matrix- [x][3]; - float gridview; + float gridview DNA_DEPRECATED; float viewquat- [x]; /* view rotation, must be kept normalized */ float dist; /* distance from 'ofs' along -viewinv- [x] vector, where result is negative as is 'ofs' */ ``` Or we can change the default behavior to just consider the `grid_scale`.

Brecht Van Lommel commented

2018-08-24 18:50:31 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2018-08-24 18:50:31 +02:00

I don't think the behavior was by accident, snapping to the visible grid resolution is by design. But it wasn't obvious at all that this variable is used for snapping.

The rv3d->gridview variable can be removed, and instead there can be a 3D view utility function that computes it. Then it can also be used by the snap to grid operators, since those have the same problem as the transform operator.

I don't think the behavior was by accident, snapping to the visible grid resolution is by design. But it wasn't obvious at all that this variable is used for snapping. The `rv3d->gridview` variable can be removed, and instead there can be a 3D view utility function that computes it. Then it can also be used by the snap to grid operators, since those have the same problem as the transform operator.

Germano Cavalcante commented

2018-08-24 19:45:46 +02:00

In #56499#530181, @brecht wrote:
I don't think the behavior was by accident, snapping to the visible grid resolution is by design. (...)

If that is the case, the grid drawing has also changed, so in the orthographic views when RV3D_VIEW_IS_AXIS the number of subdivisions in blender2.80 is less than in previous versions.
Not to mention that now in blender2.80, in any position, the grid adapts the drawing of subvisions.

I think a new behavior still needs to be discussed.
In my opinion a middle ground would always be to adapt the distance between the grid snap points (not just if RV3D_VIEW_IS_AXIS) and change the default grid_scale from 1.0 to 0.01.

> In #56499#530181, @brecht wrote: > I don't think the behavior was by accident, snapping to the visible grid resolution is by design. (...) If that is the case, the grid drawing has also changed, so in the orthographic views when RV3D_VIEW_IS_AXIS the number of subdivisions in blender2.80 is less than in previous versions. Not to mention that now in blender2.80, in any position, the grid adapts the drawing of subvisions. I think a new behavior still needs to be discussed. In my opinion a middle ground would always be to adapt the distance between the grid snap points (not just if RV3D_VIEW_IS_AXIS) and change the default `grid_scale` from 1.0 to 0.01.

Adrian Giddings commented

2018-08-24 20:27:19 +02:00

Added subscriber: @cunabula

Adrian Giddings commented

2018-08-24 20:27:19 +02:00

This was something I posted about in Right Click Select:

https://blender.community/c/rightclickselect/HQbbbc/

Copy/pasted here:

Remap (and add to) the progressive grid floor gradations for 2.80

In 2.79 the grid floor progressively adds/removes levels of detail as you zoom in and out. The same for 2.8 but in 2.8 the minimum level is 1 unit while in 2.79 it's 0.01 units

In 2.79 the levels in units are [1000] [100] [10] - [x] [0.1] [0.01] which, assuming 1 unit is 1 metre would map from 1km to 1cm.

In 2.8 they're just [1000] [100] [10] - [x] which is not as much use.

If the sub unit divisions could come back that would be ace, as would the addition of a lower [0.001] (or in metric 1mm) level.

I do appreciate that you can just work larger and scale everything down (especially when the bounding box bug is fixed so reports the correct size after transforms) but the extra faffing around which was mainly unnecessary in 2.79 would be a shame.

This was something I posted about in Right Click Select: https://blender.community/c/rightclickselect/HQbbbc/ Copy/pasted here: > **Remap (and add to) the progressive grid floor gradations for 2.80** > > > In 2.79 the grid floor progressively adds/removes levels of detail as you zoom in and out. The same for 2.8 but in 2.8 the minimum level is 1 unit while in 2.79 it's 0.01 units > > In 2.79 the levels in units are [1000] [100] [10] **- [x]** [0.1] [0.01] which, assuming 1 unit is 1 metre would map from 1km to 1cm. > > In 2.8 they're just [1000] [100] [10] **- [x]** which is not as much use. > > If the sub unit divisions could come back that would be ace, as would the addition of a lower [0.001] (or in metric 1mm) level. > > I do appreciate that you can just work larger and scale everything down (especially when the bounding box bug is fixed so reports the correct size after transforms) but the extra faffing around which was mainly unnecessary in 2.79 would be a shame.

ronan ducluzeau commented

2018-08-25 12:08:50 +02:00

Added subscriber: @zeauro

ronan ducluzeau commented

2018-08-25 12:08:50 +02:00

Absence of subdivisions is a problem.
A user losts a useful info about proportions. This is my unit. And this is one half, one third or one tenth of my unit.
I want my object 3 units large. So, that detail of this object should be large of 2 tenth of unit.
It is how user is thinking during the modeling process.
It helps a lot to make a decision to see subdivisions of grid.

Currently, with default grid scale at 1, subdivisions are invisible.
With grid scale at 0.1, they become visible. But now, it means that grid increment is set to 0.1 unit.
At grid scale at 1, if I set amount of subdivisions to 3 to see thirds of my unit, I obtain a grid with thicker lines every 3 units and subdivision lines corresponding to 1 unit.
A default for grid scale to 0.01, does not make sense. User wants grid units corresponding to its unit system, not to a portion of it.
Subdivisions should behave as subdivisions, not as a way to specify these first units have thiner lines.

Basically user wants to be able to switch between a grid increment relative to thick lines and a grid increment relative to thiner lines.
It could be an option for grid increment snapping. There is no need to mess up grid display for that.
A problem about grid increment snapping is a snapping problem. Solution should modify snapping.
A problem about grid display, is a display problem. Solution should modify display.
But please, don't try to solve a problem with an inappropriate solution.

Absence of subdivisions is a problem. A user losts a useful info about proportions. This is my unit. And this is one half, one third or one tenth of my unit. I want my object 3 units large. So, that detail of this object should be large of 2 tenth of unit. It is how user is thinking during the modeling process. It helps a lot to make a decision to see subdivisions of grid. Currently, with default grid scale at 1, subdivisions are invisible. With grid scale at 0.1, they become visible. But now, it means that grid increment is set to 0.1 unit. At grid scale at 1, if I set amount of subdivisions to 3 to see thirds of my unit, I obtain a grid with thicker lines every 3 units and subdivision lines corresponding to 1 unit. A default for grid scale to 0.01, does not make sense. User wants grid units corresponding to its unit system, not to a portion of it. Subdivisions should behave as subdivisions, not as a way to specify these first units have thiner lines. Basically user wants to be able to switch between a grid increment relative to thick lines and a grid increment relative to thiner lines. It could be an option for grid increment snapping. There is no need to mess up grid display for that. A problem about grid increment snapping is a snapping problem. Solution should modify snapping. A problem about grid display, is a display problem. Solution should modify display. But please, don't try to solve a problem with an inappropriate solution.

blender-admin commented

2018-10-30 18:21:50 +01:00

This issue was referenced by blender/blender@c8e6134386

This issue was referenced by blender/blender@c8e61343867889fda08f800701956245bac4d30f

Germano Cavalcante commented

2018-10-30 18:23:38 +01:00

Changed status from 'Open' to: 'Resolved'

Germano Cavalcante closed this issue

2018-10-30 18:23:38 +01:00

Sign in to join this conversation.