[Breaking Change] DO3D has new props localRotationX / Y /Z , pitch, yaw, roll are methods again

[Tim Knip-2]

Hi List,

Sorry for this confusion, but we decided to revert back to pitch(
angle ), yaw( angle ) and roll( angle ) methods.

There are three new getter / setters now though:

do3d.localRotationX
do3d.localRotationY
do3d.localRotationZ

So:

pitch( 30 ) would be the same as doing localRotationX = 30;

Note that  localRotationX / Y /Z are rotations relative to the
rotation as set by rotationX / Y / Z.
Also note that after do3d.lookAt() localRotationX/Y/Z will be resetted to 0

Tim

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[speedok1]

Hi Tim,

Thanks for the update.

Are there still issues with near and lookAt  ?

Tim Knip-2 wrote:

Hi List,

Sorry for this confusion, but we decided to revert back to pitch(
angle ), yaw( angle ) and roll( angle ) methods.

There are three new getter / setters now though:

do3d.localRotationX
do3d.localRotationY
do3d.localRotationZ

So:

pitch( 30 ) would be the same as doing localRotationX = 30;

Note that  localRotationX / Y /Z are rotations relative to the
rotation as set by rotationX / Y / Z.
Also note that after do3d.lookAt() localRotationX/Y/Z will be resetted to 0

Tim

_______________________________________________
Papervision3D mailing list
[e-mail]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Paul Tondeur-2]

Hi Tim,

I'm experiencing some problems after this update which you might not be
aware of.

When I execute onenterframe for example the following code:

object.yaw(1)
trace(object.rotationY);

When I expect to receive a value of +/- 90, it will return NaN. I've
located this problem to changes in the Matrix3D class.
The following code execution is happening and will trace NaN as well:

var number:Number = -1.0000000000000029;
trace(Math.asin(-number/1)); //Traces NaN

Unfurtuantly I'm not that skilled right now to solve this problem. Maybe
you have an idea?

When I do for example a object.pitch(1) and trace(object.rotationX), it
will return the right values.

Beside it seems that rotationY is always between -90 and +90, instead of
between -180 and +180. Is this a bug, or is it a feature, which use I'm
not aware of?  :-)

Paul

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Tim Knip
Sent: zondag 20 juli 2008 18:32
To: [hidden email]
Subject: [Papervision3D] [Breaking Change] DO3D has new props
localRotationX/ Y /Z , pitch, yaw, roll are methods again

Hi List,

Sorry for this confusion, but we decided to revert back to pitch(
angle ), yaw( angle ) and roll( angle ) methods.

There are three new getter / setters now though:

do3d.localRotationX
do3d.localRotationY
do3d.localRotationZ

So:

pitch( 30 ) would be the same as doing localRotationX = 30;

Note that  localRotationX / Y /Z are rotations relative to the
rotation as set by rotationX / Y / Z.
Also note that after do3d.lookAt() localRotationX/Y/Z will be resetted
to 0

Tim

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Jon Bradley-2]

Some javascript/style in this post has been disabled (why?)

On Jul 23, 2008, at 12:12 PM, Paul Tondeur wrote:

When I expect to receive a value of +/- 90, it will return NaN. I've

located this problem to changes in the Matrix3D class.

The following code execution is happening and will trace NaN as well:

var number:Number = -1.0000000000000029;

trace(Math.asin(-number/1)); //Traces NaN

Might be a bug in the Flash Player.

var number:Number = -1.0000000000000029;

var n:Number = -number/1;

trace( Math.asin(n) ); // 57.295779513082486

cheers,

jon

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Jon Bradley-2]

Some javascript/style in this post has been disabled (why?)

On Jul 23, 2008, at 12:12 PM, Paul Tondeur wrote:

When I expect to receive a value of +/- 90, it will return NaN. I've

located this problem to changes in the Matrix3D class.

The following code execution is happening and will trace NaN as well:

If the issue is with matrix2euler, change this

euler.y = Math.asin(-m.n31/sz);

to this

var n:Number = -m.n31/sz;

euler.y = Math.asin(n);

Hope that fixes it.

best,

jon

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Jon Bradley-2]

On Jul 23, 2008, at 12:36 PM, Jon Bradley wrote:

> If the issue is with matrix2euler

