[Opensg-users] Problem with matrix decomposition

Discussion:

Michael Raab

2014-08-15 12:09:41 UTC

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,</div>

<div> </div>

<div>I'm in the progress of developing some scene manipulation widgets. When implementing a scale manipulator I found out that the decomposition behaves not as I expected.</div>

<div>If I try to decompose 2 Matrices which are nearly the same I get a result scale vector that has switch axis. Here's an example:</div>

<div> </div>

<div>Matrix 1:</div>

<div>   1.040   -1.040    0.000    0.000<br/>
   0.707    0.707    0.000    0.000<br/>
   0.000    0.000    1.000    0.000<br/>
   0.000    0.000    0.000    1.000</div>

<div> </div>

<div>Result 1:</div>

<div>  Rotation 0, 0, 45</div>

<div>  Scale 1.47031, 1, 1</div>

<div>  Scale Orientation 0, 0, -0.382683, 0.92388</div>

<div> </div>

<div> </div>

<div>Matrix 2:</div>

<div>   1.046   -1.046    0.000    0.000<br/>
   0.707    0.707    0.000    0.000<br/>
   0.000    0.000    1.000    0.000<br/>
   0.000    0.000    0.000    1.000</div>

<div> </div>

<div>Result 2:</div>

<div>  Rotation: 0, 0, 45</div>

<div>  Scale: 1, 1.47986, 1</div>

<div>  Scale Orientation: 0, 0, 0.382683, 0.92388</div>

<div> </div>

<div>Has someone an explanation for this?</div>

<div> </div>

<div>Thanks,</div>

<div>Michael<br/>
 </div></div></body></html>

Carsten Neumann

2014-08-15 14:51:21 UTC

Permalink

Hello Michael,

On 2014-08-15 14:09, Michael Raab wrote:
> If I try to decompose 2 Matrices which are nearly the same I get a
> result scale vector that has switch axis. Here's an example:
> Matrix 1:
> 1.040 -1.040 0.000 0.000
> 0.707 0.707 0.000 0.000
> 0.000 0.000 1.000 0.000
> 0.000 0.000 0.000 1.000
> Result 1:
> Rotation 0, 0, 45
> Scale 1.47031, 1, 1
> Scale Orientation 0, 0, -0.382683, 0.92388
> Matrix 2:
> 1.046 -1.046 0.000 0.000
> 0.707 0.707 0.000 0.000
> 0.000 0.000 1.000 0.000
> 0.000 0.000 0.000 1.000
> Result 2:
> Rotation: 0, 0, 45
> Scale: 1, 1.47986, 1
> Scale Orientation: 0, 0, 0.382683, 0.92388
> Has someone an explanation for this?

assuming that recombining this back into matrices yields the starting
matrices (i.e. it is not a bug in the decomposition) this would be
caused by a degree of freedom in the algorithm.
I can think of the following options:
- figure out where this degree of freedom is and make choose the scale
orientation more consistently.
- can you use a ComponentTransform instead of a plain Transform and only
modify the individual components. That would make the decomposed form
the canonical representation and only build the matrix from those.
- can you make assumptions about the matrix, e.g. is it composed from
translation, rotation, and (uniform) scale only?

Cheers,
Carsten

Michael Raab

2014-08-15 17:45:08 UTC

Permalink

Hi Carsten,

Am 15.08.2014 16:51 schrieb Carsten Neumann <***@gmail.com>:
>
> Hello Michael,
>
> On 2014-08-15 14:09, Michael Raab wrote:
> > If I try to decompose 2 Matrices which are nearly the same I get a
> > result scale vector that has switch axis. Here's an example:
> > Matrix 1:
> >     1.040   -1.040    0.000    0.000
> >     0.707    0.707    0.000    0.000
> >     0.000    0.000    1.000    0.000
> >     0.000    0.000    0.000    1.000
> > Result 1:
> >    Rotation 0, 0, 45
> >    Scale 1.47031, 1, 1
> >    Scale Orientation 0, 0, -0.382683, 0.92388
> > Matrix 2:
> >     1.046   -1.046    0.000    0.000
> >     0.707    0.707    0.000    0.000
> >     0.000    0.000    1.000    0.000
> >     0.000    0.000    0.000    1.000
> > Result 2:
> >    Rotation: 0, 0, 45
> >    Scale: 1, 1.47986, 1
> >    Scale Orientation: 0, 0, 0.382683, 0.92388
> > Has someone an explanation for this?
>
> assuming that recombining this back into matrices yields the starting
> matrices (i.e. it is not a bug in the decomposition) this would be
> caused by a degree of freedom in the algorithm.

