New version 2.4: axis and up

[Bruce Sherwood]

New GlowScript version 2.4 fixes a long-standing error in changing "axis" without updating "up" to remain perpendicular to axis (and vice versa). The result was that rotating an object by continually changing its axis could cause abrupt changes in the appearance of the object. This was noticeable only if an object had a texture or a compound object lacked symmetry, which is presumably why the problem doesn't seem to have been noted for many years.

Here is an example of a program running in version 2.3 that illustrates the problem. Note that "up" doesn't change, and there's a problem when "axis" and "up" point in the same direction:

   http://www.glowscript.org/#/user/Bruce_Sherwood/folder/Pub/program/RotatingAxis2.3

Here is the same program running version 2.4, which works properly. Note that "axis" and "up" are always perpendicular to each other:

   http://www.glowscript.org/#/user/Bruce_Sherwood/folder/Pub/program/RotatingAxis2.4

For further details, see 

   http://www.glowscript.org/docs/VPythonDocs/box.html

[Bennett Weaver]

In checking a malfunction that worked in v2.2 but failed in 2.3, I discovered a work around when using the object axis to rotate instead of the rotate method. Although a physics major over 50 years ago, my vector math is a bit rusty, but the work arouind consisted of using the mag() method and the size to scale the new axis appropriately. This didn't work directly with v2.4. However, the problem appears to be a bug when using the axis argument with the compound method. according to previous usage and documentation, the axis in that instance just rotates the object on the appropriate axis without scaling. The bug seems to be that it works as stated, except of the z-axis argument. When the z-axis argument is not zero, scaling to a magnitude of z to 1 occurs. Sorry I don't have a good code snippet to include at this time. I have a deadline. Maybe more later. TIA

[Bruce Sherwood]

I hope when you have time that you can provide a test case that demonstrates the problem. Thanks.

[Bennett Weaver]

I thought that might get your attention.  ;-)

I will try to do so in the next couple of days. If your eyes and fingers are getting as old as mine, I suspect it is a typo buried somewhere that will be a bear to spot. That is frequently the problem with my coding. Cheers.

[Bennett Weaver]

In writing a demo program for this error, I ran into something else. It may be a parsing error in the compiler, or possibly a syntax error that I don't see (not a lot of experience with python). As noted in the program listing here: http://www.glowscript.org/#/user/bcweaver448/folder/bugs/program/possibleclonebug as noted in the comments, line 18 works if executed there, but not if executed after line 19. Your thought, please. It has me stumped.

[Bennett Weaver]

Further exploration seems to indicate that operations in the z-plane will not render if executed after a clone in the y-plane as noted in this program: http://www.glowscript.org/#/user/bcweaver448/folder/bugs/program/zplaneprob
A possible camera preoblem?

[Bruce Sherwood]

Yes, I too had come to that conclusion. The attributes of the unseen clone look okay except that the axis is in the -y direction instead of the +z direction, and one would expect something to be displayed (incorrectly) instead of the clone being invisible. Obviously something is broken in the clone machinery, perhaps a typo in the JavaScript code that was waiting for your program to spring the surprise.

It's probably not a camera problem, since rotating the camera doesn't change the situation.

[Bennett Weaver]

This programs that I have submitted to you this evening work as expected under V2.3 and fail as noted under V2.4

[Bruce Sherwood]

Right. The problem is associated with 2.4's attempt to make sure that axis and up are always perpendicular to each other. For reasons I don't yet understand, the clone is being created with axis and up in the same +y direction, which explains why it isn't displayed (the GPU chokes on this case). I don't yet understand how the orthogonality isn't maintained.

[Bennett Weaver]

I'll craft a demo for the first problem noted not using clone to see if there is still the original problem.

[Bennett Weaver]

Bruce , hope I am not too much of a PITA. a new demo program has been generated. There are comments regarding my understanding of how things are supposed to work, but my knowledge is marginal. I have included some label and print statements to display variables. Good luck with the implied math to determine a fix. If I can be of any help, drop me a line,

Latest program: http://www.glowscript.org/#/user/bcweaver448/folder/Private/program/BugReport

[Bennett Weaver]

Sorry for the bad link. Try this one.

http://www.glowscript.org/#/user/bcweaver448/folder/bugs/program/bugreport

[Bruce Sherwood]

Thanks much for the helpful demo concerning compound objects.

[Bruce Sherwood]

The clone problem has now been fixed in GlowScript 2.4. Thanks much for the clear report!

I might be missing something but I don't see anything wrong with the demo of compounds. Here is the relevant paragraph from the Help on compound objects, which shows why setting axis has the effects you demonstrate:

Linkage of axis and size: After creating the hammer as a compound object, changing the axis rotates the combined object. As with other objects such as box or cylinder, changing the axis not only rotates the object but its length (size.x) is set equal to the magnitude of the axis vector. Similarly, changing the size sets the magnitude of the axis vector to be equal to the length (size.x).

[Bennett Weaver]

Thanks for the quick fix. Was the bug a typo or was it something else?

Regarding what I thought was wrong with the axis was my eyes had seen "size" and not "size.x" regarding the change in size with axis change. Now I have to determine if this misunderstanding of mine is causing another error in my other aoolication. I have an objects the is pointed at another object. When the second object moves, I need to repoint the first. I was trying to use vectors and the axis rather than rotates to accomplish this. I had what I thought was a solution, but now I will double check.

Thanks, again.

[Bruce Sherwood]

No, it wasn't a typo but something rather fundamental. When you create a 3D object, the defaults are axis = vec(1,0,0) and up = vec(0,1,0), so axis and up start out being orthogonal. Then the attributes of this particular object are applied one after another, and setting axis also moves up to still be orthogonal to axis, and setting up also moves axis to still be orthogonal to up. The functions to do this were well tested. 

What I had failed to test was your case, of cloning an object and changing its axis. Cloning of an object is done by calling the constructor with all arguments of the original object (pos, axis, size, up, etc.). Alas, that meant that axis and up were starting not from the standard values (<1,0,0> and <0,1,0>) but from whatever the to-be-cloned object's axis and up were, for which the axis-up orthogonalization functions failed.

The solution was not to specify up in creating the new object, so that setting axis would create an orthogonal up but there would be no modification of axis by up. Then after the clone is created, the new up is applied.