cannot scale a 3D vector length as desired

[WCR]

I am attempting to display a 3D vector in a scene. I want the vector position, direction, and length to vary with time. The atached program dmonstrates this.  The vector position and direction change as desired, but the length does not change as desired.  The problem may be clear if you run the attached VI.  Basically, I create a vector oriented along the Z axis.  With each time step, I change its length along Z, then translate it to the desired position, then rotate it to the desired direciton.  The problem is that the Z component cycles between 0 and 1, instead of the length cycling between 0 and 1.

I have searched discussion forums for assistance, to no avail. 

I assumed that this was happening because the z-component of the most recently displayed version of hte vector was being scaled, instead of scaling the the z component of the INITIAL vector, which points along the z axis.  Therefore I tried creating 2 copies of the vector object.  One copy is the "variable" copy whic is transformed and displayed.  The other is kept untransformed.  At each stime step I copy the untransformed one to the transformed one, then transform it.  This did not cure the problem.  I tried clearing all transformations at the end of each timestep - and this is in the verion I ma posting.  However, this does not fix the problem.

One solution I have seen for this problem is to create a new vector object during each time step, then add it to the scene, then scale it, translate it, and rotate it.  Then, after it is displayed, the object is removed from the scene.  Then a new vector object is created for the next time step.  This seems computationally inefficient and inelegant, and I worry about memory filling up, since I would be creating a new object every 50 msec. 

Two subVIs (DrawUnitArrow, DrawUnitAxes) are also attached.

Thank you.

[Kimchi-Taco]

Hello, can you tell us what forums and resources you've already looked at?

Thanks,

[WCR]

I searched for help on this LV forum and google searched. Found some stuff at instructables.com, but it was not quite relevant, and it seemed to require some 3rd party code.

[spatry]

The experimenting I did with that code, seems to indicate a bug with the rotation VI, the length and translation work fine on their own, but adding rotation causes issues.

[akovaski · Accepted solution]

In the VI's you posted, if you replace the 'Set Rotation' vi with a 'Rotate Object' vi, I believe you get the behavior you desire. (You probably also want to rotate before you translate)

[WCR]

Spatry,

Thank you for trying.  I am not sure that it qualifies as a bug, but it is definitely an interaction between scaling and rotating that I did not anticipate.  If you keep the rotation as is, and scale by a factor of 1 along all 3 axes at each time step, you get the expected behavior, which to me suggests that rotation works as it should. Plus I and my students have used 3D rotations in a number of VIs with no issues.

[WCR]

Akovaski,

You are right!  I did not expect your approach to work, because RotateObject rotates the object from its last known position, and the angles I am passing are the desired rotation angles from the original position. But your method does work, and I realize it does so because after each time step, I do Clear Transformation, which moves arrow back to its default location.  (I still don't know why my original approach fails the way it does, but I don't care.)  As you predicted, it was also necessary to reverse the order of transformations to Rotate, then Translate. Thank you! 

[Intaris]

Your approach fails because you translate before rotating.  This is almost certainly going to lead to issues.

Scale first, then rotate and then translate.  3D operations are NOT commutative.  The order of the operations matters.

[WCR]

Thank you for your comment.  I am familiar with non-commutativity of 3D transformations.  In fact 3D rotations themselves do not commute, as the 3D rotation matrices don't commute (but the 2D rotation matrices do commute). I think what is going on here is a little more subtle.

[Intaris]

If you would save to an earlier version of LV (I have 2012) then I could actually look at the code.  My comments are thus, unfortunately, born purely of the textual exahnges taking place here.

Main thing is that you have a working solution.