Edge and Vertex sliding: snapping improvements #66426

Closed
opened 2019-07-04 14:35:44 +02:00 by Germano Cavalcante · 48 comments

Currently only incremental snapping works on these operators.
Revision:
D3440: Transform: Full snapping support for Vert Slide

Currently only incremental snapping works on these operators. Revision: [D3440: Transform: Full snapping support for Vert Slide](https://archive.blender.org/developer/D3440)
Author
Member

Added subscriber: @mano-wii

Added subscriber: @mano-wii

Added subscriber: @franMarz

Added subscriber: @franMarz

Added subscriber: @item412

Added subscriber: @item412

Added subscriber: @Russ1642

Added subscriber: @Russ1642

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos

Added subscriber: @Nominous

Added subscriber: @Nominous

Added subscriber: @krooooglov

Added subscriber: @krooooglov

3Ds max's snaping is best I ever used. Blender must have snaping tool even better! )

3Ds max's snaping is best I ever used. Blender must have snaping tool even better! )

Added subscriber: @Zorgos-4

Added subscriber: @Zorgos-4

In #66426#921350, @krooooglov wrote:
3Ds max's snaping is best I ever used. Blender must have snaping tool even better! )

I agree, in 3ds Max these tools are damn convenient! But first it would be enough to add a snap feature in slide mode. I'd really like to see this feature in version 2.90.

> In #66426#921350, @krooooglov wrote: > 3Ds max's snaping is best I ever used. Blender must have snaping tool even better! ) I agree, in 3ds Max these tools are damn convenient! But first it would be enough to add a snap feature in slide mode. I'd really like to see this feature in version 2.90.

Added subscriber: @Jaydead

Added subscriber: @Jaydead

Added subscriber: @hadrien

Added subscriber: @hadrien

Vertex sliding is basically a translation with an axis constraint, so I guess it could behave exactly the same (along with planned improvements such "snap to intersecting geometry").

Vertex sliding is basically a translation with an axis constraint, so I guess it could behave exactly the same (along with planned improvements such "snap to intersecting geometry").

In #66426#950185, @hadrien wrote:
Vertex sliding is basically a translation with an axis constraint, so I guess it could behave exactly the same (along with planned improvements such "snap to intersecting geometry").

So we should expect the appearance of snapping in slide mode in version 2.90 ?

> In #66426#950185, @hadrien wrote: > Vertex sliding is basically a translation with an axis constraint, so I guess it could behave exactly the same (along with planned improvements such "snap to intersecting geometry"). So we should expect the appearance of snapping in slide mode in version 2.90 ?

I made video that shows snapping issue https://youtu.be/GTJlT9a93yY

I made video that shows snapping issue https://youtu.be/GTJlT9a93yY

Added subscriber: @mattli911

Added subscriber: @mattli911

I would love to see proper edge constraint in Blender, like Max has, where we can select and rotate an edge loop along other edges!
I have not found an easily/fast way to do this in blender yet.

You can use the Skew tool in blender, but that only works if the Cylinder/Mesh is more "flat".
If you were to rotate a cylinder and cut an edge loop in the center. Then try to rotate the edge loop and have it slide/stay constrained to the other edges, it gets crushed.

I would love to see proper edge constraint in Blender, like Max has, where we can select and rotate an edge loop along other edges! I have not found an easily/fast way to do this in blender yet. You can use the Skew tool in blender, but that only works if the Cylinder/Mesh is more "flat". If you were to rotate a cylinder and cut an edge loop in the center. Then try to rotate the edge loop and have it slide/stay constrained to the other edges, it gets crushed.

Can the developers at least comment on the chances of D3440 feature getting into version 2.90?

Can the developers at least comment on the chances of [D3440](https://archive.blender.org/developer/D3440) feature getting into version 2.90?

Added subscriber: @YuriKotlov

Added subscriber: @YuriKotlov

Added subscriber: @Sergii_Kriukovskyi

Added subscriber: @Sergii_Kriukovskyi

Added subscriber: @AlexChe-4

Added subscriber: @AlexChe-4

This issue was referenced by e2fc9a88bc

This issue was referenced by e2fc9a88bcb328284e5eab4934a9b8cc8200d55e
Author
Member

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Germano Cavalcante self-assigned this 2020-06-22 20:30:14 +02:00

This comment was removed by @krooooglov

*This comment was removed by @krooooglov*

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc

I think we need more practical examples here.

I think we need more practical examples here.

In #66426#968931, @1D_Inc wrote:
I think we need more practical examples here.

Examples how to use this feature? Arrimus3D posted a lot of videos on youtube in which he always uses it in 3ds max.

> In #66426#968931, @1D_Inc wrote: > I think we need more practical examples here. Examples how to use this feature? Arrimus3D posted a lot of videos on youtube in which he always uses it in 3ds max.

I got snap bug https://youtu.be/6s-3K6Ys_qI
https://youtu.be/_3EHed20LHc
Snap doesn't work properly

I got snap bug https://youtu.be/6s-3K6Ys_qI https://youtu.be/_3EHed20LHc Snap doesn't work properly

That is not a bug that is how it works, Blender snaps to the closest point to target in the constrained axis

That is not a bug that is how it works, Blender snaps to the closest point to target in the constrained axis

Indeed... still it would be nice to support snapping along a different axis than the transform axis. (Non-orthogonal snapping)

Indeed... still it would be nice to support snapping along a different axis than the transform axis. (Non-orthogonal snapping)

In #66426#969031, @DuarteRamos wrote:
That is not a bug that is how it works, Blender snaps to the closest point to target in the constrained axis

So it useless unfortunately. The main application of that snap is to use it with sloping surfaces.

> In #66426#969031, @DuarteRamos wrote: > That is not a bug that is how it works, Blender snaps to the closest point to target in the constrained axis So it useless unfortunately. The main application of that snap is to use it with sloping surfaces.

As it was told, more exact practical examples are needed to define "this works properly" state, unless you will force developers to iteratively guess what do you mean.

I know Arrimus, he was popular, but his methods are far from being the most effective)
Anyway, providing exact video timings to make this issue clear to developers is the best way to go.

As it was told, more exact practical examples are needed to define "this works properly" state, unless you will force developers to iteratively guess what do you mean. I know Arrimus, he was popular, but his methods are far from being the most effective) Anyway, providing exact video timings to make this issue clear to developers is the best way to go.