Does it really produce the initial Matrix? Haven't tested this...

> I can think of the following options:
> - figure out where this degree of freedom is and make choose the scale
> orientation more consistently.

Sorry I don't understand this..

> - can you use a ComponentTransform instead of a plain Transform and only
> modify the individual components. That would make the decomposed form
> the canonical representation and only build the matrix from those.

That is not an option as the matrix is the result of a sequence of transformations.

> - can you make assumptions about the matrix, e.g. is it composed from
> translation, rotation, and (uniform) scale only?

Unfortunately not. The only assumption I can think of is that the scale should be applied without any additional scale orientation.
Usually I think of transformation matrices as a combination of the 3 components translation, rotation and scale. Actually I do not know where the scale orientation is necessary or useful.

Michael

>
> Cheers,
> Carsten
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Opensg-users mailing list
> Opensg-***@lists.sourceforge.net
> https://list

Michael Raab

2014-08-20 08:06:20 UTC

Permalink

Carsten Neumann

2014-08-20 08:28:51 UTC

Permalink

Hello Michael,

On 08/20/2014 10:06 AM, Michael Raab wrote:
> after reading a bit more about this, I'm aware why scale orientation is
> necessary in special cases.

ok, in that case ignore my other mail, it may get some things wrong
since it's been a while since I touched the decomposition code and I
also don't have access to Graphics Gems IV at the moment :)

> Our manipulation works now, too.

Glad to hear that! :)

> Thanks for the support.
> While playing around with Matrix::getTransform() we added the missing
> snuggle support. If you think it is worth to be commited, the patch is
> attached.
> (Source may be optimized but this is more or less the original code from
> Graphics Gems IV).

Thanks for the patch! I have a very vague recollection of considering
that step of the algorithm and for some reason ended up not implementing
it - unfortunately I don't remember what the reason was.
Do you include the snuggle operation in your source tree? Have you
noticed it having an effect?

Thanks & Cheers,
Carsten

Michael Raab

2014-08-20 08:55:02 UTC

Permalink

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>> Thanks for the patch! I have a very vague recollection of considering<br/>
> that step of the algorithm and for some reason ended up not implementing<br/>
> it - unfortunately I don't remember what the reason was.<br/>
> Do you include the snuggle operation in your source tree? Have you<br/>
> noticed it having an effect?
<div>
<div> </div>

<div>Unfortunately I noticed no changes, but haven't spent much time on that.</div>

<div>Therefore I put the function in the Matrix source code but have commented its call.</div>

<div>Other projects like OpenSceneGraph and Wildfiregames use this function in their decomposition..</div>

<div> </div>

<div>Michael</div>

<div> </div>

<div> </div>

<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Mittwoch, 20. August 2014 um 10:28 Uhr<br/>
<b>Von:</b> "Carsten Neumann" <***@gmail.com><br/>
<b>An:</b> opensg-***@lists.sourceforge.net<br/>
<b>Betreff:</b> Re: [Opensg-users] Problem with matrix decomposition</div>

