Page MenuHome

Pivot point broken after scaling a flat object to 0 in a dimension
Closed, ResolvedPublic

Description

Windows 10

Broken: 2.80 2c2c996a1b2
Worked: 2.79

Pivot point is broken after scaling an already flat object to 0 in its flat dimension.
After that, only 'individual origins' seems to work. All other pivot point modes seem to default to the object origin.

Steps to reproduce:

  • Open blender.
  • Add bezier (or circle, etc) (shift + a > curve > bezier).
  • In object mode, scale z to 0 (s + z + 0 + enter)
  • Enter edit mode (tab)
  • Select one point (right-click)
  • Make sure pivot point is set to Median Point (hold period > median point)
  • Optionally, switch to top-down orthographic (click ortho z / numpad-7)
  • Rotate selection (r)

Event Timeline

Philipp Oeser (lichtwerk) claimed this task.
Philipp Oeser (lichtwerk) triaged this task as Confirmed, Medium priority.

Confirmed, will have a look...

OK, had a look at this again and here are (some) findings:

first off a little detour [just as a background, nothing wrong here...]

  • since the introduction of multi-object-editing [or specifically rB844a17a3d9d2], each TransDataContainer stores matrices [4x4, 3x3, ..., inverse matrix in imat,... derrived from the objects obmat]
  • prior to above commit, those matrices were computed "on demand" all over the place
  • now for e.g editmode above local matrices are used also for converting the global transform center to the local transform center, see calculateCenterLocal()

now to where this fails:

  • a scale of zero in a matrix is not invertible
  • 2.79 suffers the same [unsolvable] problem, BUT:
  • matrix inversion was changed in rB01c75c3765eb from own code to EIGEN for performance reasons
  • if matrix inversion fails in EIGEN, it will return a zero matrix (this will result in a local transform center of 0/0/0 all the time)
  • if matrix inversion failed in previous blender code, it would do something 'smart' and return a 'partially inverted' matrix [everything inverted, failing components set to 1]

So my suggestion to workaround this situation would be to bring back the "old" invert_m4_m4() and use that as fallback if EIGEN fails.
This would make the local transform center appear correct, see D4804

other notes:

  • the helpline (see drawHelpline) is unaffected because it uses t->center_global
  • T_LOCAL_MATRIX seems unused? [was introduced in rB844a17a3d9d2], see D4805 for removal