In #66426#969043, @1D_Inc wrote:
As it was told, more exact practical examples are needed to define "this works properly" state, unless you will force developers to iteratively guess what do you mean.

I know Arrimus, he was popular, but his methods are far from being the most effective)
Anyway, providing exact video timings to make this issue clear to developers is the best way to go.

I want active loop (edge, vert) sliding thrue inclined surface to be on one height (or in one of axis X,Y,Z) with vert to which I snapping https://www.youtube.com/watch?v=_3EHed20LHc
That's all )
Thats how it works in 3Ds max https://www.youtube.com/watch?v=GTJlT9a93yY

> In #66426#969043, @1D_Inc wrote: > As it was told, more exact practical examples are needed to define "this works properly" state, unless you will force developers to iteratively guess what do you mean. > > I know Arrimus, he was popular, but his methods are far from being the most effective) > Anyway, providing exact video timings to make this issue clear to developers is the best way to go. I want active loop (edge, vert) sliding thrue inclined surface to be on one height (or in one of axis X,Y,Z) with vert to which I snapping https://www.youtube.com/watch?v=_3EHed20LHc That's all ) Thats how it works in 3Ds max https://www.youtube.com/watch?v=GTJlT9a93yY

In #66426#969072, @krooooglov wrote:

In #66426#969043, @1D_Inc wrote:
As it was told, more exact practical examples are needed to define "this works properly" state, unless you will force developers to iteratively guess what do you mean.

I know Arrimus, he was popular, but his methods are far from being the most effective)
Anyway, providing exact video timings to make this issue clear to developers is the best way to go.

I want active loop (edge, vert) sliding thrue inclined surface to be on one height (or in one of axis X,Y,Z) with vert to which I snapping https://www.youtube.com/watch?v=_3EHed20LHc
That's all )
Thats how it works in 3Ds max https://www.youtube.com/watch?v=GTJlT9a93yY

There is no way for Blender to know along which axis you want to snap : in your last example, what you're trying to do is snap the edge along the Z (vertical) axis while moving it diagonally along a different, non-perpendicular axis. This patch only adds to edge slide the snapping functionality we already have for translation, which is orthogonal/perpendicular snapping. To support non-orthogonal snapping we'd need a way for the user to define an "intersection axis" so to say : global X, Y, Z or a custom one. But right now this isn't part of the patch. I believe there isn't even a design task for it, is there ?