If you're really bold, you can try this method instead:

        public static function matrix2euler( m :Matrix3D,  
euler:Number3D=null, scale:Number3D=null ) : Number3D
        {
                euler = euler || new Number3D();

         var x:Number = 0;
         var y:Number = 0;
         var c:Number = 0;

         euler.y = -Math.asin( m.13);
         c = Math.cos(ay);

         if ( Math.abs(c) > 0.005 )
         {
             x =  m.33/c;
             y = -m.23/c;

             euler.x = Math.atan2(y,x);

             x = m.11/c;
             y = m.12/c;

             euler.z = atan2(y,x);
         }
         else
         {
             euler.x = 0;
             x = m.22;
             y = m.21;
             euler.z = atan2(y,x);
         }

         //  Clamp values
         euler.x = (euler.x > 360) ? 360:((euler.x < 0) ? 0:euler.x);
         euler.y = (euler.y > 360) ? 360:((euler.y < 0) ? 0:euler.y);
         euler.z = (euler.z > 360) ? 360:((euler.z < 0) ? 0:euler.z);

                if(Papervision3D.useDEGREES)
                {
                        euler.x *= toDEGREES;
                        euler.y *= toDEGREES;
                        euler.z *= toDEGREES;
                }
               
                return euler;
     }



_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Jon Bradley-2]

Ah, I'm a doofus. Didn't put in the matrix props correctly. This  
method is completely untested.

        public static function matrix2euler( m :Matrix3D,  
euler:Number3D=null, scale:Number3D=null ) : Number3D
        {
                euler = euler || new Number3D();

         var x:Number = 0;
         var y:Number = 0;
         var c:Number = 0;

         euler.y = -Math.asin( m.n13);
         c = Math.cos(ay);

         if ( Math.abs(c) > 0.005 )
         {
             x =  m.n33/c;
             y = -m.n23/c;

             euler.x = Math.atan2(y,x);

             x = m.n11/c;
             y = m.n12/c;

             euler.z = atan2(y,x);
         }
         else
         {
             euler.x = 0;
             x = m.n22;
             y = m.n21;
             euler.z = atan2(y,x);
         }

         //  Clamp values
         euler.x = (euler.x > 360) ? 360:((euler.x < 0) ? 0:euler.x);
         euler.y = (euler.y > 360) ? 360:((euler.y < 0) ? 0:euler.y);
         euler.z = (euler.z > 360) ? 360:((euler.z < 0) ? 0:euler.z);

                if(Papervision3D.useDEGREES)
                {
                        euler.x *= toDEGREES;
                        euler.y *= toDEGREES;
                        euler.z *= toDEGREES;
                }
               
                return euler;
     }




_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Paul Tondeur-2]

Hi Jon,

Thanks for the suggestions to solve this problem! Unfortunately, none of
these seems to work out correctly.
I tried using the code for this method from revision 647. This seems to
work without any problems right now. However I expect that this might
introduce some new problems as well.

It might be an idea that someone from the pv3d team looks into this and
put this in the next update?
As soon as I've found a way to update the current implemented code I'll
post a new message.

Paul


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jon Bradley
Sent: woensdag 23 juli 2008 19:04
To: [hidden email]
Subject: Re: [Papervision3D] [Breaking Change] DO3D has new
propslocalRotationX/ Y /Z , pitch, yaw, roll are methods again

Ah, I'm a doofus. Didn't put in the matrix props correctly. This  
method is completely untested.

        public static function matrix2euler( m :Matrix3D,  
euler:Number3D=null, scale:Number3D=null ) : Number3D
        {
                euler = euler || new Number3D();

         var x:Number = 0;
         var y:Number = 0;
         var c:Number = 0;

         euler.y = -Math.asin( m.n13);
         c = Math.cos(ay);

         if ( Math.abs(c) > 0.005 )
         {
             x =  m.n33/c;
             y = -m.n23/c;

             euler.x = Math.atan2(y,x);

             x = m.n11/c;
             y = m.n12/c;

             euler.z = atan2(y,x);
         }
         else
         {
             euler.x = 0;
             x = m.n22;
             y = m.n21;
             euler.z = atan2(y,x);
         }

         //  Clamp values
         euler.x = (euler.x > 360) ? 360:((euler.x < 0) ? 0:euler.x);
         euler.y = (euler.y > 360) ? 360:((euler.y < 0) ? 0:euler.y);
         euler.z = (euler.z > 360) ? 360:((euler.z < 0) ? 0:euler.z);

                if(Papervision3D.useDEGREES)
                {
                        euler.x *= toDEGREES;
                        euler.y *= toDEGREES;
                        euler.z *= toDEGREES;
                }
               
                return euler;
     }




