Transform3D.setScale(Vector3f) buggy?

Transform3D.setScale(Vector3f) appears to be buggy in that it does not preserve pre-existing rotation. The work-around that I use is to set the scale first and then set the rotation. The setRotation() method does preserve pre-existing scale.

Here is the old code. You can see that is simply overwrites the 3x3 rotation/scale matrix. This only works if there is no pre-existing rotation:


    /**
     * Set this transform to a scaling matrix after setting it to
     * the identity matrix.
     */
    public final void setScale(Vector3f v) {
//        matrix.setIdentity();
//        matrix.setScale(v.x);
        matrix.m00 = v.x;
        matrix.m11 = v.y;
        matrix.m22 = v.z;

        setChanged(true);
    }

Here is my work-around code. It preserves copies of the translation and rotation and then resets everything with the scaling set before the rotation.

       
       transform.get ( translationVector3f );
       
       transform.getRotation ( rotationMatrix3f );
       
       transform.setIdentity ( );
       
       transform.set ( translationVector3f );
       
       transform.setScale ( scaleVector3f );
       
       transform.setRotation ( rotationMatrix3f );

Here is the javadoc for Matrix4f.setRotation():

Unfortunately Matrix4f does not have a setScale(Vector3f) method, only a setScale(float) method.

How about we fix Transform3D.setScale(Vector3f) by replacing the old code with something like the work-around?

transform.setIdentity ( ); is a redundant step in your workaround.

you also could use transform.setTranslation ( translationVector3f ); in the next line to save CPU cycles, because all the other transform matrix elements get overwritten by transform.setScale and transform.setRotation independently of their previous state.

correct?

[quote]How about we fix Transform3D.setScale(Vector3f) by replacing the old code with something like the work-around?
[/quote]
Nice idea, but we would have to keep the old setScale:

  1. most people use that function in the way it works now.
  2. you use it in your work-around code. :wink:

Maybe you could add a method scale(Vector3f) that contains your workaround.

[quote]Unfortunately Matrix4f does not have a setScale(Vector3f) method, only a setScale(float) method.
[/quote]
This is, because in a Matrix4f you can save a uniform scale at the low right corner of the 4x4 Matrix. This scale is totally independent of your scale in the 3x3 rotation part and it also applies for the translation.
(At least I believe it is like this)

Arne

I think the question is what is the authoritive specification?

For this I believe it is the javadocs for Java3D’s Transform3D: http://java.sun.com/products/java-media/3D/forDevelopers/J3D_1_3_API/j3dapi/javax/media/j3d/Transform3D.html

It specifies setScale as:

Xith Transform3D is missing setRotationScale(Matrix3f). Most folks will want to use that for rotation or scaling since it is faster because it does not need to preserve a pre-existing transform through a factoring process. We could implement setRotationScale() and then add some cautionary javadoc to setScale(Vector3f) advising them to use setRotationScale() instead for performance reasons if they do not need to preserve the rotation.

Thanks. I will explore further.

I created a patch and filed it as a bug report:
https://xith3d.dev.java.net/issues/show_bug.cgi?id=105

Hi,

I will take a look at it on Sunday and will apply if everythink is OK.

Yuri

P.S. Sorry - have not so much time these days

It has been a month. Is there someone else who can add this method if you do not have the time?

croft, sorry - I completely forgot about this issue… WIll take care of it ASAP.

Yuri

I can do it if you’re really busy, yvg.

[quote="<MagicSpark.org [ BlueSky ]>,post:11,topic:25001"]
I can do it if you’re really busy, yvg.
[/quote]
It has been two months now. I am still interested in seeing this fixed.

I also filed a new bug report:
https://xith3d.dev.java.net/issues/show_bug.cgi?id=106

I goofed. The first part of the my above bug report was correct but the 2nd part was wrong. I stated the following:
“Also, the javadoc for rotXYZ() is a bit confusing in that it suggests it sets the rotation. I believe it actually rotates relative to the current rotation.”

I see now that the correct answer is that it sets the rotation without regard to the current rotation and that is the way it is supposed to be.

I filed two new javadoc patch bug reports:
https://xith3d.dev.java.net/issues/show_bug.cgi?id=107
https://xith3d.dev.java.net/issues/show_bug.cgi?id=108

Thanks for fixing.

Here is a related enhancement request:
https://xith3d.dev.java.net/issues/show_bug.cgi?id=109
http://java.sun.com/products/java-media/3D/forDevelopers/J3D_1_3_API/j3dapi/javax/media/j3d/Transform3D.html#setEuler(javax.vecmath.Vector3d)

Ah ok so I’ll fix it one more time.

OK I’ll do that ASAP. You don’t have Developer access yourself ? You could ask YVG or willdenniss to grant you.

[quote="<MagicSpark.org [ BlueSky ]>,post:15,topic:25001"]

OK I’ll do that ASAP. You don’t have Developer access yourself ? You could ask YVG or willdenniss to grant you.
[/quote]
I do not have developer access to xith3d. Please remember to fix bug #108.

Fixed all of them.