> In #66426#969072, @krooooglov wrote: >> In #66426#969043, @1D_Inc wrote: >> As it was told, more exact practical examples are needed to define "this works properly" state, unless you will force developers to iteratively guess what do you mean. >> >> I know Arrimus, he was popular, but his methods are far from being the most effective) >> Anyway, providing exact video timings to make this issue clear to developers is the best way to go. > > I want active loop (edge, vert) sliding thrue inclined surface to be on one height (or in one of axis X,Y,Z) with vert to which I snapping https://www.youtube.com/watch?v=_3EHed20LHc > That's all ) > Thats how it works in 3Ds max https://www.youtube.com/watch?v=GTJlT9a93yY There is no way for Blender to know along which axis you want to snap : in your last example, what you're trying to do is snap the edge along the Z (vertical) axis while moving it diagonally along a different, non-perpendicular axis. This patch only adds to edge slide the snapping functionality we already have for translation, which is orthogonal/perpendicular snapping. To support non-orthogonal snapping we'd need a way for the user to define an "intersection axis" so to say : global X, Y, Z or a custom one. But right now this isn't part of the patch. I believe there isn't even a design task for it, is there ?

In #66426#969094, @hadrien wrote:

In #66426#969072, @krooooglov wrote:

In #66426#969043, @1D_Inc wrote:
As it was told, more exact practical examples are needed to define "this works properly" state, unless you will force developers to iteratively guess what do you mean.

I know Arrimus, he was popular, but his methods are far from being the most effective)
Anyway, providing exact video timings to make this issue clear to developers is the best way to go.

I want active loop (edge, vert) sliding thrue inclined surface to be on one height (or in one of axis X,Y,Z) with vert to which I snapping https://www.youtube.com/watch?v=_3EHed20LHc
That's all )
Thats how it works in 3Ds max https://www.youtube.com/watch?v=GTJlT9a93yY

There is no way for Blender to know along which axis you want to snap : in your last example, what you're trying to do is snap the edge along the Z (vertical) axis while moving it diagonally along a different, non-perpendicular axis. This patch only adds to edge slide the snapping functionality we already have for translation, which is orthogonal/perpendicular snapping. To support non-orthogonal snapping we'd need a way for the user to define an "intersection axis" so to say : global X, Y, Z or a custom one. But right now this isn't part of the patch. I believe there isn't even a design task for it, is there ?

Very pity. Its natural to use snap this way. Blender may know which axis I want to snap because I could select axis by pushing X,Y,Z buttons ...

> In #66426#969094, @hadrien wrote: >> In #66426#969072, @krooooglov wrote: >>> In #66426#969043, @1D_Inc wrote: >>> As it was told, more exact practical examples are needed to define "this works properly" state, unless you will force developers to iteratively guess what do you mean. >>> >>> I know Arrimus, he was popular, but his methods are far from being the most effective) >>> Anyway, providing exact video timings to make this issue clear to developers is the best way to go. >> >> I want active loop (edge, vert) sliding thrue inclined surface to be on one height (or in one of axis X,Y,Z) with vert to which I snapping https://www.youtube.com/watch?v=_3EHed20LHc >> That's all ) >> Thats how it works in 3Ds max https://www.youtube.com/watch?v=GTJlT9a93yY > > There is no way for Blender to know along which axis you want to snap : in your last example, what you're trying to do is snap the edge along the Z (vertical) axis while moving it diagonally along a different, non-perpendicular axis. This patch only adds to edge slide the snapping functionality we already have for translation, which is orthogonal/perpendicular snapping. To support non-orthogonal snapping we'd need a way for the user to define an "intersection axis" so to say : global X, Y, Z or a custom one. But right now this isn't part of the patch. I believe there isn't even a design task for it, is there ? Very pity. Its natural to use snap this way. Blender may know which axis I want to snap because I could select axis by pushing X,Y,Z buttons ...

I may have got too excited for this patch as well. But I will have to experiment with it more.

I still am hoping for a edge constraint feature where you can rotate an edge loop along other edges. Plus what people have mentioned otherwise.
Basically just stealing/replicating what 3DS Max has.

There is currently no way to use a constraint that I know of, to rotate an edge loop in blender along a cylinder type shape. You can Shear, but that doesn't work well often.

You can also do some interesting things like slide an edge loop against another one (in Max), to conform it. Although you sort of can do that in Blender maybe...

I may have got too excited for this patch as well. But I will have to experiment with it more. I still am hoping for a edge constraint feature where you can rotate an edge loop along other edges. Plus what people have mentioned otherwise. Basically just stealing/replicating what 3DS Max has. There is currently no way to use a constraint that I know of, to rotate an edge loop in blender along a cylinder type shape. You can Shear, but that doesn't work well often. You can also do some interesting things like slide an edge loop against another one (in Max), to conform it. Although you sort of can do that in Blender maybe...

Last I heard, pictures and videos of other software are prohibited here for legal reasons - I think it's safer to remove it and take it to devtalk.blender.org/ or https://rightclickselect.com/p/ where there can be a lengthy design discussion about this particular feature.

In #66426#969101, @krooooglov wrote:
Very pity. Its natural to use snap this way.

I agree it would be nice. If we can come up with a design for it to work in Blender we may just be lucky enough to have a developer work on it.

In #66426#969101, @krooooglov wrote:
Blender may know which axis I want to snap because I could select axis by pushing X,Y,Z buttons ...

Then again, not exactly : hitting X, Y or Z changes the axis of transformation, not the axis of snapping. Right now Blender only knows how to snap to elements that lie on the plane defined by the axis constraint. What you'd like it to do is define a different plane which to intersect during the transform.
The UI for this is not obvious to me, I really think it's best to mock it up on RCS before going further. Transform is undergoing quite a few changes these days so the best time to do that may be now (?).

In #66426#969110, @mattli911 wrote:
I may have got too excited for this patch as well. But I will have to experiment with it more.

I still am hoping for a edge constraint feature where you can rotate an edge loop along other edges. Plus what people have mentioned otherwise.
Basically just stealing/replicating what 3DS Max has.

There is currently no way to use a constraint that I know of, to rotate an edge loop in blender along a cylinder type shape. You can Shear, but that doesn't work well often.

You can also do some interesting things like slide an edge loop against another one (in Max), to conform it. Although you sort of can do that in Blender maybe...

Not to say that this isn't something that would be cool to simplify and streamline, but you can do it already with this patch. It requires another object (a plane) that intersects the geometry, then you can slide the vertices and snap them against the surface of the plane (with "face snapping" turned on).

Last I heard, pictures and videos of other software are prohibited here for legal reasons - I think it's safer to remove it and take it to devtalk.blender.org/ or https://rightclickselect.com/p/ where there can be a lengthy design discussion about this particular feature. > In #66426#969101, @krooooglov wrote: > Very pity. Its natural to use snap this way. I agree it would be nice. If we can come up with a design for it to work in Blender we may just be lucky enough to have a developer work on it. > In #66426#969101, @krooooglov wrote: > Blender may know which axis I want to snap because I could select axis by pushing X,Y,Z buttons ... Then again, not exactly : hitting X, Y or Z changes the axis of transformation, not the axis of snapping. Right now Blender only knows how to snap to elements that lie on the plane defined by the axis constraint. What you'd like it to do is define *a different plane* which to intersect during the transform. The UI for this is not obvious to me, I really think it's best to mock it up on RCS before going further. Transform is undergoing quite a few changes these days so the best time to do that may be now (?). > In #66426#969110, @mattli911 wrote: > I may have got too excited for this patch as well. But I will have to experiment with it more. > > I still am hoping for a edge constraint feature where you can rotate an edge loop along other edges. Plus what people have mentioned otherwise. > Basically just stealing/replicating what 3DS Max has. > > There is currently no way to use a constraint that I know of, to rotate an edge loop in blender along a cylinder type shape. You can Shear, but that doesn't work well often. > > You can also do some interesting things like slide an edge loop against another one (in Max), to conform it. Although you sort of can do that in Blender maybe... Not to say that this isn't something that would be cool to simplify and streamline, but you can do it already with this patch. It requires another object (a plane) that intersects the geometry, then you can slide the vertices and snap them against the surface of the plane (with "face snapping" turned on).

In #66426#969072, @krooooglov wrote:

I want active loop (edge, vert) sliding thrue inclined surface to be on one height (or in one of axis X,Y,Z) with vert to which I snapping https://www.youtube.com/watch?v=_3EHed20LHc
That's all )
Thats how it works in 3Ds max https://www.youtube.com/watch?v=GTJlT9a93yY