_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[John Grden]

yeah I'm sure tim will likely get back to you - he's been working on this pretty vigorously as of late

Thanks for the posts guys, this does help!

On Wed, Jul 23, 2008 at 3:21 PM, Paul Tondeur <[hidden email]> wrote:

Hi Jon,

Thanks for the suggestions to solve this problem! Unfortunately, none of
these seems to work out correctly.
I tried using the code for this method from revision 647. This seems to
work without any problems right now. However I expect that this might
introduce some new problems as well.

It might be an idea that someone from the pv3d team looks into this and
put this in the next update?
As soon as I've found a way to update the current implemented code I'll
post a new message.

Paul


-----Original Message-----
From: [hidden email]

[mailto:[hidden email]] On Behalf Of Jon Bradley
Sent: woensdag 23 juli 2008 19:04
To: [hidden email]

Subject: Re: [Papervision3D] [Breaking Change] DO3D has new
propslocalRotationX/ Y /Z , pitch, yaw, roll are methods again

Ah, I'm a doofus. Didn't put in the matrix props correctly. This
method is completely untested.

       public static function matrix2euler( m :Matrix3D,
euler:Number3D=null, scale:Number3D=null ) : Number3D
       {
               euler = euler || new Number3D();

        var x:Number = 0;
        var y:Number = 0;
        var c:Number = 0;

        euler.y = -Math.asin( m.n13);
        c = Math.cos(ay);

        if ( Math.abs(c) > 0.005 )
        {
            x =  m.n33/c;
            y = -m.n23/c;

            euler.x = Math.atan2(y,x);

            x = m.n11/c;
            y = m.n12/c;

            euler.z = atan2(y,x);
        }
        else
        {
            euler.x = 0;
            x = m.n22;
            y = m.n21;
            euler.z = atan2(y,x);
        }

        //  Clamp values
        euler.x = (euler.x > 360) ? 360:((euler.x < 0) ? 0:euler.x);
        euler.y = (euler.y > 360) ? 360:((euler.y < 0) ? 0:euler.y);
        euler.z = (euler.z > 360) ? 360:((euler.z < 0) ? 0:euler.z);

               if(Papervision3D.useDEGREES)
               {
                       euler.x *= toDEGREES;
                       euler.y *= toDEGREES;
                       euler.z *= toDEGREES;
               }

               return euler;
    }




_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

--
[ JPG ]

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Tim Knip-2]

Hi all,

The NaN issue is fixed I beleive, update is in repo.

Now... the issue of #rotationY only going from -90 / +90...

This has to do with the fact that #rotationX / Y / Z are Euler-angles.
A problem is that when one does pitch(), yaw() or roll() the above
props are getting updated thru Matrix3D#matrix2euler.

Now: the process to convert a matrix into Euler-angles is called
'factoring'. This process has one BIG disadvantage: the
'factorization' can yield TWO possible solutions (Different sets of
eulers can descibe the same rotation).

Bottomline is that yaw()-ing past rotationY = +/- 90 will make
#rotationX / Z 180...
Note that this behaviour only occurs with yaw(), pitch() and roll() =>
only these will trigger matrix2euler()

Don't see a solution for this (think its just the nature of
euler-angles)... anyone?

Tim

2008/7/23 John Grden <[hidden email]>:

