projection surface snap issue
Closed, ArchivedPublic


hi devs!

The projection surface snap (old retopo), projecting on it self.

I think it is a bug because no retopo tools works in this way.

thankyou and Sorry for my english.

svn 34262 x64 win vista.


To Do

I don't see where is the problem in your .blend.

Even if It can be used as retopo tool, it is a snap tool.
It seems logical that projection on other object is ignored when there is no other object.

If you want to say that mesh should cross itself when an other surface is behind mesh one; maybe it is more respectfull of tools description.
But I don't see the benefits for user to create mesh that cross itself.

Martin, we could add an option for this, its quite easy though header is getting full.
- what do you think?

Todo item or close?

I think it's a strange option. Maybe it has cons... But I know the easiest way to snap on "itself": duplicate an object and set it to wireframe look.

It would be cool if the bug tracker have an option of "voting". So when it's confusing - what decision can be best... voting helps. It can distract somebody but also it can bump all blenderheads (I mean Devs and guys who knows well about Blender's structure and code, those who did patches for Blender) when it can be something to decide.
It's not about this bug report but I just got this idea.

since retopo is a common workflow, and this worked in 2.4x, added r35438.

This is a bad change. Too many options is an indicator of unclear workflow, we need to look into this, not tack on options after options.

ok. would be good if you could give feedback on these issues though.
reverted, r35444.

You could have kept the change. In or out, there's something bad there.

This is generic workflow and ui design, I certainly shouldn't be the only one giving feedback on this. One part of the problem is that we have one tool that does too many things, that should probably be split up in different operators instead of options for a single operator (in the same way that you can have specific operators for extrude forcing options in the generic operator).

Reopening the bug. In the long term, this is not the proper fix and I'd rather we keep this as a reminder.

Also, if you received other feedback on the issue, please indicate it here (you didn't mention anything).

Martin, i'd rather not keep reports here for a reminder. If there's actual bug here please would be nice to know what is remained to fix, if it's just thing-which-might-be-improved better to move it into wiki.

I would like to state that I am also affected by this and actually describe the bug as this:
when you retopo you shouldn't project on "self" (object) surface. it should only work on other object's surfaces only, as also the tooltip suggests...
this bug is still open in blender 2.63 bmesh

The option do what it is supposed to do.
It is not a bug. User can disable this behaviour by clicking on appropriate "Snap onto itself" icon in 3dview's header.
If it was disabled by default; people will post reports to say that snapping does not work in edit mode.

I suggest to create a clearly mentionned retopo mode with better tools for retopology or dedicated retopo tools disabling this.
Newbies don't understand that a retopo mode does not exist.

ronan you are right! but the snap onto itself should be disabled when someone uses the "retopo". meaning that even if projecting on a surface in the same object it should not snap/project onto linked vertices/faces.
The tooltip is clear, project on the surface of OTHER objects, that is what is supposed to do...

Setting as TODO/Closed,

This area could be improved, but this goes for many areas of blender and there is no specific action that needs to be taken to resolve a bug in blender,
keeping this open just clogs up the tracker,

- closing.