Page MenuHome

Absolute grid snapping
Closed, InvalidPublicPATCH


this patch adds another snap element type (GRID, which is actually already used in the node editor for snapping). Instead of snapping in increments relative to the current location, it will snap to increments based on the origin (0, 0, 0) (absolute).

This allows is for aligning objects on the grid more easily. This is especially useful for game development with modular designs.

I implemented the functionality in the applyGridIncrement function.
As to the problems of the current implementation:
I tried to respect the transform constrains but for now only constraining to the global transform orientation will make much sense since the goal of this snapping type is to absolutely snap to the global grid.

Another problem is the UI. Here is what it looks like right now:

As you can see GRID and INCREMENT share the same icon

Either a new icon needs be designed or my proposal would be to add a checkbox to toggle between absolute and relative/incremental grid snapping.

The other problem is as initially mentioned that I reused the grid snap element currently used by the node editor.

Revisions and Commits

Event Timeline

Fabio Arnold (donfabio) raised the priority of this task from to 90.
Fabio Arnold (donfabio) updated the task description. (Show Details)
Fabio Arnold (donfabio) edited a custom field.

Some preliminary comments in the code:

Instead of

if snap_element != 'INCREMENT' and snap_element != 'GRID':

you can do:

if snap_element not in {'INCREMENT', 'GRID'}:

The same applies to the C-code, so instead cases like:

if (!(t->tsnap.mode != SCE_SNAP_MODE_INCREMENT && t->tsnap.mode != SCE_SNAP_MODE_GRID && activeSnap(t))) {

you can do

if (!(!ELEM(t->tsnap.mode, SCE_SNAP_MODE_INCREMENT, SCE_SNAP_MODE_GRID) && activeSnap(t))) {

Here you can also invert the condition to avoid !!.

I don't really understand what exact issue with supporting constraints is?

As for interface, making it a checkbox seems to be wrong -- grid snapping is not a part of incremental snapping IMO. But here would like to hear proposal from our UI team.

Sergey Sharybin (sergey) lowered the priority of this task from 90 to Normal.Nov 18 2014, 10:31 AM

Fantastic! I've been hoping someone would tackle this, thanks so much.

I prefer the original implentation over the toggl. As Sergey pointed out, it's not part of incremental snapping. Iconwise we could change Increment to either a numerical representation or maybe a grid of dots (to show the steps, but not invoke the link to the grid?).

Sergey: I adopted your logic improvements. Didn't know about the ELEM macro. Also I thought the double negative (!(a != b && c)) was intentional and easier to grasp for the one who wrote it so I kept it originally.

The issue with the constraints is I handle them in the applyGridIncrement function itself (right now only 'APPLY' and the three axis). I don't know if there's more I should check and whether the function is the best place to check.

For the UI I can see why you want them as separate types. The incremental doesn't really behave as "relative grid snapping".

Michael: Thanks. This is also a feature I always wanted in Blender myself. :)

Another thing I would like to see is a custom grid snapping factor. So you could snap your vertices to 1/8 of a Blender unit without scaling the object for example. Right now we only have these SMALL_GEARS and BIG_GEARS types which respectively map to a factor of 0.1 and 1.0.
Could we use a numerical input next to the snap buttons or would that be to too cluttering/ugly?

The most logical way would be to adjust the grid itself. Otherwise I think we're overcomplicating a feature that's really only about snapping to the grid. The 0.1-version is just a nice extra that's consistent program-wide and the user would expect to have it.

I agree.

I think there should somehow be a custom amount of grid subdivisions configurable by the user like 8 or 16 instead of only 10. This would also mean to change the hardcoded 0.1.

But that's certainly for another task.

We should avoid adding more elements to the 3D View header, so adding it to the Snap menu is the better solution. @Paweł Łyczkowski (plyczkowski), Icon City is your kingdom, right ;) ?

@Jonathan Williamson (carter2422) and @venomgfx, goal for 2.73? I can handle review.

I made a quick icon sketch:

On the left is absolute grid snapping on the right is incremental.

When using the absolute grid the object will snap to the grid. That's why the sphere in the icon is off center (I also moved the grid lines by 1 pixel to match the center of the blue dot). The idea is when using incremental the object keeps its current position and moves from its current position in increments. That's why it's in the center of the icon.

The icon needs work because currently it's bigger than 16x16...

I've been wishing to have this in Blender for some time now. Great work!

I agree that Grid and Increment should each be its own option, it fits better into the existing interaction system.

The icon looks good to me, but would probably need to be checked with the UI team, since it re-purposes an already existing icon.

Thanks for tackling this @Fabio Arnold (donfabio), I will try and review the functionality and UI in the next few days. This has been needed for some time now.

@Fabio Arnold (donfabio) this should probably be a diff, rather than a tracker task? Easier to make review of the code, see .

Bastien Montagne (mont29) changed the task status from Unknown Status to Unknown Status.Nov 21 2014, 7:49 PM
Bastien Montagne (mont29) claimed this task.

Thanks, 'remapped' everyone to the diff, and closing this task now! :)