retopoflow
retopoflow copied to clipboard
CGCookie
Respect nearest snapping when transforming
Most tools use RFOperator_Translate_ScreenSpace all of the time while tweaking, while Contours uses RFOperator_Translate_BoundaryLoop all of the time. This makes it so that moving a loop in any other tool causes the geometry to snap incorrectly.
To address this, I made a new operator, RFOperator_Translate that can do both and switch between the two. This should also help reduce duplicated code.
@vxlcoder Can you review this to see if it is acceptable? And remind me why we need a custom translate in v4? It would be nice to invoke the default translate where possible, since that comes with so many things for free like edge sliding, mirroring, constraining, etc.
For reference: https://github.com/CGCookie/retopoflow/issues/1399
I tried using Blender's native translate when tweaking in 1cc07b8e, and it seems to work great. It not only respects the Nearest Face snapping, but also works with edge and vert snapping, which are highly requested by hard surface artists. I would imagine that it's also more performant. I still need to test more to see if there are unintended consequences, but it doesn't seem like it so far.
Ah, that's right. Blender's vertex snapping can't distinguish between self and source, so with it off it will not snap to itself, but with it on it snaps to every vert in the source and jumps around annoyingly. I remember now that's one reason for the custom transform. Hmm.
correct. I started adding some ability to filter what is snappable, as the default is to snap to anything visible, but it got complicated pretty quick. that was the impetus behind the custom transform with snap.
the approach we've taken so far was to set snap settings (whether raycast or nearest or custom) based on the tool that is used. if the tool works primarily in screenspace, then the transform is in screenspace. if in world, then world. for contours, the slight difference here is that contours works with planes (plane intersecting the mesh), so there is a custom transform tool to attempt to preserve plane-related properties. it may be that the custom contours transform does not work as it should...
will take a look at your changes.
That makes sense! Maybe someday we can help improve native snapping in Blender to support this... In the meantime, the custom transform makes the most sense.
I might make native snapping a preference, so people who are working with hard surfaces can snap to edges, but would not use that as a default.
I think changing the snapping type per tool made sense in v3, but in this case we are letting folks use all of Blender's tools alongside the RF tools and it would be nice if those stayed consistent between tools. Since screen space snapping can be pretty destructive and it's easy to mess up parts of the mesh you can't see when it's enabled, my thinking was that world space makes sense to have as a default and only switch to screen space when it's clearly better (like tweaking a component that's facing the view direction) or explicitly set by the user.