> yeah I'm sure tim will likely get back to you - he's been working on this
> pretty vigorously as of late
>
> Thanks for the posts guys, this does help!
>
> On Wed, Jul 23, 2008 at 3:21 PM, Paul Tondeur <[hidden email]> wrote:
>>
>> Hi Jon,
>>
>> Thanks for the suggestions to solve this problem! Unfortunately, none of
>> these seems to work out correctly.
>> I tried using the code for this method from revision 647. This seems to
>> work without any problems right now. However I expect that this might
>> introduce some new problems as well.
>>
>> It might be an idea that someone from the pv3d team looks into this and
>> put this in the next update?
>> As soon as I've found a way to update the current implemented code I'll
>> post a new message.
>>
>> Paul
>>
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Jon Bradley
>> Sent: woensdag 23 juli 2008 19:04
>> To: [hidden email]
>> Subject: Re: [Papervision3D] [Breaking Change] DO3D has new
>> propslocalRotationX/ Y /Z , pitch, yaw, roll are methods again
>>
>> Ah, I'm a doofus. Didn't put in the matrix props correctly. This
>> method is completely untested.
>>
>>        public static function matrix2euler( m :Matrix3D,
>> euler:Number3D=null, scale:Number3D=null ) : Number3D
>>        {
>>                euler = euler || new Number3D();
>>
>>         var x:Number = 0;
>>         var y:Number = 0;
>>         var c:Number = 0;
>>
>>         euler.y = -Math.asin( m.n13);
>>         c = Math.cos(ay);
>>
>>         if ( Math.abs(c) > 0.005 )
>>         {
>>             x =  m.n33/c;
>>             y = -m.n23/c;
>>
>>             euler.x = Math.atan2(y,x);
>>
>>             x = m.n11/c;
>>             y = m.n12/c;
>>
>>             euler.z = atan2(y,x);
>>         }
>>         else
>>         {
>>             euler.x = 0;
>>             x = m.n22;
>>             y = m.n21;
>>             euler.z = atan2(y,x);
>>         }
>>
>>         //  Clamp values
>>         euler.x = (euler.x > 360) ? 360:((euler.x < 0) ? 0:euler.x);
>>         euler.y = (euler.y > 360) ? 360:((euler.y < 0) ? 0:euler.y);
>>         euler.z = (euler.z > 360) ? 360:((euler.z < 0) ? 0:euler.z);
>>
>>                if(Papervision3D.useDEGREES)
>>                {
>>                        euler.x *= toDEGREES;
>>                        euler.y *= toDEGREES;
>>                        euler.z *= toDEGREES;
>>                }
>>
>>                return euler;
>>     }
>>
>>
>>
>>
>> _______________________________________________
>> Papervision3D mailing list
>> [hidden email]
>> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>>
>> _______________________________________________
>> Papervision3D mailing list
>> [hidden email]
>> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>
>
>
> --
> [ JPG ]
> _______________________________________________
> Papervision3D mailing list
> [hidden email]
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>
>

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Jon Bradley-2]

Some javascript/style in this post has been disabled (why?)

On Jul 23, 2008, at 5:13 PM, Tim Knip wrote:

Don't see a solution for this (think its just the nature of

euler-angles)... anyone?

Tricky, definitely.

The only way to really do it is to record the previous euler result and using it to choose the proper solution. 

It's pretty easy to do for a situation where you have that previous result, but when that result does not exist you're always going to get 2 valid solutions (at a minimum) and infinite solutions (cosine 0) at a maximum.

BTW, I think the code I posted is a more generic solution than what is there right now. I'd just have to go through it and test it out. It doesn't handle scale though.

cheers,

jon

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Jon Bradley-2]

Some javascript/style in this post has been disabled (why?)

And in response to my previous post about using the previous result from a matrix to euler conversion, the following code dump might be of assistance.

http://www.kuroyumes-developmentzone.com/_private_/WellbehavedEulers.txt

- jon

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Tim Knip-2]

Here's a good reference: www.geometrictools.com/Documentation/EulerAngles.pdf

Apparenlty PV3D need 'ZYX' factoring.

Tim

2008/7/23 Jon Bradley <[hidden email]>:

>
> On Jul 23, 2008, at 5:13 PM, Tim Knip wrote:
>
> Don't see a solution for this (think its just the nature of
>
> euler-angles)... anyone?
>
> Tricky, definitely.
> The only way to really do it is to record the previous euler result and
> using it to choose the proper solution.
> It's pretty easy to do for a situation where you have that previous result,
> but when that result does not exist you're always going to get 2 valid
> solutions (at a minimum) and infinite solutions (cosine 0) at a maximum.
> BTW, I think the code I posted is a more generic solution than what is there
> right now. I'd just have to go through it and test it out. It doesn't handle
> scale though.
> cheers,
> jon
> _______________________________________________
> Papervision3D mailing list
> [hidden email]
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>
>

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Jon Bradley-2]

On Jul 23, 2008, at 5:42 PM, Tim Knip wrote:

> Here's a good reference: www.geometrictools.com/Documentation/EulerAngles.pdf
>
> Apparenlty PV3D need 'ZYX' factoring.

FYI, I love that resource. I've been using that for all sorts of good  
stuff.

cheers,

jon

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Tim Knip-2]

