Page MenuHome

Limit Scale does not Limit Scale on the Minimum Value
Open, NormalPublic


System Information
Operating system and graphics card
OS X 10.8.5
Graphics AMD Radeon HD 6490M 256 MB

Blender Version
Broken: Blender 2.69

Short description of error
The Limit Scale constraint fails with a minimum value of 0.0. The user is able to bypass the minimum and scale all the way "down" to the negative maximum value. It is easiest to bypass the minimum value at 0.0. It is also possible at values close to zero such as 0.2 or 0.4, but the user must move the mouse rather quickly to jump over the minimum value into the negative side.

Exact steps for others to reproduce the error
This is reproducible with the default blend or with the attached.


To Do

Event Timeline

Daniel Houghton (dhoughto) created this task.
Daniel Houghton (dhoughto) raised the priority of this task from to Needs Triage by Developer.

I agree.

"Limit rotation" also does not work (as expected). I post it here because it's closely related or even has the same cause:

Z is limited to the range 180..270 degrees. Press [R] [Z] to rotate the object around the Z axis. The object can not be rotated at all. I expect to be able to rotate it within the range 180..270.

This would be great to get fixed soon!

When a minimum scale is above zero and the user scales below zero, the bone stops scaling at the minimum limit, but then flips to a negative scale as soon as the user input passes zero.
When the minimum scale is set to zero or a negative number, the constraint seems to do no lower limiting at all.

This is another one of those tricky matrix decomposition problems that we also have with rotations. In this case, the problem is that we cannot tell which axis got a negative scale factor - we just know that one of them did.

I'm beginning to think that maybe we need to overhaul how transforms get passed through the transform stack - basically, making it so that raw euler and scale values get passed through the stack, get modified by any math operations which modify the matrix, and are used to temper any results (i.e. doing compatible_euler() on rotations, and checking for -ve's for scale) as they go through. Of course, it helps that such an approach would be dead easy with some of the things I'm planning with the depsgraph refactor, but would be slightly trickier to retrofit onto the current pipeline.

Moving to TODO, this isnt mistake in code, more something we could support (but as it turns out not trivial to do).

Listed here: