Page MenuHome

Mesh explode when bone is in 180º (maybe Maintain Volume modifier)
Closed, ArchivedPublic


Open "mesh explode.blend", 4 bones and simple mesh with armature

-In frame 0 the mesh appear "explode", the "spine_root__CA.M" is rotated 180º in Y axis
-in Frame 1 the mesh appear correct, is rotated 179.841º in Y axis

the bone "eye_squas_low__BKH.L" have a Maintain Volume modifier if, you turn off it, seems everything is ok




To Do

Event Timeline

I don't have this issue with r48394 on Ubuntu 10.10 32 bit. It's fine for all frames. Could we have some information about the version you use?

I am not familiar with the feature, but the issue is clearly related to some math getting wrong values. Its related to the rotation of the bones.

- if you set both bones to use quaternions, things work fine
- or if you set "Maintain Volume" constraint influence to slightly less than 100% it goes fine.

At least you can work around it now ;) but now... let's check if the coder of this option is around.

Any updates here?

I can confirm that it looks odd on frame 0, but why use frame 0 anyway here? Frame 1 and above is fine.

no, i did not touch any piece of the code ( and i don't want to )
since the patch early in 2012 .. was about nmesh stuff as far as i remember

well..assigning a bug is one thing .. finding the one coding it, the other
well blaming coders to write code that does not fit future rules is a bit odd at least

Marked this on our Animation/rigging list as known issue, for future reference.

Jens Ole: no blame game here, just tried to check if you had suggestions.

Ton Roosendaal (ton) closed this task as Archived.Feb 16 2013, 5:28 PM

That sounds much more like .. 'we need help can you look at it?'
Well .. i will have a look at it ASAP

Did try on recent build (2013/02/25) on win XP (32 bit OS) 2.66 (still no revision on scons build :( )
As well as on 2.65.0 r 53189 windows (32 bit bit Os)
What i did:
Open file
Select object
/* some coders thoughts ******
.. hum .. which object to select .. there is a copy constraint .. may be a delayed copy?
After all a crude set up. Hard to find out what is intended an how the get the bug reproduced.
Select spine_root__CA.M
set Y angle in Euler to 180
press alt A
everything is working fine.
So for me it is a unknown issue :)
Can you give a step by step crash/fail instruction?
Sure the user did see what he complains about.
first wild guesses
'but the issue is clearly related to some math getting wrong values'
Math is OK
'some math getting wrong values' says
but some variable is not set properly on frame 0 ( as windows has a different memory allocation thing .. thus pointing things to locations that resemble the desired layout )
may be a 64 bit pointer issue ( if it was a 64 bit system at all )