Still...

Lets view this conceptually:

We can conclude that factoring eulers from a matrix is tricky to say the least.

Confusion arises because pitch(), yaw() and roll() update the
rotationX / Y / Z (eulers!) values to reflect the current
rotation-matrix. Now: p/y/r work on the 'existing' rotation-matrix
(ie: what we've set before thru rotationX/Y/Z).

Now: is this conceptually sound?
I'm not sure. Mixing eulers and p/y/r seems somewhat weird.

Wouldn't it be better to simply choose a single system? As p/y/r work
in the objects 'local' frame of reference, whilst rotationX / Y / Z
work in the 'global' frame of reference.

I'm sure this is something basic in 3D, but I'm lost at the moment.

If anyone can shed any light on how other 3D-apps handle the diverse
'rotation types' (local, global, parent, etc)  i'll be *very* happy.

Tim

2008/7/24 Jon Bradley <[hidden email]>:

>
> On Jul 23, 2008, at 5:42 PM, Tim Knip wrote:
>
>> Here's a good reference: www.geometrictools.com/Documentation/EulerAngles.pdf
>>
>> Apparenlty PV3D need 'ZYX' factoring.
>
> FYI, I love that resource. I've been using that for all sorts of good
> stuff.
>
> cheers,
>
> jon
>
> _______________________________________________
> Papervision3D mailing list
> [hidden email]
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[barbara]

Hi guys,

I usually get help on this web site when at a loss between quaternions, matrices, euler angles, axis angles...
http://www.euclideanspace.com/maths/geometry/rotations/conversions/matrixToEuler/index.htm

Indeed, translating a matrix into euler angles should be avoided if possible.
Personally, in the openGL world where I come from we use only quaternions and matrices to directly achieve the rotations we wish. My advice would be to let go the rotationX,Y,Z variables, because they are not completely reliable, and work with the rotation matrix.

Tim Knip-2 wrote:

Still...

Lets view this conceptually:

We can conclude that factoring eulers from a matrix is tricky to say the least.

Confusion arises because pitch(), yaw() and roll() update the
rotationX / Y / Z (eulers!) values to reflect the current
rotation-matrix. Now: p/y/r work on the 'existing' rotation-matrix
(ie: what we've set before thru rotationX/Y/Z).

Now: is this conceptually sound?
I'm not sure. Mixing eulers and p/y/r seems somewhat weird.

Wouldn't it be better to simply choose a single system? As p/y/r work
in the objects 'local' frame of reference, whilst rotationX / Y / Z
work in the 'global' frame of reference.

I'm sure this is something basic in 3D, but I'm lost at the moment.

If anyone can shed any light on how other 3D-apps handle the diverse
'rotation types' (local, global, parent, etc)  i'll be *very* happy.

Tim

2008/7/24 Jon Bradley <[e-mail]>:
>
> On Jul 23, 2008, at 5:42 PM, Tim Knip wrote:
>
>> Here's a good reference: www.geometrictools.com/Documentation/EulerAngles.pdf
>>
>> Apparenlty PV3D need 'ZYX' factoring.
>
> FYI, I love that resource. I've been using that for all sorts of good
> stuff.
>
> cheers,
>
> jon
>
> _______________________________________________
> Papervision3D mailing list
> [e-mail]
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>

_______________________________________________
Papervision3D mailing list
[e-mail]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Paul Tondeur-2]

Hi Tim,

Great work! Thumbs up for the fast response, the problem is solved here!

Euler rotation values were introduced in one of the latest revisions
isn't it? I think it would be usefull when a yaw/pitch/roll would update
rotation values the same as setting an object.rotation* value.
I agree with you, it would be usefull to use the same system for both.
However, I'm not familar with the euler system. Where would euler angles
be usefull for?

Paul

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Tim Knip
Sent: donderdag 24 juli 2008 03:16
To: [hidden email]
Subject: Re: [Papervision3D] [Breaking Change] DO3D has
newpropslocalRotationX/ Y /Z , pitch, yaw, roll are methods again

Still...

Lets view this conceptually:

We can conclude that factoring eulers from a matrix is tricky to say the
least.

Confusion arises because pitch(), yaw() and roll() update the
rotationX / Y / Z (eulers!) values to reflect the current
rotation-matrix. Now: p/y/r work on the 'existing' rotation-matrix
(ie: what we've set before thru rotationX/Y/Z).

Now: is this conceptually sound?
I'm not sure. Mixing eulers and p/y/r seems somewhat weird.

Wouldn't it be better to simply choose a single system? As p/y/r work
in the objects 'local' frame of reference, whilst rotationX / Y / Z
work in the 'global' frame of reference.

I'm sure this is something basic in 3D, but I'm lost at the moment.

If anyone can shed any light on how other 3D-apps handle the diverse
'rotation types' (local, global, parent, etc)  i'll be *very* happy.

Tim

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Jon Bradley-2]

Some javascript/style in this post has been disabled (why?)

On Jul 23, 2008, at 9:16 PM, Tim Knip wrote:

Wouldn't it be better to simply choose a single system? As p/y/r work

in the objects 'local' frame of reference, whilst rotationX / Y / Z

work in the 'global' frame of reference.

I agree a single system is better than two. The problem then becomes that of user knowledge. Matrices are far better to work with, but they are absolutely not intuitive unless the person has used them a lot.

That said, X/Y/Z rotations can easily get converted to a rotation matrix and concatenated with the actual rotation matrix of the object to get the desired result, so I don't see that there is any actual need for euler angles. All you need to do is add an accessor to Matrix3D to get a rotation matrix for each of the independent axes.

I'm sure this is something basic in 3D, but I'm lost at the moment.

Aye, most of us are. :) It's not basic man, and the stuff you guys have done so far is immensely impressive.

