Maniphest T56499

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

Assigned To
None
Authored By
Hjalti Hjálmarsson (hjalti)
Aug 22 2018, 4:00 PM
Tags
  • BF Blender: 2.8
  • Blender Studio
Subscribers
Adrian Giddings (cunabula)
Antoine (Martantoine)
Brecht Van Lommel (brecht)
Germano Cavalcante (mano-wii)
Hjalti Hjálmarsson (hjalti)
ronan ducluzeau (zeauro)

Description

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

Revisions and Commits

rB Blender
rBc8e613438678 Fix T56499: Adapt incremental snapping to orthographic viewport scale.

Related Objects

Mentioned Here
P771 Fix T56499
rB21f09060f8f4: Cleanup: comment naming which will be changed

Event Timeline

Hjalti Hjálmarsson (hjalti) created this task.Aug 22 2018, 4:00 PM
Hjalti Hjálmarsson (hjalti) moved this task from Tasks to Spring Bugs on the Code Quest board.
Antoine (Martantoine) added a subscriber: Antoine (Martantoine).Aug 22 2018, 6:31 PM

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 90 to 50.
Germano Cavalcante (mano-wii) added a subscriber: Germano Cavalcante (mano-wii).Aug 24 2018, 6:25 PM

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 T56499
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;
7
8 if (rv3d) {
9+ View3D *v3d = t->sa->spacedata.first;
10+ float grid_scale = ED_view3d_grid_scale(t->scene, v3d, NULL);
11+
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+ }
23+
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];
40
41- float gridview;
42+ float gridview DNA_DEPRECATED;
43
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.

Brecht Van Lommel (brecht) added a subscriber: Brecht Van Lommel (brecht).Aug 24 2018, 6:50 PM

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 (mano-wii) added a comment.Aug 24 2018, 7:45 PM
In T56499#530181, @Brecht Van Lommel (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 (cunabula) added a subscriber: Adrian Giddings (cunabula).Aug 24 2018, 8:27 PM

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

ronan ducluzeau (zeauro) added a subscriber: ronan ducluzeau (zeauro).EditedAug 25 2018, 12:08 PM

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.

Brecht Van Lommel (brecht) edited projects, added Blender Studio; removed Code Quest.Sep 28 2018, 4:30 PM
Brecht Van Lommel (brecht) moved this task from To Do to Commited/In Review on the Blender Studio board.Sep 28 2018, 4:33 PM
Germano Cavalcante (mano-wii) changed the task status from Unknown Status to Resolved by committing rBc8e613438678: Fix T56499: Adapt incremental snapping to orthographic viewport scale..Oct 30 2018, 6:23 PM
Germano Cavalcante (mano-wii) added a commit: rBc8e613438678: Fix T56499: Adapt incremental snapping to orthographic viewport scale..