Armature modifier - Preserve volume + scale = incorrect result #43188

New Issue

lucas veber · 2015-01-09T19:42:23+01:00

lucas veber commented

2015-01-09 19:42:23 +01:00

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.preserve_volume_scale.blend

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.[preserve_volume_scale.blend](https://archive.blender.org/developer/F136478/preserve_volume_scale.blend)

lucas veber commented

2015-01-09 19:42:23 +01:00

Changed status to: 'Open'

lucas veber commented

2015-01-09 19:42:23 +01:00

Added subscriber: @LucasVeber

blender-admin commented

2015-01-09 19:42:23 +01:00

#100373 was marked as duplicate of this issue

Bastien Montagne commented

2015-01-09 20:02:19 +01:00

Added subscribers: @JoshuaLeung, @LukasTonne, @mont29

Bastien Montagne commented

2015-01-09 20:02:19 +01:00

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.

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.

lucas veber commented

2015-01-09 20:17:19 +01:00

This comment was removed by @LucasVeber

*This comment was removed by @LucasVeber*

Julian Eisel commented

2015-02-23 23:39:46 +01:00

Closed as duplicate of #32022

Julian Eisel closed this issue

2015-02-23 23:39:46 +01:00

Julian Eisel commented

2015-02-23 23:43:23 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2015-02-23 23:43:23 +01:00

As stated in #32022, 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.

Riccardo Giovanetti commented

2015-02-24 01:58:50 +01:00

Added subscriber: @Harvester

Riccardo Giovanetti commented

2015-02-24 01:58:50 +01:00

Just a simple question Julian. Shouldn't this (or #32022) 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.

Riccardo Giovanetti commented

2015-02-24 02:33:04 +01:00

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.

Julian Eisel commented

2015-02-24 03:30:18 +01:00

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 ;)

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 ](http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2015/Ideas#Modifiers), 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 ](http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Animation#Armature), but think that's a rather formal step ;)

Riccardo Giovanetti commented

2015-02-24 12:04:18 +01:00

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.

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.

Omar Emara commented

2022-08-15 14:21:30 +02:00

Added subscribers: @Munkle_Mark, @OmarEmaraDev

himisa referenced this issue

2023-05-22 08:42:58 +02:00

Fix #32022, #43188, #100373, Armature modifier - Preserve volume + Scale #108134

Nathan Vegdahl referenced this issue from a commit

2023-06-06 12:32:01 +02:00

Fix #32022, #43188, #100373, Armature modifier - Preserve volume + Scale

Sign in to join this conversation.