I have my own beefs with PV3D, but they lie directly with the sorting of triangle at the moment. I'm struggling with implementing a quadrant renderer, because the project I'm working on right now is not a 'real-time' application - it's a load-this-model-and-render-it project. Unfortunately, that requires some serious code updates.

If anyone can shed any light on how other 3D-apps handle the diverse

'rotation types' (local, global, parent, etc)  i'll be *very* happy.

Hierarchal transformation matrices?

http://www.cs.unc.edu/~hoff/techrep/hierarch.html

It may even be best to store translation, rotation, and scale as separate matrices for performance reasons. I'm not sure if that would help at this time though.

That's just my 0.02. Anyway, I'd much rather see an example of implementing a new dynamic triangle sorter than modifications to the matrices, but that's just me being greedy!

jon

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Andy Zupko]

Some javascript/style in this post has been disabled (why?)

I think it definitely comes down to what is easiest for the user.  Eulers are simple to understand - and like you said - no one understands matrices just by looking at them until they have worked with them for a while and know what a sin is :P

Using the rXYZ as setters is easy and works fine - its when they are updated by the matrix that the problem really occurs - some of the time.  Personally, i feel that for most people most of the time, the euler implementation is the way to go.  People use the euler angles for all sorts of stuff, and removing that real world ability of easily getting an understandable angle would be a bad choice.  That said - they aren't perfect - but if someone has an application that runs into this problem, THEN they can start digging deeper.  Again - just my personal opinion.

If you get a quadrant renderer working let us know :)  We have the basis of a quad-tree in the repo right now - but the main functionality hasnt been added yet.  The biggest problem with the quadtree approach is how slow it is.  Though it is good for static scenes like it sounds like you are dealing with :).  If you are able to build a QuadRenderer let us know - it is something the engine could definitely use!

I've been wondering about the seperation of matrices as well.  I haven't had time to mess with this yet though - been too busy with other stuff. 

thoughts anyone?

On Jul 24, 2008, at 10:10 AM, Jon Bradley wrote:

On Jul 23, 2008, at 9:16 PM, Tim Knip wrote:

Wouldn't it be better to simply choose a single system? As p/y/r work

in the objects 'local' frame of reference, whilst rotationX / Y / Z

work in the 'global' frame of reference.

I agree a single system is better than two. The problem then becomes that of user knowledge. Matrices are far better to work with, but they are absolutely not intuitive unless the person has used them a lot.

That said, X/Y/Z rotations can easily get converted to a rotation matrix and concatenated with the actual rotation matrix of the object to get the desired result, so I don't see that there is any actual need for euler angles. All you need to do is add an accessor to Matrix3D to get a rotation matrix for each of the independent axes.

I'm sure this is something basic in 3D, but I'm lost at the moment.

Aye, most of us are. :) It's not basic man, and the stuff you guys have done so far is immensely impressive.

