Page MenuHome

Unpredicted way of loopslide, different directions in similar cases.
Closed, ArchivedPublic

Description

System Information
Operating system: Windows-8.1-6.3.9600-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 660 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 471.41

Blender Version
Broken: version: 2.93.4 Release Candidate, branch: master, commit date: 2021-08-18 12:30, hash: rB63559a779c04
Worked: (newest version of Blender that worked as expected)

Short description of error
There is no way to force to slide loops in one direction sometimes.
Please wach demo:


Event Timeline

Vyacheslav (hitrpr) updated the task description. (Show Details)
Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.Sep 1 2021, 4:07 AM

This does look incorrect, if I understand this correctly both edges should move in "same direction".

Vyacheslav (hitrpr) added a comment.EditedSep 1 2021, 7:53 AM

This does look incorrect, if I understand this correctly both edges should move in "same direction".

So «same direction» changing, depending on angles or mouse position
This is same direction, at least all three (2 edges and mouse movement) are codirected.

But slide goes mainly up-down instead right. Look: Nothing changed, Edges are codirected with mouse movement, but behavior changes.

They DO NOT move in the same direction at all.

It's hard to describe "same direction" in your example.

It is best to be described in linear and circular pattern to see how this fails. See this example:

Though this may be feature request or even conflicting with actual tool design, because I can imagine that it wouldn't be very easy to tell users intention just from topology alone.
@Germano Cavalcante (mano-wii) Do you think this is a bug? Now I am not quite sure...

The Edge Slide operator does not consider the mouse movement direction to choose a direction for loops.
So it doesn't matter if the mouse is moving right to left or bottom to top.
The direction of each loop is based on the direction of the loop closest to the cursor.
In this case, any of these 2 would be the closest:

Since the angle between these 2 is close to 90 degrees, the resulting direction is somewhat unpredictable.

We could calculate an average direction based on the closest point and the farthest point in each loop.
But that would add complexity to the code (which might even hide some bugs).
And that would be an almost imperceptible change for the user. I'm not sure it would be worth it.

So overall I don't consider this a bug, it works as designed.