Dev:Source/Development/Proposals/Advanced snapping system

This is a proposal for an more flexible snapping system together with a minor tweak to current cursor transform, to make snapping possibilities wider and faster. It has been written as an idea to be talked about and maybe picked up by some developer or as a GSOC project some year. I have written it down because I noticed there are several snapping systems currently(object/editmode snap to vertex, Apricot snap to ground, editmode retopo), and I think it can be quite confusing and non consistent for users, so I thought at least write ideas down and let people vote/talk about it on blenderstorm.

Basic idea

The new system should enable possibly all types of geometry+grid being snappable. The "snappable features" would be enabled to work together instead of excluding each other right now(vertex snap excludes grid snapping).The other part is a different snap center definition.

The list of what could be snappable:

Point features:

• Vertices,curve points,nurbs points
• object centers
• midpoints(weighted midpoints of edges, faces, curvesegments)

lines,curves:

• edges
• nurbs edges

Surfaces:

• faces
• nurbs surfaces
• metaballs

grid

maybe more?

Cursor snapping

cursor snapping could define quickly alternative transform centers, while preserving accuracy of transform. The result of such change would be also dropping out current possibilities "Active, Median, Center, Closest", which can be a little confusing, since it's a duplicate system for setting transform center with the main transform options(for me it's confusing a lot, but i can imagine for some people it can be the better workflow). An example of how snapping a tree to ground could work: User ctrl* clicks a vertex on the object to be transformed(tree where the roots start). The cursor snaps on the vertex. Then he grabs the tree and because the surface snapping is on, he presses ctrl and the tree snaps to the ground, but exactly with the vertex where the cursor got snapped, so the roots are underground, trunk over ground. By now, it would either snap with the center(so the tree would dive deep into ground or wherever it has it's center), or it would snap with "nearest", so it would snap to ground, but with roots still outside over ground.

Currently, the cursor would stay on it's location also after transform. I propose that the cursor could have a property "snapped", at least during an object/editmode selection is the same, and would transform together with the snapped - to vertex. after another selection is done, the cursor gets freed.

Notice to shortcut:ctrl+click would be consistent with rest of UI, but is taken by fast extrude in editmode.

An alternative to this would be storing this transform center as an alternate pivot of the object, writing this down although I dunno how this would work best.

Interface

this is how the snapping system could show in header, icons are just simple draft:

How could that work in code:

I am not a real C coder(although have some experience with it and added some very little code parts to blender too). I think the system could work like this: after ctrl gets pressed, the system builds a "snapping map" for the current camera-view angle. As the user moves the object, the system gets always the right feature from the map with mouse position and performs snapping. It checks what types of snapping are on, and build a 2d representation of the view, which is filled with areas for snapping.

There are priorities for snapping (customizable?), so areas for snapping have a hierarchy: grid, before it surfaces, then edges, and verts/points on top. By this map, blender can decide to which feature to snap, when the mouse is hovering over it. There's a property for "snapping radius", which is defined in pixels around the mouse, but practically this gets reflected already in building up the snapping map, where the area of each non-surface feature grows by the radius in the map(like dilate filter on image).

I guess snapping map could possibly work also with multiple objects(see ideasman42's "snap to ground" blenderstorm idea and its comments), but there could be troube with having many objects selected and some of them being out of view.This case could be solved just by not snapping outside objects at all, or keeping some "drop to ground" feature still outside this system, as ideasman42 already implemented it.

The image below shows a sample snapping map representation. notice that occlusion order vertex->edge->surface->grid, which would be optionally customizable.The map is though z-buffer aware, so front vetices would also be on top, and vertices occluded by surface wouldn't be taken into account in this case.

As I read through my text, I can see the occlusion thingy isn't explained really well still. Have to make better picture yet.

Performance:

It's higly probable, that this system could get slow on complicated scenes. Because of it, objects could have a new property "snappable", which could include/exclude them from the snapping map. It could be reflected also in outliner next to renderable/selectable/hidden/->snappable. In future this could be reflected in some more advanced layer system too, aka snappability per layer.

Snap-ability per object in outliner:

Comments, Discussion

feel free to write comments here.