Dual quaternion deform breaks on Tara rig #43711

New Issue

Daniel Salazar · 2015-02-17T18:58:50+01:00

Daniel Salazar commented

2015-02-17 18:58:50 +01:00

System Information

openSUSE 12.3 64bits
NVIDIA 480GTX SC
AMD FX-8350

Blender Version
Broken: 2.73a

Short description of error

https://www.youtube.com/watch?v=bd9QpdoQsBs

Exact steps for others to reproduce the error

File runs on official release but better to use master. Just move selected bone
dualquat.blend

This happens due to neck_01 being deformed by the chest bone. It can be fixed by disabling inherit scale. But still, nasty :D

**System Information** openSUSE 12.3 64bits NVIDIA 480GTX SC AMD FX-8350 **Blender Version** Broken: 2.73a **Short description of error** https://www.youtube.com/watch?v=bd9QpdoQsBs **Exact steps for others to reproduce the error** File runs on official release but better to use master. Just move selected bone [dualquat.blend](https://archive.blender.org/developer/F144316/dualquat.blend) This happens due to neck_01 being deformed by the chest bone. It can be fixed by disabling inherit scale. But still, nasty :D

Daniel Salazar commented

2015-02-17 18:58:50 +01:00

Changed status to: 'Open'

Brecht Van Lommel was assigned by Daniel Salazar

2015-02-17 18:58:50 +01:00

Daniel Salazar commented

2015-02-17 18:58:50 +01:00

Added subscriber: @zanqdo

Antonis Ryakiotakis commented

2015-02-18 12:10:32 +01:00

Added subscriber: @Psy-Fi

Antonis Ryakiotakis commented

2015-02-18 12:10:32 +01:00

There's something wrong with the file, I can't move anything and as soon I try I get not-a-number errors at the translation fields. Can you try if it works for master or if there some linking error somewhere?

Antonis Ryakiotakis commented

2015-02-18 12:16:31 +01:00

Alright, ignore please case of "reload trusted", moving on...

Daniel Salazar commented

2015-02-18 12:18:51 +01:00

@Psy-Fi Maybe the run python scripts thing is disabled? There is no external data in this file. A little more info. You move neck_01 in RIG_tara armature (Layer 11) This will move neck_01 in DEF_tara (layer 12). This is the bone that actually produces the issue since it's parented to chest.

Julian Eisel commented

2015-02-19 15:48:36 +01:00

Added subscriber: @JulianEisel

Brecht Van Lommel was unassigned by Sergey Sharybin

2015-02-20 11:03:36 +01:00

Sergey Sharybin commented

2015-02-20 11:03:36 +01:00

Added subscribers: @brecht, @Sergey

Sergey Sharybin commented

2015-02-20 11:03:36 +01:00

Placing the report for grabs. Don't think @brecht will find time soon to look into it. I'll try to look later, or maybe @Psy-Fi will nail the issue down :)

Brecht Van Lommel commented

2015-02-20 20:42:13 +01:00

I took a look at this file, there is some odd shearing on the neck_* bones in the deform rig, inherited from the chest bone. I would imagine the shearing on these neck bones is not intentional? So perhaps the real issue is in the scale inheriting code, I don't remember what the rules are here.

It seems the dual quaternion code in mat4_to_dquat() is not detecting the shearing, only scaling along the axes, and so it incorrectly assumes that there is an orthogonal matrix. The patch below can work, though I think the tolerance in is_orthonormal_m3() is way too low for any purpose, it should probably be increased to avoid too many false positives where it detects scaling when there isn't any. Maybe 1e-5f? I don't have much time now to test this on various rigs to find the right tolerance.

diff --git a/source/blender/blenlib/intern/math_rotation.c b/source/blender/blenlib/intern/math_rotation.c
index 3ac031d..0a8010b 100644
--- a/source/blender/blenlib/intern/math_rotation.c
+++ b/source/blender/blenlib/intern/math_rotation.c
@@ -1572,7 +1572,7 @@ void eulO_to_gimbal_axis(float gmat[3][3], const float eul[3], const short order
 
 void mat4_to_dquat(DualQuat *dq, float basemat[4][4], float mat[4][4])
 {
-	float *t, *q, dscale[3], scale[3], basequat[4];
+	float *t, *q, dscale[3], scale[3], basequat[4], mat3[3][3];
 	float baseRS[4][4], baseinv[4][4], baseR[4][4], baseRinv[4][4];
 	float R[4][4], S[4][4];
 
@@ -1585,7 +1585,9 @@ void mat4_to_dquat(DualQuat *dq, float basemat[4][4], float mat[4][4])
 	dscale[1] = scale[1] - 1.0f;
 	dscale[2] = scale[2] - 1.0f;
 
-	if ((determinant_m4(mat) < 0.0f) || len_v3(dscale) > 1e-4f) {
+	copy_m3_m4(mat3, mat);
+
+	if (!is_orthonormal_m3(mat3) || (determinant_m4(mat) < 0.0f) || len_v3(dscale) > 1e-4f) {
 		/* extract R and S  */
 		float tmp[4][4];

I took a look at this file, there is some odd shearing on the `neck_*` bones in the deform rig, inherited from the `chest` bone. I would imagine the shearing on these neck bones is not intentional? So perhaps the real issue is in the scale inheriting code, I don't remember what the rules are here. It seems the dual quaternion code in `mat4_to_dquat()` is not detecting the shearing, only scaling along the axes, and so it incorrectly assumes that there is an orthogonal matrix. The patch below can work, though I think the tolerance in `is_orthonormal_m3()` is way too low for any purpose, it should probably be increased to avoid too many false positives where it detects scaling when there isn't any. Maybe `1e-5f`? I don't have much time now to test this on various rigs to find the right tolerance. ``` diff --git a/source/blender/blenlib/intern/math_rotation.c b/source/blender/blenlib/intern/math_rotation.c index 3ac031d..0a8010b 100644 --- a/source/blender/blenlib/intern/math_rotation.c +++ b/source/blender/blenlib/intern/math_rotation.c @@ -1572,7 +1572,7 @@ void eulO_to_gimbal_axis(float gmat[3][3], const float eul[3], const short order void mat4_to_dquat(DualQuat *dq, float basemat[4][4], float mat[4][4]) { - float *t, *q, dscale[3], scale[3], basequat[4]; + float *t, *q, dscale[3], scale[3], basequat[4], mat3[3][3]; float baseRS[4][4], baseinv[4][4], baseR[4][4], baseRinv[4][4]; float R[4][4], S[4][4]; @@ -1585,7 +1585,9 @@ void mat4_to_dquat(DualQuat *dq, float basemat[4][4], float mat[4][4]) dscale[1] = scale[1] - 1.0f; dscale[2] = scale[2] - 1.0f; - if ((determinant_m4(mat) < 0.0f) || len_v3(dscale) > 1e-4f) { + copy_m3_m4(mat3, mat); + + if (!is_orthonormal_m3(mat3) || (determinant_m4(mat) < 0.0f) || len_v3(dscale) > 1e-4f) { /* extract R and S */ float tmp[4][4]; ```

Sergey Sharybin commented

2015-02-20 20:54:05 +01:00

@brecht, awesome to hear from you! :) Thanks for the inputs, and indeed eps seems kinda odd for me as well. We'll check on that since we've got quite a few of rigs to test on.