We are solving similar cases with the Polycross tool. It allow to reach pretty much flexible results, and is very useful in common.

In #66426#969110, @mattli911 wrote:

slide an edge loop against another one (in Max), to conform it.

Yes, it is interesting functionality from 3dsmax, we are solving such cases with "Project edges to faces" tool, which is a bit slower, since you have to define faces, but more precise and flexible, because supports for multiple faces as projection input.
изображение.png

> In #66426#969072, @krooooglov wrote: > I want active loop (edge, vert) sliding thrue inclined surface to be on one height (or in one of axis X,Y,Z) with vert to which I snapping https://www.youtube.com/watch?v=_3EHed20LHc > That's all ) > Thats how it works in 3Ds max https://www.youtube.com/watch?v=GTJlT9a93yY We are solving similar cases with the [Polycross ](https://youtu.be/xS7KMHCms7U) tool. It allow to reach pretty much flexible results, and is very useful in common. > In #66426#969110, @mattli911 wrote: > slide an edge loop against another one (in Max), to conform it. Yes, it is interesting functionality from 3dsmax, we are solving such cases with "Project edges to faces" tool, which is a bit slower, since you have to define faces, but more precise and flexible, because supports for multiple faces as projection input. ![изображение.png](https://archive.blender.org/developer/F8653944/изображение.png)

This comment was removed by @franMarz

*This comment was removed by @franMarz*

Please bear with me, but I'll try to be clear to avoid more noise:

Right now, the point of snap is determined by the intersection of the edge where the vertex slide is performed with the plane perpendicular to it and that contains the snap target, i.e., the shortest path. This is not so handy neither predictable in a lot of situations, especially with irregular meshes where you would prefer to snap to the intersection of the edge of slide with one of the three global planes (XY, YZ, XZ) at the target position, i.e., like moving with an axis constraint like when using G + X, Y or Z, but while sliding.

A proposal: shortcut options (X, Y, Z) for especifying during the running of the operator the direction of sliding, so the intersecting plane is the one that is perpendicular to this direction and contains the snapping target, and not the perpendicular to the edge of slide, which could remain the default.

Please bear with me, but I'll try to be clear to avoid more noise: Right now, the point of snap is determined by the intersection of the edge where the vertex slide is performed with the plane perpendicular to it and that contains the snap target, i.e., the shortest path. This is not so handy neither predictable in a lot of situations, especially with irregular meshes where you would prefer to snap to the intersection of the edge of slide with one of the three global planes (XY, YZ, XZ) at the target position, i.e., like moving with an axis constraint like when using G + X, Y or Z, but while sliding. A proposal: shortcut options (X, Y, Z) for especifying during the running of the operator the direction of sliding, so the intersecting plane is the one that is perpendicular to this direction and contains the snapping target, and not the perpendicular to the edge of slide, which could remain the default.

In #66426#970463, @franMarz wrote:
G + X, Y or Z, but while sliding.

Sounds like you mean snapping to intersecting to projections to XY planes instead of direct perpendiculars, like in Corner tool from 1D_Scripts.
Can you provide some images to make your idea clear?

> In #66426#970463, @franMarz wrote: > G + X, Y or Z, but while sliding. Sounds like you mean snapping to intersecting to projections to XY planes instead of direct perpendiculars, like in Corner tool from 1D_Scripts. Can you provide some images to make your idea clear?

In #66426#970463, @franMarz wrote:
Please bear with me, but I'll try to be clear to avoid more noise:

Right now, the point of snap is determined by the intersection of the edge where the vertex slide is performed with the plane perpendicular to it and that contains the snap target, i.e., the shortest path. This is not so handy neither predictable in a lot of situations, especially with irregular meshes where you would prefer to snap to the intersection of the edge of slide with one of the three global planes (XY, YZ, XZ) at the target position, i.e., like moving with an axis constraint like when using G + X, Y or Z, but while sliding.

A proposal: shortcut options (X, Y, Z) for especifying during the running of the operator the direction of sliding, so the intersecting plane is the one that is perpendicular to this direction and contains the snapping target, and not the perpendicular to the edge of slide, which could remain the default.

I like this idea. Thinking further, would we want to be able to specify other planes than global X, Y or Z ? or is that the main case ?

> In #66426#970463, @franMarz wrote: > Please bear with me, but I'll try to be clear to avoid more noise: > > Right now, the point of snap is determined by the intersection of the edge where the vertex slide is performed with the plane perpendicular to it and that contains the snap target, i.e., the shortest path. This is not so handy neither predictable in a lot of situations, especially with irregular meshes where you would prefer to snap to the intersection of the edge of slide with one of the three global planes (XY, YZ, XZ) at the target position, i.e., like moving with an axis constraint like when using G + X, Y or Z, but while sliding. > > A proposal: shortcut options (X, Y, Z) for especifying during the running of the operator the direction of sliding, so the intersecting plane is the one that is perpendicular to this direction and contains the snapping target, and not the perpendicular to the edge of slide, which could remain the default. I like this idea. Thinking further, would we want to be able to specify other planes than global X, Y or Z ? or is that the main case ?

Added subscriber: @DanPool

Added subscriber: @DanPool

I want to point out that the software, whose name I will not mention, that people are expecting this feature to perform similarly to also allows for snapping in a particular local or world axis. So, for instance, if I want to snap to only the z location of the target vertex, I will drag the z gizmo when sliding along an edge and the vertex will project the axis of motion along the edge to the z location of the target - the vertex slides until it reaches the xy plane that the target vertex lies on. The current state of things has the vertex snapping to the point where a ray perpendicular to the edge intersects with the vertex. So far, this has only been useful to me when the edge I'm sliding on is parallel to one of the primary world axes.

The image below depicts the current behavior of the edge slide snap which snaps perpendicular to the edge as shown in red. If I press the z key during this transform while having World Coordinates selected, I would expect the vertex to snap in a location that lies in the xy plane of the target vertex - shown in blue.
Edge Slide Snap.png

I want to point out that the software, whose name I will not mention, that people are expecting this feature to perform similarly to also allows for snapping in a particular local or world axis. So, for instance, if I want to snap to only the z location of the target vertex, I will drag the z gizmo when sliding along an edge and the vertex will project the axis of motion along the edge to the z location of the target - the vertex slides until it reaches the xy plane that the target vertex lies on. The current state of things has the vertex snapping to the point where a ray perpendicular to the edge intersects with the vertex. So far, this has only been useful to me when the edge I'm sliding on is parallel to one of the primary world axes. The image below depicts the current behavior of the edge slide snap which snaps perpendicular to the edge as shown in red. If I press the z key during this transform while having World Coordinates selected, I would expect the vertex to snap in a location that lies in the xy plane of the target vertex - shown in blue. ![Edge Slide Snap.png](https://archive.blender.org/developer/F8657781/Edge_Slide_Snap.png)

Can't say if all of this is possible, we made special subset of tools (like Polycross tool, Corner Edges tool, Project edges to faces tool) to satisfy conditions you want to put to Edge and Vertex sliding.

In #66426#970900, @DanPool wrote:
If I press the z key during this transform

This is applicable to single vertex sliding, not to loop sliding, that will eliminate the uncertainty of calculations, because loops can have much more complex shape.

Can't say if all of this is possible, we made special subset of tools (like Polycross tool, Corner Edges tool, Project edges to faces tool) to satisfy conditions you want to put to Edge and Vertex sliding. > In #66426#970900, @DanPool wrote: > If I press the z key during this transform This is applicable to single vertex sliding, not to loop sliding, that will eliminate the uncertainty of calculations, because loops can have much more complex shape.

In #66426#970900, @DanPool wrote:
I want to point out that the software, whose name I will not mention, that people are expecting this feature to perform similarly to also allows for snapping in a particular local or world axis. So, for instance, if I want to snap to only the z location of the target vertex, I will drag the z gizmo when sliding along an edge and the vertex will project the axis of motion along the edge to the z location of the target - the vertex slides until it reaches the xy plane that the target vertex lies on. The current state of things has the vertex snapping to the point where a ray perpendicular to the edge intersects with the vertex. So far, this has only been useful to me when the edge I'm sliding on is parallel to one of the primary world axes.

The image below depicts the current behavior of the edge slide snap which snaps perpendicular to the edge as shown in red. If I press the z key during this transform while having World Coordinates selected, I would expect the vertex to snap in a location that lies in the xy plane of the target vertex - shown in blue.
Edge Slide Snap.png

