Page MenuHome

Uncontrolled vertex movement in symmetric editing
Confirmed, NormalPublicKNOWN ISSUE

Description

System Information
Operating system: Windows 7
Graphics card: AMD Radeeon R9 200 Series

Blender Version
Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: rB77d23b0bd76f, type: Release; build date: 2020-02-13, 01:56:46
Worked: (optional)

Short description of error
When symmetrical editing about the X axis with proportional editing of an almost symmetric object, model changes are detected in places where editing was not performed.

Moreover, these changes occur asymmetrically. For example, in a key with a changed shape of the legs of a human model, a significant asymmetric change in the neck region with a shift of the line of symmetry itself was found. So it is with most other shape keys. Thus, the symmetry of the entire model is violated, which entails other undesirable consequences. These problems cannot be solved programmatically or manually, and the data on the coordinates of the vertices strangely diverge from the observed form.

Exact steps for others to reproduce the error

  1. Open file
  2. Move selected vertex
  3. vertices in unconnected mesh on mirror side will move

Model Genesis 8 exported from DAZ Studio in Base Resolution .obj file and imported to Blender.
https://youtu.be/HMiU6BYcl2E

Event Timeline

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Needs Information from User.Mar 2 2020, 10:39 AM

Could you share your .blend file with the model already imported?
Also please share the exact steps to reproduce the issue (which vertices to select, how to transform them etc,)
What might help here are screenshots also (showing "wrong" results vs. "expected" results)

If we dont have the above, I think there is no way to reproduce this issue... Thx for your help in advance...

I give a link to the video of the process and the file.

Here's what happens: a shape key is created and the first shift of the selected vertex causes an uncontrolled shift of the vertices in other areas with symmetry breaking. The next offset of the selected vertex works fine. With the new form key, the situation repeats and violations accumulate.

Richard Antalik (ISS) changed the task status from Needs Information from User to Confirmed.Mar 11 2020, 9:20 PM

I could reproduce this only with proportional editing, and behavior is definitely weird.

Since this model is asymetrical in the first place not sure if this would be considered a bug.
Perhaps you could delete half of model vertices and use mirror modifier to make it perfectly symetrical?

In order to maintain the order of the vertices, the destruction of the grid is unacceptable. To fix the defect, I tried to set all the middle vertices to the zero coordinate - this did not work. Symmetry is not restored or new vertices are added during symmetrization - this is unacceptable. But when working with symmetrical sculpting, I did not notice such a problem. It may be necessary to prepare the model in some other editor (I don’t know which one) or to make Blender somehow work ...

Jacques Lucke (JacquesLucke) changed the subtype of this task from "Report" to "Bug".Mar 18 2020, 2:45 PM

I simplified the file step by step until I got this:

Looks like a bug to me.

Germano Cavalcante (mano-wii) changed the subtype of this task from "Bug" to "Known Issue".Apr 3 2020, 9:29 PM

I don't think this is a bug.
With proportional activated, all vertices are transformed, but some of them are far away and their transformation value is multiplied by zero.
Mirror elements are not affected by proportional edit. If the element they mirror is transformed they are transformed as well.
It is good to remember that the proportional edit radius can be changed while transforming.

It would first be necessary to discuss how to resolve this. Here are some options with their disadvantage:

  • copy the porpocional distance value to the mirror elements as well. (this would increase the structure of the mirror elements which need to be small since it can work on high poly objects and could bring other unfavorable results since it would not affect all elements).
  • add an option for mirror with offset. (Currently the code is efficient because it works with the coordinate pointer directly. With this new option, the coordinate values ​​would be obtained indirectly. It would be less efficient, but it would be the only disadvantage).

I added a task to solve this in T68836: Transform Refactoring