Absolute Grid Snapping Corner Cases #45212

New Issue

Julian Eisel · 2015-06-27T14:30:46+02:00

Julian Eisel commented

2015-06-27 14:30:46 +02:00

Absolute Grid Snapping Corner Cases

Since 48ef0501b7 (D910) Blender supports absolute grid snapping. While this works pretty well in basic cases, it still "fails" for some others. "Failing" as in - behaving not so nice UX wise. We'd like to get some user feedback on how people would expect this to behave.

Corner Cases:

Rotating/Scaling: In both cases we can't really snap to grid as a grid is only a locational characteristic. Current implementation falls back to the incremental calculation.
Multiple Objects: Editing multiple objects, the center of all objects is used for snapping. Maybe people would expect all objects to be snapped individually instead. This would influence the spacing between objects but if the user wants to keep this, he can still choose incremental snapping
Non-Grid Aligned Transformation Orientations: (e.g. Transformation Orientation set to "View") - If we force snapping to absolute grid we get same issue as with multiple objects: Spacing between objects may change during transformation

# Absolute Grid Snapping Corner Cases Since 48ef0501b7 ([D910](https://archive.blender.org/developer/D910)) Blender supports absolute grid snapping. While this works pretty well in basic cases, it still "fails" for some others. "Failing" as in - behaving not so nice UX wise. We'd like to get some user feedback on how people would expect this to behave. ## Corner Cases: * **Rotating/Scaling:** In both cases we can't really snap to grid as a grid is only a locational characteristic. Current implementation falls back to the incremental calculation. * **Multiple Objects:** Editing multiple objects, the center of all objects is used for snapping. Maybe people would expect all objects to be snapped individually instead. This would influence the spacing between objects but if the user wants to keep this, he can still choose incremental snapping * **Non-Grid Aligned Transformation Orientations:** (e.g. Transformation Orientation set to "View") - If we force snapping to absolute grid we get same issue as with multiple objects: Spacing between objects may change during transformation

Julian Eisel commented

2015-06-27 14:30:46 +02:00

Changed status to: 'Open'

Julian Eisel commented

2015-06-27 14:30:46 +02:00

Added subscriber: @JulianEisel

Sebastian Koenig commented

2015-06-27 15:15:03 +02:00

Added subscriber: @sebastian_k

Sebastian Koenig commented

2015-06-27 15:15:03 +02:00

Yeah, I think Rotation/Scale should fall back to incremental
Would this depend on pivot setting? Median, Individual, Active, all this could apply here very nicely
At the moment I am not sure how this is different from 2... :)

1) Yeah, I think Rotation/Scale should fall back to incremental 2) Would this depend on pivot setting? Median, Individual, Active, all this could apply here very nicely 3) At the moment I am not sure how this is different from 2... :)

Julian Eisel commented

2015-06-27 15:23:26 +02:00

Yeah, also thought so, but wanted to get proven that users think so as well. I'm not sure if it wouldn't lead to more issues though... need to test
Indeed, it's basically the same , but since it was being discussed separately in D910 I thought it might be better to mention it separately as well, so people don't think I forgot it ;)

2. Yeah, also thought so, but wanted to get proven that users think so as well. I'm not sure if it wouldn't lead to more issues though... need to test 3. Indeed, it's basically the same , but since it was being discussed separately in [D910](https://archive.blender.org/developer/D910) I thought it might be better to mention it separately as well, so people don't think I forgot it ;)

Julian Eisel commented

2015-06-27 15:23:47 +02:00

Added subscriber: @donfabio

mathieu menuet commented

2015-06-27 18:15:36 +02:00

Added subscriber: @bliblubli

mathieu menuet commented

2015-06-27 18:15:36 +02:00

This comment was removed by @bliblubli

*This comment was removed by @bliblubli*

Campbell Barton commented

2015-06-28 02:20:32 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2015-06-28 02:21:21 +02:00

@bliblubli removed your comment. Asking to work on different improvements - is off topic.

Campbell Barton commented

2015-06-28 03:00:58 +02:00

Heres my suggestion for how absolute grid snapping could work.

Keep current incremental snapping working as-is.
Add a toggle: Absolute Grid Snapping which ensures all transform data is grid aligned (while transforming).
Instead of snapping the input value (the number in the header), it would snap each element to the grid.

I think this is what users expect, the logic from the user side is...

"When this option is enabled, everything is aligned to the grid."

(we already have this for UV's in fact - the Snap to Pixels option).

It can work with scale, rotation... different axis modes too of course. It also resolves the 3 corner cases noted in this task.

The main noticeable difference/drawback with this, is that the relative distances from points will change. So transforming could - for example - make points overlap. But I think for the situations you would want to use this option, its an acceptable tradeoff.

Heres my suggestion for how absolute grid snapping could work. - Keep current incremental snapping working as-is. - Add a toggle: **Absolute Grid Snapping** which ensures all transform data is grid aligned (while transforming). - Instead of snapping the input value *(the number in the header)*, it would snap each element to the grid. I *think* this is what users expect, the logic from the user side is... > "When this option is enabled, everything is aligned to the grid." *(we already have this for UV's in fact - the **Snap to Pixels** option)*. It can work with scale, rotation... different axis modes too of course. It also resolves the 3 corner cases noted in this task. ---- The main noticeable difference/drawback with this, is that the relative distances from points will change. So transforming could - for example - make points overlap. But I think for the situations you would want to use this option, its an acceptable tradeoff.

ronan ducluzeau commented

2015-06-28 11:22:24 +02:00

Added subscriber: @zeauro

ronan ducluzeau commented

2015-06-28 11:22:24 +02:00

We have a grid displayed when we are in ortho views. I think that using this grid in front,top, side views are the most expected cases.
I suggest that rotation and scaling use this grid in ortho views.
Here, the idea is just to choose a point on grid to point at.
I think that brita's user coordinates spaces idea could solve problems for other views.
But for the moment, I suggest to fallback to incremental for perspective views.

We have a grid displayed when we are in ortho views. I think that using this grid in front,top, side views are the most expected cases. I suggest that rotation and scaling use this grid in ortho views. Here, the idea is just to choose a point on grid to point at. I think that brita's user coordinates spaces idea could solve problems for other views. But for the moment, I suggest to fallback to incremental for perspective views.

Paweł Łyczkowski commented

2015-06-28 11:25:31 +02:00

Added subscriber: @PawelLyczkowski-1

Paweł Łyczkowski commented

2015-06-28 11:25:31 +02:00

In #45212#318064, @ideasman42 wrote:
Heres my suggestion for how absolute grid snapping could work.

+1 to that.

Now the GUI/UI part. We can just add a new mode, but it also is an opportunity to revamp it a bit.

Some of these modes are non-exclusive. For instance - incremental scale and rotation are non-exclusive with all other modes (you can rotate in increments and have any other position snapping on).

Vertex, edge, face snapping could be non-exclusive, with lower level elements taking precedent. So if they would all be on, snapping over the face would snap to face, on the edge, edge would take precedent (oven though it's also over a face), and on a vertex - vertex (even though it's also over an edge and a face).

Here is an example of hover regions with all of these turned on:

Grid snapping and element snapping are mutually exclusive I guess - but maybe not: element snapping could be considered lower-level and take precedent over grid snapping when mouse hovering over an element.

Grid snapping and position incremental snapping are definitely exclusive.

They can just override each other - position increment snapping can be just overridden bu the more low-level modes - the grid and element ones.

So, it's a logical problem on how to arrange toggles/combo boxes.

I'll provide a mockup soon.

> In #45212#318064, @ideasman42 wrote: > Heres my suggestion for how absolute grid snapping could work. +1 to that. Now the GUI/UI part. We can just add a new mode, but it also is an opportunity to revamp it a bit. Some of these modes are non-exclusive. For instance - incremental scale and rotation are non-exclusive with all other modes (you can rotate in increments and have any other position snapping on). Vertex, edge, face snapping could be non-exclusive, with lower level elements taking precedent. So if they would all be on, snapping over the face would snap to face, on the edge, edge would take precedent (oven though it's also over a face), and on a vertex - vertex (even though it's also over an edge and a face). Here is an example of hover regions with all of these turned on: ![shot_150628_112059.png](https://archive.blender.org/developer/F198088/shot_150628_112059.png) Grid snapping and element snapping are mutually exclusive I guess - but maybe not: element snapping could be considered lower-level and take precedent over grid snapping when mouse hovering over an element. Grid snapping and position incremental snapping are definitely exclusive. They can just override each other - position increment snapping can be just overridden bu the more low-level modes - the grid and element ones. So, it's a logical problem on how to arrange toggles/combo boxes. I'll provide a mockup soon.

chris huf commented

2015-06-28 13:25:58 +02:00

Added subscriber: @tischbein3-2

chris huf commented

2015-06-28 13:25:58 +02:00

Actually I like how it works already, keeping rotation to incremental is actually the two usage scenarios I would need the most, without changing any settings (= interupting the workflow) . I also think that making everything grid conformal should be a separrate tool (quantize python script). Never encountered any scenario where I actually need to snap to grid during an rotation operation (wich can't be fixed by an additional transform) or realistically using it in the 3d view (In fact this would open a can of worms wich would ultimately lead to the feature request of modos construction planes).

So for me this implementation is close to perfect, and a good base to build upon further due to additional user input over a longer period of time.

Actually I like how it works already, keeping rotation to incremental is actually the two usage scenarios I would need the most, without changing any settings (= interupting the workflow) . I also think that making everything grid conformal should be a separrate tool (quantize python script). Never encountered any scenario where I actually need to snap to grid during an rotation operation (wich can't be fixed by an additional transform) or realistically using it in the 3d view (In fact this would open a can of worms wich would ultimately lead to the feature request of modos construction planes). So for me this implementation is close to perfect, and a good base to build upon further due to additional user input over a longer period of time.

Paweł Łyczkowski commented

2015-06-29 12:29:24 +02:00

So here is the mockup:

The whole menu is fired up in a popup with a button next to the snap toggle in the header. The menu does not close after clicking on a toggle, it closes on RMB click/LMB click outside.

The toggles are mostly non-exclusive. The only exclusive combination is the Grid and Translate in Increments combo - so when Grid is on, Translate in Increments becomes grayed out and inactive. (If there is a way to make them non-exclusive, that would be even better)

The rest of combinations is allowed, and it works like this - the more specific/lower-level an element is, the more important it is; it takes precedent - it's hover-over area is "above" less important hover-over areas. The toggles are organized using this hierarchy - Vertex at the top (most important), Translate in Increments at the bottom (least). We ignore Rotate and Scale since they are non-exclusive with everything.

A simplified explanation - more red hover areas win over less red ones, the toggles turn hover areas on and off : )

So here is the mockup: ![shot_150w629_120247.png](https://archive.blender.org/developer/F198472/shot_150w629_120247.png) The whole menu is fired up in a popup with a button next to the snap toggle in the header. The menu does not close after clicking on a toggle, it closes on RMB click/LMB click outside. The toggles are mostly non-exclusive. The only exclusive combination is the Grid and Translate in Increments combo - so when Grid is on, Translate in Increments becomes grayed out and inactive. (If there is a way to make them non-exclusive, that would be even better) The rest of combinations is allowed, and it works like this - the more specific/lower-level an element is, the more important it is; it takes precedent - it's hover-over area is "above" less important hover-over areas. The toggles are organized using this hierarchy - Vertex at the top (most important), Translate in Increments at the bottom (least). We ignore Rotate and Scale since they are non-exclusive with everything. A simplified explanation - more red hover areas win over less red ones, the toggles turn hover areas on and off : ) ![shot_150629_122715.png](https://archive.blender.org/developer/F198474/shot_150629_122715.png)

chris huf commented

2015-06-29 17:05:39 +02:00

Ok, just an addendum / usage scenario on the snap each element to the grid

Lets say you have a bunch of objects wich have been aligned to each other in a circular way (image one)
and i just want to move all element to a new position via snapping (move it 4 m to the x and 3 to the y axis) Currently I can do this by
set the pivot mode to active / select all and move them accordingly. (image one)
image 3 shows the result I would get if each element is aligned to a grid.

maybe its just me but I really do think the current behaviour as shown in image two is more widely used and needed.
{F198541}{F198543}

Ok, just an addendum / usage scenario on the snap each element to the grid Lets say you have a bunch of objects wich have been aligned to each other in a circular way (image one) and i just want to move all element to a new position via snapping (move it 4 m to the x and 3 to the y axis) Currently I can do this by set the pivot mode to active / select all and move them accordingly. (image one) image 3 shows the result I would get if each element is aligned to a grid. maybe its just me but I really do think the current behaviour as shown in image two is more widely used and needed. {[F198541](https://archive.blender.org/developer/F198541/snap1.jpg)}{[F198543](https://archive.blender.org/developer/F198543/snap2.jpg)}![snap3.jpg](https://archive.blender.org/developer/F198545/snap3.jpg)

Paweł Łyczkowski commented

2015-06-29 17:13:04 +02:00

In #45212#318435, @tischbein3-2 wrote:

Shouldn't this use Pivot Point setting? With Median chosen you get this 2, and with Individual Origins you get 3?

> In #45212#318435, @tischbein3-2 wrote: >![snap2.jpg](https://archive.blender.org/developer/F198543/snap2.jpg) Shouldn't this use Pivot Point setting? With Median chosen you get this 2, and with Individual Origins you get 3?

chris huf commented

2015-06-29 17:17:43 +02:00

good point: currently it does use the median point if you set it to individual origins, but yes, this really would make sense

Campbell Barton commented

2015-06-30 07:10:44 +02:00

@PawelLyczkowski-1, regarding your mockup.

While its fine to suggest such UI changes, I don't think grid snapping behavior depends on re-arranging settings as you propose.

So I rather defer larger UI changes and first find a good solution for grid snapping.

Also not sure what you mean by red hovering graphic.

@tischbein3-2 Not sure about having grid snapping use the pivot point, This is how it worked, but it meant that you would keep having to switch to 'active' pivot, whenever you wanted to keep multiple objects snapped to the grid.

I think, in the circumstances where this feature is wanted, users just want to keep everything grid snapped - so having to setup transform options to achieve this is more annoying then helpful.

@PawelLyczkowski-1, regarding your mockup. While its fine to suggest such UI changes, I don't think grid snapping behavior depends on re-arranging settings as you propose. So I rather defer larger UI changes and first find a good solution for grid snapping. Also not sure what you mean by red hovering graphic. ---- @tischbein3-2 Not sure about having grid snapping use the pivot point, This is how it worked, but it meant that you would keep having to switch to 'active' pivot, whenever you wanted to keep multiple objects snapped to the grid. I *think*, in the circumstances where this feature is wanted, users just want to keep everything grid snapped - so having to setup transform options to achieve this is more annoying then helpful.

Paweł Łyczkowski commented

2015-06-30 10:28:02 +02:00

Also not sure what you mean by red hovering graphic.

This is just a visualization on how the active areas would look with multiple snapping options on. Not visible to the user. You hover the mouse over one of the grid points, you get grid snapping. You do that over the center of the face, you get face snapping. You enter with the mouse in the redder edge area, you get edge snapping, and so on. The mockup just shows how they overlay regarding their size and priority.

I think, in the circumstances where this feature is wanted, users just want to keep everything grid snapped.

I respectfully disagree. I would say that both scenarios will happen. And when transforming multiple objects, keeping them all snapped to the grid will be the less desired one IMO. Why would they do that? It would destroy the object setup they have (like in @tischbein3-2's example) - a house, character, multi object environment piece etc in Object mode, and their mesh in Edit mode.

> Also not sure what you mean by red hovering graphic. This is just a visualization on how the active areas would look with multiple snapping options on. Not visible to the user. You hover the mouse over one of the grid points, you get grid snapping. You do that over the center of the face, you get face snapping. You enter with the mouse in the redder edge area, you get edge snapping, and so on. The mockup just shows how they overlay regarding their size and priority. > I *think*, in the circumstances where this feature is wanted, users just want to keep everything grid snapped. I respectfully disagree. I would say that both scenarios will happen. And when transforming multiple objects, keeping them all snapped to the grid will be the less desired one IMO. Why would they do that? It would destroy the object setup they have (like in @tischbein3-2's example) - a house, character, multi object environment piece etc in Object mode, and their mesh in Edit mode.

ronan ducluzeau commented

2015-06-30 12:08:14 +02:00

In #45212#318591, @PawelLyczkowski-1 wrote:

I think, in the circumstances where this feature is wanted, users just want to keep everything grid snapped.

I respectfully disagree. I would say that both scenarios will happen. And when transforming multiple objects, keeping them all snapped to the grid will be the less desired one IMO. Why would they do that? It would destroy the object setup they have (like in @tischbein3-2's example) - a house, character, multi object environment piece etc in Object mode, and their mesh in Edit mode.

I agree with plyczkowski. The way, it is in trunk does not make sense. Shape is destroyed in edit mode.
You may want to move center or active point of a circle onto a point of grid. It does not mean that you want to transform circle selection into square.

I think that what people want is to avoïd to do :
click to position Cursor
Shift S to snap Cursor to grid
shift S to snap Selection to Cursor(Offset).

They just want directly to snap pivot of selection to grid.

> In #45212#318591, @PawelLyczkowski-1 wrote: >> I *think*, in the circumstances where this feature is wanted, users just want to keep everything grid snapped. > > I respectfully disagree. I would say that both scenarios will happen. And when transforming multiple objects, keeping them all snapped to the grid will be the less desired one IMO. Why would they do that? It would destroy the object setup they have (like in @tischbein3-2's example) - a house, character, multi object environment piece etc in Object mode, and their mesh in Edit mode. I agree with plyczkowski. The way, it is in trunk does not make sense. Shape is destroyed in edit mode. You may want to move center or active point of a circle onto a point of grid. It does not mean that you want to transform circle selection into square. I think that what people want is to avoïd to do : click to position Cursor Shift S to snap Cursor to grid shift S to snap Selection to Cursor(Offset). They just want directly to snap pivot of selection to grid.

Campbell Barton commented

2015-07-01 11:01:13 +02:00

Once we get into opinions about what users want - its very open to interpretation.

I would rather see example of usage where this feature is needed. (not just isolated examples, ... since many arbitrary features can be useful sometimes),
but projects where its useful and where the limits of 2.75x become apparent.

Other options are still open, we can always have multiple behaviors for grid snapping too.

But would prefer to get some testing with current option ~ which is quite straightforward to use (no messing about with pivot points just to ensure data is grid aligned).

Once we get into opinions about what users want - its very open to interpretation. I would rather see example of usage where this feature is needed. *(not just isolated examples, ... since many arbitrary features can be useful *sometimes*)*, but projects where its useful and where the limits of 2.75x become apparent. Other options are still open, we can always have multiple behaviors for grid snapping too. But would prefer to get some testing with current option ~ which is quite straightforward to use (no messing about with pivot points just to ensure data is grid aligned).

ronan ducluzeau commented

2015-07-01 12:03:56 +02:00

I would rather see example of usage where this feature is needed. (not just isolated examples, ... since many arbitrary features can be useful sometimes),
but projects where its useful and where the limits of 2.75x become apparent.

Your request of examples is irrelevant.
I precisely explained that limit of 2.75 is to do 3 operations in order to snap an element that is not already in the grid when everybody expects one.
And the fact that blender add new primitives to 3DCursor position, which is moved frequently ramdomly by a simple left click is a well known reason of users frustration.

In #45212#318822, @ideasman42 wrote:
Once we get into opinions about what users want - its very open to interpretation.

Seriously, did you play a little bit with your monster ?

Why people who want to snap things to be precise would like to obtain :
_a non uniform scale without precising any axis.

_ a rotation that destroys shape of their selection.

_a translation that also creates shapes with no sense.

Do you really think that people who applause to annoucement of absolute grid snapping have in minds something that only give a satisfying result for moving elements one by one ?

> I would rather see example of usage where this feature is needed. *(not just isolated examples, ... since many arbitrary features can be useful *sometimes*)*, > but projects where its useful and where the limits of 2.75x become apparent. Your request of examples is irrelevant. I precisely explained that limit of 2.75 is to do 3 operations in order to snap an element that is not already in the grid when everybody expects one. And the fact that blender add new primitives to 3DCursor position, which is moved frequently ramdomly by a simple left click is a well known reason of users frustration. > In #45212#318822, @ideasman42 wrote: > Once we get into opinions about what users want - its very open to interpretation. Seriously, did you play a little bit with your monster ? Why people who want to snap things to be precise would like to obtain : _a non uniform scale without precising any axis. ![scale.jpg](https://archive.blender.org/developer/F199103/scale.jpg) _ a rotation that destroys shape of their selection. ![rotation.jpg](https://archive.blender.org/developer/F199107/rotation.jpg) _a translation that also creates shapes with no sense. ![translation.jpg](https://archive.blender.org/developer/F199109/translation.jpg) Do you really think that people who applause to annoucement of absolute grid snapping have in minds something that only give a satisfying result for moving elements one by one ?

Paweł Łyczkowski commented

2015-07-01 12:49:10 +02:00

In #45212#318822, @ideasman42 wrote:
I would rather see example of usage where this feature is needed. (not just isolated examples, ... since many arbitrary features can be useful sometimes),

I'd say the situation is reversed for me - I don't see many examples where keeping everything grid-snapped is useful. I guess if someone got his objects slightly off the grid in different directions somehow then the Individual Origins behaviour would be useful to get them realigned, but that's all that comes to mind.

Examples for when other pivots than Individual is useful:

Object mode:

A piece of modular grid aligned environment fragment composed of many objects. You just need one that has it's origin on the grid, and you can select it last and use the Active mode. Or just set all of their Origins on the grid and use median. Modular environments are the number one usage of grid snapping as far as I know.
Align something to the grid without changing any origins - just place the cursor on the point you want aligned and set the Pivot to 3d Cursor.

Edit mode:

Here the individual origins is only useful if your model's vertices are lying on the grid - otherwise it will get deformed during transformation. And when your vertices are lying on the grid, you don't need Individual Origins anyway - you can use Active Element for the same effect.

Active Element is also great for placing your model on the grid - just select a vertex in the corner of your model, where usually the Origin is placed in modular systems, and move that point, with all the others, to the existing Origin. (It's similar to placing Origin on a vertex, but can be easier sometimes this way)

> In #45212#318822, @ideasman42 wrote: > I would rather see example of usage where this feature is needed. *(not just isolated examples, ... since many arbitrary features can be useful *sometimes*)*, I'd say the situation is reversed for me - I don't see many examples where keeping everything grid-snapped is useful. I guess if someone got his objects slightly off the grid in different directions somehow then the Individual Origins behaviour would be useful to get them realigned, but that's all that comes to mind. Examples for when other pivots than Individual is useful: Object mode: - A piece of modular grid aligned environment fragment composed of many objects. You just need one that has it's origin on the grid, and you can select it last and use the Active mode. Or just set all of their Origins on the grid and use median. Modular environments are the number one usage of grid snapping as far as I know. - Align something to the grid without changing any origins - just place the cursor on the point you want aligned and set the Pivot to 3d Cursor. Edit mode: Here the individual origins is only useful if your model's vertices are lying on the grid - otherwise it will get deformed during transformation. And when your vertices are lying on the grid, you don't need Individual Origins anyway - you can use Active Element for the same effect. - Active Element is also great for placing your model on the grid - just select a vertex in the corner of your model, where usually the Origin is placed in modular systems, and move that point, with all the others, to the existing Origin. (It's similar to placing Origin on a vertex, but can be easier sometimes this way)

Campbell Barton commented

2015-07-01 13:22:21 +02:00

@zeauro, there is no need for sarcastic/snarky comments.

I'm well aware of the behavior your mention, if you want to help with development, stay to-the-point and constructive.

Of course with a large grid its possible to show examples causing significant distortion.
In that case you're not working to a grid thats a useful size, so: resize the grid, or don't enable the option.

In #45212#318829, @PawelLyczkowski-1 wrote:

In #45212#318822, @ideasman42 wrote:
I would rather see example of usage where this feature is needed. (not just isolated examples, ... since many arbitrary features can be useful sometimes),

I'd say the situation is reversed for me - I don't see many examples where keeping everything grid-snapped is useful. I guess if someone got his objects slightly off the grid in different directions somehow then the Individual Origins behaviour would be useful to get them realigned, but that's all that comes to mind.

Yep, but some users make entire models (or sections of a model), levels etc. which are grid aligned, so its not necessarily a corner case.

Examples for when other pivots than Individual is useful:

Object mode:

A piece of modular grid aligned environment fragment composed of many objects. You just need one that has it's origin on the grid, and you can select it last and use the Active mode. Or just set all of their Origins on the grid and use median. Modular environments are the number one usage of grid snapping as far as I know.

Align something to the grid without changing any origins - just place the cursor on the point you want aligned and set the Pivot to 3d Cursor.

Edit mode:

Here the individual origins is only useful if your model's vertices are lying on the grid - otherwise it will get deformed during transformation. And when your vertices are lying on the grid, you don't need Individual Origins anyway - you can use Active Element for the same effect.

Active Element is also great for placing your model on the grid - just select a vertex in the corner of your model, where usually the Origin is placed in modular systems, and move that point, with all the others, to the existing Origin. (It's similar to placing Origin on a vertex, but can be easier sometimes this way)

Good points, which makes me think having both options could be useful... though this does get a bit fuzzy from a UI perspective.

@zeauro, there is no need for sarcastic/snarky comments. I'm well aware of the behavior your mention, if you want to help with development, stay to-the-point and constructive. Of course with a large grid its possible to show examples causing significant distortion. In that case you're not working to a grid thats a useful size, so: resize the grid, or don't enable the option. ---- > In #45212#318829, @PawelLyczkowski-1 wrote: >> In #45212#318822, @ideasman42 wrote: >> I would rather see example of usage where this feature is needed. *(not just isolated examples, ... since many arbitrary features can be useful *sometimes*)*, > > I'd say the situation is reversed for me - I don't see many examples where keeping everything grid-snapped is useful. I guess if someone got his objects slightly off the grid in different directions somehow then the Individual Origins behaviour would be useful to get them realigned, but that's all that comes to mind. Yep, but some users make entire models (or sections of a model), levels etc. which are grid aligned, so its not necessarily a corner case. > Examples for when other pivots than Individual is useful: > > Object mode: > > - A piece of modular grid aligned environment fragment composed of many objects. You just need one that has it's origin on the grid, and you can select it last and use the Active mode. Or just set all of their Origins on the grid and use median. Modular environments are the number one usage of grid snapping as far as I know. > > - Align something to the grid without changing any origins - just place the cursor on the point you want aligned and set the Pivot to 3d Cursor. > > Edit mode: > > Here the individual origins is only useful if your model's vertices are lying on the grid - otherwise it will get deformed during transformation. And when your vertices are lying on the grid, you don't need Individual Origins anyway - you can use Active Element for the same effect. > > - Active Element is also great for placing your model on the grid - just select a vertex in the corner of your model, where usually the Origin is placed in modular systems, and move that point, with all the others, to the existing Origin. (It's similar to placing Origin on a vertex, but can be easier sometimes this way) Good points, which makes me think having both options could be useful... though this does get a bit fuzzy from a UI perspective.

ronan ducluzeau commented

2015-07-01 13:51:52 +02:00

In #45212#318831, @ideasman42 wrote:
@zeauro, there is no need for sarcastic/snarky comments.

I am sorry.
But when you ask to me examples to disonsider the problem I clearly expose while you are refusing to expose examples where current behaviour could make sense; I feel it like a lack of respect.

Of course with a large grid its possible to show examples causing significant distortion.
In that case you're not working to a grid thats a useful size, so: resize the grid, or don't enable the option.

It is the bad faith.
If you take a look at hemisphere examples, distortion occurs on any model that don't have a cubic shape.
You can do the test with a circle, you will obtain a non pertinent shape at any grid scale.

If the goal is simply to use it, to have a more intuitive tool to align objects in object mode; you 'd rather hide it in edit mode.

Your implementation is inspired by "snap to pixels" option in UVs menu.
In UVeditor, it is not confused with increment snap.
I don't see a reason to introduce confusion in 3Dview header.

We are using snapping to stick to a reference.
In 3DView, there is no image.
The idea of grid as a reference is simply to align and to respect spacing, proportions.
Current behaviour only produce a result sticked to a polygonal shape or distribution.
Maybe, it is an expected constraints for dealing with a navigation mesh or a complex setup based on polygons.
It is clearly not something commonly used that requires to be exposed in header.

> In #45212#318831, @ideasman42 wrote: > @zeauro, there is no need for sarcastic/snarky comments. > I am sorry. But when you ask to me examples to disonsider the problem I clearly expose while you are refusing to expose examples where current behaviour could make sense; I feel it like a lack of respect. >Of course with a large grid its possible to show examples causing significant distortion. >In that case you're not working to a grid thats a useful size, so: resize the grid, or don't enable the option. It is the bad faith. If you take a look at hemisphere examples, distortion occurs on any model that don't have a cubic shape. You can do the test with a circle, you will obtain a non pertinent shape at any grid scale. If the goal is simply to use it, to have a more intuitive tool to align objects in object mode; you 'd rather hide it in edit mode. Your implementation is inspired by "snap to pixels" option in UVs menu. In UVeditor, it is not confused with increment snap. I don't see a reason to introduce confusion in 3Dview header. We are using snapping to stick to a reference. In 3DView, there is no image. The idea of grid as a reference is simply to align and to respect spacing, proportions. Current behaviour only produce a result sticked to a polygonal shape or distribution. Maybe, it is an expected constraints for dealing with a navigation mesh or a complex setup based on polygons. It is clearly not something commonly used that requires to be exposed in header.

chris huf commented

2015-07-01 18:05:44 +02:00

sorry for the late reply:

I think, in the circumstances where this feature is wanted, users just want to keep everything grid snapped - so having to setup transform options to achieve this is more annoying then helpful.

sure but point is: with proposed way (individual origins = all elements are snapped to grid), you get both behaviours. while your proposal does locks out an imho needed behaviour. Also it is logical from the way how blender does all snapping modes work:
If you move your objects in face snap mode, not all points get snapped to the face.

As for an example: take a wall with a window (modeled frame glass etc) in it, wich you want to shift a few meters on the left: The whole window (due to its small structure will be distorted through snapping. (You need a big grid size to cover the distance).

I know what behaviour your are looking for, but I really do think these are a minority and only applicable on item level.

And for whats its worth: In my whole software-live I almost never encountered a snapping behaviour you proposed, (maya comes close to your proposal,, but it also has the option for the "normal" behaviour)

sorry for the late reply: > I *think*, in the circumstances where this feature is wanted, users just want to keep everything grid snapped - so having to setup transform options to achieve this is more annoying then helpful. sure but point is: with proposed way (individual origins = all elements are snapped to grid), you get both behaviours. while your proposal does locks out an imho needed behaviour. Also it is logical from the way how blender does all snapping modes work: If you move your objects in face snap mode, not all points get snapped to the face. As for an example: take a wall with a window (modeled frame glass etc) in it, wich you want to shift a few meters on the left: The whole window (due to its small structure will be distorted through snapping. (You need a big grid size to cover the distance). - I know what behaviour your are looking for, but I really do think these are a minority and only applicable on item level. And for whats its worth: In my whole software-live I almost never encountered a snapping behaviour you proposed, (maya comes close to your proposal,, but it also has the option for the "normal" behaviour)

Campbell Barton commented

2015-07-01 18:37:35 +02:00

Ok, read the replies and it seems guys have more sophisticated tasks then making minecraft levels (absolute snapping) :)

So, reverted to original behavior of D910... with minor changes.
5edff01920

Instead of a new snapping mode, this uses a toggle next to the Incremental
Noted in the tool-tip that this snaps to absolute grid based on the pivot point. ... note that Im not so keen on using the pivot point as the snap source... although once known, it can be effective too.

So the 3 corner cases from this original task are now back, but not sure we necessarily have to solve them all, since some options logically exclude each other (absolute grid & Non-Grid Aligned Transformation Orientations).

Ok, read the replies and it seems guys have more sophisticated tasks then making minecraft levels *(absolute snapping)* :) So, reverted to original behavior of [D910](https://archive.blender.org/developer/D910)... with minor changes. 5edff01920 - Instead of a new snapping mode, this uses a toggle next to the **Incremental** - Noted in the tool-tip that this snaps to absolute grid based on the pivot point. *... note that Im not so keen on using the pivot point as the snap source... although once known, it can be effective too.* ---- So the 3 corner cases from this original task are now back, but not sure we necessarily have to *solve* them all, since some options logically exclude each other (absolute grid & **Non-Grid Aligned Transformation Orientations**).

chris huf commented

2015-07-02 06:17:11 +02:00

Thats cool, thanks !

Julian Eisel commented

2015-07-06 20:47:46 +02:00

So it seems like @ideasman42 has found a behavior that people like? If so, this can be closed.

Jonathan Williamson commented

2015-07-06 23:25:03 +02:00

Added subscriber: @JonathanWilliamson

Jonathan Williamson commented

2015-07-06 23:25:03 +02:00

I realize I'm late to the party, just wanted to say the latest iteration in 5edff01920 is really nice and makes good sense

The only thing off that I can find is that setting the Individual Origins as the pivot point does not seem to work with Absolute grid snapping; but rest of the pivot point options do work correct it seems.

I realize I'm late to the party, just wanted to say the latest iteration in 5edff01920 is really nice and makes good sense The only thing off that I can find is that setting the **Individual Origins** as the pivot point does not seem to work with Absolute grid snapping; but rest of the pivot point options do work correct it seems.

Julian Eisel commented

2015-09-05 23:45:34 +02:00

Added icon for incremental grid snapping 14dd88e817

Added icon for incremental grid snapping 14dd88e817

Julian Eisel commented

2015-09-06 00:36:50 +02:00

Tested, and can confirm that it works nicely, maybe except of Individual Origins mode. I would in this case expect all objects jump to closest grid segment, so that distances change.

P255: Alternative behavior for absolute grid snapping w/ individual origins

diff --git a/source/blender/editors/transform/transform_generics.c b/source/blender/editors/transform/transform_generics.c
index 74dbc09..14f3a65 100644
--- a/source/blender/editors/transform/transform_generics.c
+++ b/source/blender/editors/transform/transform_generics.c
@@ -709,6 +709,12 @@ static void recalcData_objects(TransInfo *t)
 {
        Base *base = t->scene->basact;
 
+       if (t->state != TRANS_CANCEL) {
+               if (t->around == V3D_LOCAL && t->tsnap.mode == SCE_SNAP_MODE_INCREMENT && t->tsnap.snap_spatial_grid) {
+                       applyGridAbsolute(t);
+               }
+       }
+
        if (t->obedit) {
                if (ELEM(t->obedit->type, OB_CURVE, OB_SURF)) {
                        Curve *cu = t->obedit->data;

Tested, and can confirm that it works nicely, maybe except of *Individual Origins* mode. I would in this case expect all objects jump to closest grid segment, so that distances change. [P255: Alternative behavior for absolute grid snapping w/ individual origins](https://archive.blender.org/developer/P255.txt) ``` diff --git a/source/blender/editors/transform/transform_generics.c b/source/blender/editors/transform/transform_generics.c index 74dbc09..14f3a65 100644 --- a/source/blender/editors/transform/transform_generics.c +++ b/source/blender/editors/transform/transform_generics.c @@ -709,6 +709,12 @@ static void recalcData_objects(TransInfo *t) { Base *base = t->scene->basact; + if (t->state != TRANS_CANCEL) { + if (t->around == V3D_LOCAL && t->tsnap.mode == SCE_SNAP_MODE_INCREMENT && t->tsnap.snap_spatial_grid) { + applyGridAbsolute(t); + } + } + if (t->obedit) { if (ELEM(t->obedit->type, OB_CURVE, OB_SURF)) { Curve *cu = t->obedit->data; ```

Paweł Łyczkowski commented

2015-09-07 21:13:27 +02:00

@ideasman42 What is the reasoning for adding this as a toggle next to the Incremental mode, instead a new snapping mode?

I would in this case expect all objects jump to closest grid segment, so that distances change.

+1 to that.

@ideasman42 What is the reasoning for adding this as a toggle next to the Incremental mode, instead a new snapping mode? >I would in this case expect all objects jump to closest grid segment, so that distances change. +1 to that.

Julian Eisel commented

2016-07-05 20:26:26 +02:00

What's the status on this? Do we need to keep the task open? Has the issue with individual origins been addressed?

Russell commented

2020-08-22 07:09:53 +02:00

Added subscriber: @Russ1642

Russell commented

2020-08-22 07:10:17 +02:00

Removed subscriber: @Russ1642

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Absolute Grid Snapping Corner Cases #45212

Absolute Grid Snapping Corner Cases

Corner Cases: