Page MenuHome

Wrong snapping (active) in 2.71 (no active verts after extrusion, fallback snap median broken)
Closed, ResolvedPublic


System Information
Linux Mint x64 (ubu 13.04), nvidia gtx560 (driver version 331.10)

Blender Version
Broken: 2.71

Short description of error
Wrong snapping. Just try next steps in 2.69 and then in 2.71

Exact steps for others to reproduce the error

  1. open the attached file. two vertices are already selected
  2. extrude them along the Y axis and snap to any vertex right to them in current viewport (E - Y - (hold Ctrl to snap) - (move mouse over the vertex))

In the 2.7 and older version selected vertexes will snap correctly and in the 2.71 they will fly away on the double distance.

Event Timeline

Maxim Tkachenko (maleficmax) created this task.
Maxim Tkachenko (maleficmax) raised the priority of this task from to Needs Triage by Developer.
Niko Leopold (mangostaniko) triaged this task as Confirmed, Medium priority.

confirmed on 2.71, Ubuntu 12.04 (elementary os).

seems to happen with 'snap active to target' only, and yeah, only when extruded.
as a workaround you may use the other options (median, center, closest).
also doesnt seem like double distance, but rather a constant offset (couldnt yet figure out what that offset depends on however).

will have a look at this.

This comment has been deleted.
Niko Leopold (mangostaniko) renamed this task from Wrong snapping in 2.71 to Wrong snapping in 2.71 (no active verts/edges after extrusion).

obviously the active vertex/edge simply is not set after extrusion, if you look for the white (active) dot/edge, it disappears after extrusion.

i wonder if this is intentional? when extruding faces a new active face is set, when extruding edges and vertices none is set active.
personally, i feel that to update the active element would be good, as many people might not be aware of the meaning of active and are confused by incoherent results.
another solution would be to snap to selected, when no elements are active.

or are there some cases when its necessary to have no active vertex/edge after extrusion? otherwise i would feel that it cant hurt..

It has to be fixed, it is impossible to extrude in architecture now :(
And there were no active elements in the older versions. And everything worked great. Logically.
Please, fix it.

extruding works fine here, i assume you mean the snapping. did you try changing the snap target setting (right of the magnet symbol) from 'active' to something else? That should be a good workaround for most situations.

since the snapping in 2.69 seems to snap at 'median' when set to 'active' but none are active.
i think thats quite reasonable (and maybe better than assigning an active vertex). i hope that i can get some opinion of more experienced blender devs, i especially wonder whether the functionality was deliberately changed or by accident.
for now ill try to get to how it was in 2.69, i.e. snap median in 'active' mode when none are active.

I agree with mangostaniko.
There is no bug. Just a bad use of snapping tool.
The interest of active element is restricted to object mode since a dev did a change that does not allow to have an unselected active face/edge or vert.
There is no chance to be able snap something on an element that is moving as a member of transformed selection.

@Maxim Tkachenko (maleficmax), change Active to Closest and it would work as you want. It was probably changed by a alt+wheel accident.

No logic here :(
I use it so often (every day since I learned snapping one million years ago) and now you say, that it is not a bug, but a feature... Just today it threw me away from the work process nearly 10 times...
Some of the newly extruded vertices has to be active. What sense in keeping old vertices active in this situation?
But you are the bosses, of course :(

Sorry for my english)

no bosses, most of the guys here are volunteers who just want to help.
the question is whether we can help at all.
sorry to ask, is the difference between active and selected clear? as zeauro mentioned, using 'closest' you can get the functionality you want. otherwise you can just mark one of the selected vertices after extruding as active using ctrl-shift-click or similar.

as i said, ill look into getting back to 2.69 functionality where it falls back to median when you have no active vertex in the selection but im not sure if it would get accepted.

Niko Leopold (mangostaniko) renamed this task from Wrong snapping in 2.71 (no active verts/edges after extrusion) to Wrong snapping in 2.71 (no active verts after extrusion, snapping fallback to median broken).
Niko Leopold (mangostaniko) renamed this task from Wrong snapping in 2.71 (no active verts after extrusion, snapping fallback to median broken) to Wrong snapping (active) in 2.71 (no active verts after extrusion, fallback snap median broken).

ok i think i found what i would consider a bug. it seems like the fallback to snap median from snap active when none are active is actually intended and implemented, but its broken by a tiny piece of code.

since this is my first bug fix, ill find out how to post a diff and write all the details as soon as i have proper internet access (hopefully tomorrow).

Sorry, I did a confusion not about the meaning of active but about the snapping target.

In fact, I am not used to use it.
I worked so many years only with shift s and active element as pivot point that even if it is broken, I would never say that it is impossible to work.
I made a rush at giving a workaround to maleficmax that reacted as he was playing his life.

There is only one active vertex, edge or face at a time and it dissappears after extrusion. So, no active target is available and then, snapping acts like median.
But snapping to active target is not broken when one element is active.

I don't see how and why it could be annoying to have an active element after extrusion.
Except if user have it as pivot point and do a scale or rotation. But user can choose an appropriate pivot point.

>>So, no active target is available and then, snapping acts like median.
Yes, it has to be.
Here are screenshots, this one shows what i am extruding
and this one shows where everything flies away and the snapping point
and this is how it used to be

It seems that problem is relative to default cube.
If you edit another primitive; snap active to target have no offset and is snapping to median after an extrusion.

Even in your .blend, if you delete part of mesh that represent a screw or a nut (I dont know); snap is working correctly.

Yes, it happens not every time. In the default cube exuded vertices can even get only half way to the selected snap point) Not the double way, like my example does.

here it was broken for all meshes, the problem was that when none are active, it used the center of the active face (even if in vertex/edge selection!) as a replacement. just 4 lines of code caused this and they are commented with /* no */ so it seems a bit questionable. a fallback to snap median is actually implemented, but this 'replacement' bypassed it. after deleting those lines, it works very well here, falling back to snap median as intended by the original developer and obviously also many users.

the 'patch' (just 4 lines deleted ;) is awaiting review now (D640).

The problem with D640 is telling when "none are active". There is an alternate method in the code for specifying "active face", and according to it, there is an active face here. It is not clear whether or not some other function depends on that.

I'm not sure we have a clearly stated definition of what "active" is. Is it the last element explicitly selected by the user? Or does it include the implicit selections that happen when you create new geometry and the code selects the new geometry (and if not, is the correct thing to do to clear the "active" state, including the bmesh->act_face one, after constructing new geometry?).

Assuming "Active" can be set by the implicit selection of newly constructed geometry, an alternate fix to this bug is in

I think perhaps Campbell needs to decide which of these, or maybe some other solution, is best here.

Added a different fix - D758, this works a bit differently to D640 in that it remaps selection history,

This has to be implemented for each tool, which is a bit of a drawback.