<div name="quoted-content">Hello Michael,<br/>
<br/>
On 08/20/2014 10:06 AM, Michael Raab wrote:<br/>
> after reading a bit more about this, I'm aware why scale orientation is<br/>
> necessary in special cases.<br/>
<br/>
ok, in that case ignore my other mail, it may get some things wrong<br/>
since it's been a while since I touched the decomposition code and I<br/>
also don't have access to Graphics Gems IV at the moment :)<br/>
<br/>
> Our manipulation works now, too.<br/>
<br/>
Glad to hear that! :)<br/>
<br/>
> Thanks for the support.<br/>
> While playing around with Matrix::getTransform() we added the missing<br/>
> snuggle support. If you think it is worth to be commited, the patch is<br/>
> attached.<br/>
> (Source may be optimized but this is more or less the original code from<br/>
> Graphics Gems IV).<br/>
<br/>
Thanks for the patch! I have a very vague recollection of considering<br/>
that step of the algorithm and for some reason ended up not implementing<br/>
it - unfortunately I don't remember what the reason was.<br/>
Do you include the snuggle operation in your source tree? Have you<br/>
noticed it having an effect?<br/>
<br/>
Thanks & Cheers,<br/>
Carsten<br/>
<br/>
------------------------------------------------------------------------------<br/>
Slashdot TV.<br/>
Video for Nerds. Stuff that matters.<br/>
<a href="http://tv.slashdot.org/" target="_blank">http://tv.slashdot.org/</a><br/>
_______________________________________________<br/>
Opensg-users mailing list<br/>
Opensg-***@lists.sourceforge.net<br/>
<a href="https://lists.sourceforge.net/lists/listinfo/opensg-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/opensg-users</a></div>
</div>
</div>
</div></div></body></html>

Carsten Neumann

2014-08-20 08:07:49 UTC

Permalink

Hello Michael,

On 08/15/2014 07:45 PM, Michael Raab wrote:
> Am 15.08.2014 16:51 schrieb Carsten Neumann <***@gmail.com>:
>> assuming that recombining this back into matrices yields the starting
>> matrices (i.e. it is not a bug in the decomposition) this would be
>> caused by a degree of freedom in the algorithm.
>
> Does it really produce the initial Matrix? Haven't tested this...
>
>> I can think of the following options:
>> - figure out where this degree of freedom is and make choose the scale
>> orientation more consistently.
>
> Sorry I don't understand this..
>
>> - can you use a ComponentTransform instead of a plain Transform and only
>> modify the individual components. That would make the decomposed form
>> the canonical representation and only build the matrix from those.
>
> That is not an option as the matrix is the result of a sequence of transformations.
>
>> - can you make assumptions about the matrix, e.g. is it composed from
>> translation, rotation, and (uniform) scale only?
>
> Unfortunately not. The only assumption I can think of is that the scale should be applied without any additional scale orientation.
> Usually I think of transformation matrices as a combination of the 3 components translation, rotation and scale. Actually I do not know where the scale orientation is necessary or useful.

the problem with that is that if your sequence of transformations
contains a scale, a rotation and another scale (i.e. M = S * R * Z) you
can not really find a rotation R' and scale S' such that M = R' * S':

(s_x ) (r_xx r_xy r_xz )
S = ( s_y ) R = (r_yx r_yy r_yz )
( s_z ) (r_zx r_zy r_zz )
( 1) ( 1)

( s_x z_x r_xx | s_x z_y r_xy | s_x z_z r_xz | )
S * R * Z = ( s_y z_x r_xx | s_x z_y r_xy | s_y z_z r_xz | )
( s_z z_x r_xx | s_z z_y r_xy | s_z z_z r_xz | )
( | | | 1)

In R' * S' the columns of the rotation are all scaled by the same
factor, while in S * R * Z every row and column has its individual scale
factor (s_* z_*). The two scaling operations S and Z happen along
different axis. It is possible to find a rotation (call it SR) and new
scaling factors S'' such that this 'complicated scaling along different
axis' can again be represented as scaling along the canonical axis' in
that rotation (!) - that is the product S * R * Z can be written:
R' * SR * S'' * SR^-1
where R' is a rotation and S'' is a scaling matrix, SR is a rotation
(into a coordinate system where we can scale along the canonical axis) -
the scale orientation.

Hope this makes some sense and that I got it right ;)

Cheers,
Carsten