I have my own beefs with PV3D, but they lie directly with the sorting of triangle at the moment. I'm struggling with implementing a quadrant renderer, because the project I'm working on right now is not a 'real-time' application - it's a load-this-model-and-render-it project. Unfortunately, that requires some serious code updates.

If anyone can shed any light on how other 3D-apps handle the diverse

'rotation types' (local, global, parent, etc)  i'll be *very* happy.

Hierarchal transformation matrices?

http://www.cs.unc.edu/~hoff/techrep/hierarch.html

It may even be best to store translation, rotation, and scale as separate matrices for performance reasons. I'm not sure if that would help at this time though.

That's just my 0.02. Anyway, I'd much rather see an example of implementing a new dynamic triangle sorter than modifications to the matrices, but that's just me being greedy!

jon

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org

[Tim Knip-2]

Agree totally that Euler's should remain.

We just don't want pitch(), yaw() and roll() to update these Euler's
as that goes sour due to the inherent problems with matrix2euler.

We should solve this internally in DO3D. Possible, but gonna take some time.

Tim

2008/7/24 Andy Zupko <[hidden email]>:

> I think it definitely comes down to what is easiest for the user.  Eulers
> are simple to understand - and like you said - no one understands matrices
> just by looking at them until they have worked with them for a while and
> know what a sin is :P
> Using the rXYZ as setters is easy and works fine - its when they are updated
> by the matrix that the problem really occurs - some of the time.
>  Personally, i feel that for most people most of the time, the euler
> implementation is the way to go.  People use the euler angles for all sorts
> of stuff, and removing that real world ability of easily getting an
> understandable angle would be a bad choice.  That said - they aren't perfect
> - but if someone has an application that runs into this problem, THEN they
> can start digging deeper.  Again - just my personal opinion.
> If you get a quadrant renderer working let us know :)  We have the basis of
> a quad-tree in the repo right now - but the main functionality hasnt been
> added yet.  The biggest problem with the quadtree approach is how slow it
> is.  Though it is good for static scenes like it sounds like you are dealing
> with :).  If you are able to build a QuadRenderer let us know - it is
> something the engine could definitely use!
> I've been wondering about the seperation of matrices as well.  I haven't had
> time to mess with this yet though - been too busy with other stuff.
> thoughts anyone?
>
> On Jul 24, 2008, at 10:10 AM, Jon Bradley wrote:
>
> On Jul 23, 2008, at 9:16 PM, Tim Knip wrote:
>
> Wouldn't it be better to simply choose a single system? As p/y/r work
> in the objects 'local' frame of reference, whilst rotationX / Y / Z
> work in the 'global' frame of reference.
>
> I agree a single system is better than two. The problem then becomes that of
> user knowledge. Matrices are far better to work with, but they are
> absolutely not intuitive unless the person has used them a lot.
> That said, X/Y/Z rotations can easily get converted to a rotation matrix and
> concatenated with the actual rotation matrix of the object to get the
> desired result, so I don't see that there is any actual need for euler
> angles. All you need to do is add an accessor to Matrix3D to get a rotation
> matrix for each of the independent axes.
>
> I'm sure this is something basic in 3D, but I'm lost at the moment.
>
> Aye, most of us are. :) It's not basic man, and the stuff you guys have done
> so far is immensely impressive.
> I have my own beefs with PV3D, but they lie directly with the sorting of
> triangle at the moment. I'm struggling with implementing a quadrant
> renderer, because the project I'm working on right now is not a 'real-time'
> application - it's a load-this-model-and-render-it project. Unfortunately,
> that requires some serious code updates.
>
> If anyone can shed any light on how other 3D-apps handle the diverse
> 'rotation types' (local, global, parent, etc)  i'll be *very* happy.
>
> Hierarchal transformation matrices?
> http://www.cs.unc.edu/~hoff/techrep/hierarch.html
> It may even be best to store translation, rotation, and scale as separate
> matrices for performance reasons. I'm not sure if that would help at this
> time though.
> That's just my 0.02. Anyway, I'd much rather see an example of implementing
> a new dynamic triangle sorter than modifications to the matrices, but that's
> just me being greedy!
> jon
> _______________________________________________
> Papervision3D mailing list
> [hidden email]
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>
>
> _______________________________________________
> Papervision3D mailing list
> [hidden email]
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>
>

_______________________________________________
Papervision3D mailing list
[hidden email]
http://osflash.org/mailman/listinfo/papervision3d_osflash.org