Page MenuHome

Armature modifier - Preserve volume + scale = incorrect result
Closed, DuplicatePublic


Win7 64, gtx 580

Blender 2.73 official

The preserve volume feature of the armature modifier gives incorrect results when scaling a bone.

See the blend file: a cylinder is rigged with 2 bones. When rotating the second bone, the deformation is not the same, depending on the scale of the first bone. I've duplicated the armature and the mesh on the right, and scaled the first bone, so that you can state it clearly.



Event Timeline

lucas veber (lucky3) set Type to Bug.
lucas veber (lucky3) created this task.
lucas veber (lucky3) raised the priority of this task from to Needs Triage by Developer.

I'm quite sure there is no bug here… Volume does not evolve the same as scaling (scaling by 2 will result in 8 times initial volume), so imho it is to be expected that 'preserve' volume also gives different results here?

Maybe others (Lukas? Aligorith?) know better.

Bastien Montagne (mont29) triaged this task as Confirmed, Low priority.Jan 9 2015, 8:02 PM

Bastien, the volume should be proportionnal to the scale, otherwise you can't achieve a complete rig with scalable bone... This is a non-sense!

As stated in T32022, I did some research on the "Quaternion Deform Interpolation" algorithm we use for the "Preserve Volume" feature, and it seems that this is a known limitation of it. It was solved in a later version of the algorithm but we still use the old one.

Just a simple question Julian. Shouldn't this (or T32022) be classified as a "To Do" up for grab instead of simply closing it, considering that you stated that a later version of the algorithm exists that solves the problem, but it has not been implemented yet? Thank you.

I possibly found the papers that refers to this problem and, despite not being a matematician, I now probably understand why an alternate solution hasn't been implemented: it is very complex and requires an high degree of knowledge in matematics, not to speak about its implementation. It seems to be more appropriate for a GSOC submission than a To Do that nobody would do. Sorry for my ignorance and for opening my mouth without knowing what I was talking about.

Nah, no need to excuse, you didn't get rude or so ;)
Of course this isn't a project for a boring evening, but I'm also afraid this is a bit too much for most GSOC students. There have been many discussions about the scope or the size of our GSOC projects lately, because in the past, most of the big projects have failed, ending up in more organization work than benefit (from our and the student's side). People tend to forget that most of the GSOC students are completely new to Blender development and aren't rocket scientists as well. It's no surprise that this approach has failed many times. Anyway, that doesn't mean we are completely rejecting this. In fact it's also on our GSOC 2015 ideas site, but still, I think it's much more likely that this will be tackled by a more experienced developer, hopefully in the near future.

That said, you see we are aware of this, we just need a dev who has the time to implement it, and maybe it's an GSOC student.
Although our Todo isn't the best maintained part of Blender's development environment, I added a note to it, but think that's a rather formal step ;)

Thank you Julian for your reply and I appreciate it very much the explanation. You're doing a very good job.

About the failing of GSOC projects, perhaps they should be included in a more defined development process where a follow-up path is coordinated and agreed upon within the development of Blender. It seems like (but this is only my feeling) that many of the GSOC projects are an end in themselves, I mean like a good "exercise" but nothing more. Anyway, I understand that the students might lack the needed experience and time to dedicate on further development of their GSOC project after they have come to the end (with success or not). Best regards.