Page MenuHome

Incremental snapping is constant (not adapting to orthographic viewport scale)
Closed, ResolvedPublic


System Information
Xbuntu / AMD

Blender Version

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 jumps between 0 and 1 even though your view might only be looking at something closer to 0.01 in size...

Event Timeline

This bug is also on windows 10 x64

Bastien Montagne (mont29) renamed this task from Incremental snapping is constant (not adapting to viewport) to Incremental snapping is constant (not adapting to orthographic viewport scale).Aug 23 2018, 11:39 AM
Bastien Montagne (mont29) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.

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:

1diff --git a/source/blender/editors/transform/transform.c b/source/blender/editors/transform/transform.c
2index 142460bb7fa..6089b3db48d 100644
3--- a/source/blender/editors/transform/transform.c
4+++ b/source/blender/editors/transform/transform.c
5@@ -4578,8 +4578,26 @@ static void initSnapSpatial(TransInfo *t, float r_snap[3])
6 RegionView3D *rv3d = t->ar->regiondata;
8 if (rv3d) {
9+ View3D *v3d = t->sa->spacedata.first;
10+ float grid_scale = ED_view3d_grid_scale(t->scene, v3d, NULL);
12+ if (!rv3d->is_persp && RV3D_VIEW_IS_AXIS(rv3d->view)) {
13+ /* Decrease the distance between grid snap points depending on zoom. */
14+ float grid_subdiv = v3d->gridsubdiv;
15+ if (grid_subdiv > 1) {
16+ float grid_distance = rv3d->dist;
17+ float lvl = (logf(grid_distance / grid_scale) / logf(grid_subdiv));
18+ if (lvl < 0.0f) {
19+ /* Negative values need an offset for correct rounding.
20+ * By convention, the minimum lvl is limited to -1 */
21+ lvl = -1.0f;
22+ }
24+ grid_scale *= pow(grid_subdiv, (int)lvl - 1);
25+ }
26+ }
27 r_snap[0] = 0.0f;
28- r_snap[1] = rv3d->gridview * 1.0f;
29+ r_snap[1] = grid_scale * 1.0f;
30 r_snap[2] = r_snap[1] * 0.1f;
31 }
32 }
33diff --git a/source/blender/makesdna/DNA_view3d_types.h b/source/blender/makesdna/DNA_view3d_types.h
34index 317cde9009d..65b6192b9c8 100644
35--- a/source/blender/makesdna/DNA_view3d_types.h
36+++ b/source/blender/makesdna/DNA_view3d_types.h
37@@ -96,7 +96,7 @@ typedef struct RegionView3D {
38 float tw_axis_min[3], tw_axis_max[3];
39 float tw_axis_matrix[3][3];
41- float gridview;
42+ float gridview DNA_DEPRECATED;
44 float viewquat[4]; /* view rotation, must be kept normalized */
45 float dist; /* distance from 'ofs' along -viewinv[2] vector, where result is negative as is 'ofs' */

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

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. (...)

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.

This was something I posted about in Right Click Select:

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] [1] [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] [1] 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.

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.