I think the snapping plane should be determined by an additional property rather than by the current transform orientation (global, local...). If not, then vertex sliding and regular transform would be handled in an inconsistent way : one (vertex slide) would use the current transform orientation to determine the snap plane whereas the other (regular transform) would inevitably have to use a different property, because it ultimately needs two different orientations 1. to pick a direction in which to move and 2. to pick a plane to snap to.
I believe we could introduce a new property to control the orientation of the snapping plane, which would default to "orthogonal" and behave like it does currently. Other options could be "global X", "local Z", and so on.

@1D_Inc I'm going to study what your addon allows in terms of intersections, it seems to be rather complete

> In #66426#970900, @DanPool wrote: > I want to point out that the software, whose name I will not mention, that people are expecting this feature to perform similarly to also allows for snapping in a particular local or world axis. So, for instance, if I want to snap to only the z location of the target vertex, I will drag the z gizmo when sliding along an edge and the vertex will project the axis of motion along the edge to the z location of the target - the vertex slides until it reaches the xy plane that the target vertex lies on. The current state of things has the vertex snapping to the point where a ray perpendicular to the edge intersects with the vertex. So far, this has only been useful to me when the edge I'm sliding on is parallel to one of the primary world axes. > > The image below depicts the current behavior of the edge slide snap which snaps perpendicular to the edge as shown in red. If I press the z key during this transform while having World Coordinates selected, I would expect the vertex to snap in a location that lies in the xy plane of the target vertex - shown in blue. > ![Edge Slide Snap.png](https://archive.blender.org/developer/F8657781/Edge_Slide_Snap.png) I think the snapping plane should be determined by an additional property rather than by the current transform orientation (global, local...). If not, then vertex sliding and regular transform would be handled in an inconsistent way : one (vertex slide) would use the current transform orientation to determine the snap plane whereas the other (regular transform) would inevitably have to use a different property, because it ultimately needs two different orientations 1. to pick a direction in which to move and 2. to pick a plane to snap to. I believe we could introduce a new property to control the orientation of the snapping plane, which would default to "orthogonal" and behave like it does currently. Other options could be "global X", "local Z", and so on. @1D_Inc I'm going to study what your addon allows in terms of intersections, it seems to be rather complete

In #66426#971329, @hadrien wrote:

...it ultimately needs two different orientations 1. to pick a direction in which to move and 2. to pick a plane to snap to.

You're overthinking it. If you pick z direction with the world coordinates selected, the plane will be parallel to the world xy plane. That is enough to define a plane: a point in 3d space and an existing plane to reference for parallelism. The axis of motion is still along the edge that you're sliding. Your edge or vertex slides until it meets this plane.

In #66426#971309, @1D_Inc wrote:
This is applicable to single vertex sliding, not to loop sliding, that will eliminate the uncertainty of calculations, because loops can have much more complex shape.

This is already addressed in the "Snap with" settings, the pertinent options being Closest, Median, and Active. This will also be further addressed with the basepoint transforms.
https://developer.blender.org/T66424

It works in other software, so I know it's possible. I also know it is a huge timesaver and the exact reason people requested this feature in the first place.

Further discussion should probably be moved here:
https://devtalk.blender.org/t/discussions-for-better-snapping-and-precision-modeling/5351/267

> In #66426#971329, @hadrien wrote: > > ...it ultimately needs two different orientations 1. to pick a direction in which to move and 2. to pick a plane to snap to. You're overthinking it. If you pick z direction with the world coordinates selected, the plane will be parallel to the world xy plane. That is enough to define a plane: a point in 3d space and an existing plane to reference for parallelism. The axis of motion is still along the edge that you're sliding. Your edge or vertex slides until it meets this plane. > In #66426#971309, @1D_Inc wrote: > This is applicable to single vertex sliding, not to loop sliding, that will eliminate the uncertainty of calculations, because loops can have much more complex shape. This is already addressed in the "Snap with" settings, the pertinent options being Closest, Median, and Active. This will also be further addressed with the basepoint transforms. https://developer.blender.org/T66424 It works in other software, so I know it's possible. I also know it is a huge timesaver and the exact reason people requested this feature in the first place. Further discussion should probably be moved here: https://devtalk.blender.org/t/discussions-for-better-snapping-and-precision-modeling/5351/267
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
17 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#66426
No description provided.