Editing Appendix/Ramblings/OculusRiftS (section)

===Model Try06===

Let's approach this from the opposite direction.  We'll start with the relatively simple "Try06" model &#8212; whose animated component (the large purple cube) works inside my Oculus Home &#8212; and replace the large purple block with the more sophisticated Riemann ellipsoid geometry pulled from DImod07.dae.

<ul>
<li>
<table border="0" align="right" cellpadding="10"><tr><td align="center">
<table border="1" align="center" cellpadding="5"><tr><td align="center">
Mac Preview of Try06_Zup03.dae</td></tr>
<tr><td align="center" bgcolor="lightgrey">[[File:Try06_Zup03Small.png|300px|Mac Preview of Try06_Zup03.dae]]</td></tr>
</table>
</td></tr></table>
<font color="darkgreen">Try06_Zup01.dae on 19 April 2020</font>:
Let's use this as the base model, since it definitely works in my Oculus Home.</li>
<li><font color="darkgreen">Try06_Zup02.dae on 19 April 2020</font>:
<br />Inserted &hellip;
  <ol><li>
<effect id="DiffuseRed_EFE">
</li>
<li><material id="ID6_EFE" name="material"> which references DiffuseRed_EFE</li>
<li><library_nodes><node id="ID3_EFE" name="cube_component"> which references ID6_EFE **and** "#SimpleCube" geometry</li>
<li><visual_scene> inside <node id="Third">, replaced last line to read, <instance_node url="#ID3_EFE" /></li>
  </ol>
</li>
<li>
<font color="darkgreen">Try06_Zup03.dae on 19 April 2020</font>: &nbsp; &nbsp; Mac Preview image of this model shown here, on the right -->
  <ol><li>
<library_nodes><node id="ID3_EFE" name="cube_component"> replaced referenced geometry with "#EllipsoidOctant" geometry</li>
<li>Inserted 2555 lines of code that defines <geometry id="EllipsoidOctant"></li>
  </ol>
<font color="red"><b>THIS WORKS!!</b></font> &nbsp; &nbsp;  Inside my Oculus Rift S Home, the single red octant starts out a bit tilted (as did the large cube), then it spins about its (longest) x-axis.  Note, however, that when we open this .dae file inside the Mac Preview app, it spins about the (shortest) z-axis.  Why is this?
</li>
<li><font color="darkgreen">Try06_Xup03.dae and Try06_Yup03.dae on 20 April 2020</font>:
<br />Both of these new COLLADA files are identical to Try06_Zup03.dae ''except'' inside the <asset> specification, Z_UP has been changed to X_UP and Y_UP, respectively.  When these new files were imported into the Oculus Rift S, the layout of the purple blocks and relative position/orientation of the red ellipsoid octant was ''identical'' to the Z_UP model.  The only thing that changed was the orientation of the coordinate system &#8212; e.g., the white circular hoop defining the equatorial plane &#8212; that is used by the Oculus hand-controllers.  This all makes logical sense, but it is still unclear why the animation specified inside the COLLADA file leads in all three cases to a red ellipsoid octant that is spinning about the model's z-axis.
</li>
<li><font color="darkgreen">Try06_ZupXrot04.dae on 20 April 2020</font>:
<br />A couple of changes have been made in the COLLADA file in an attempt to make the ellipsoid octant spin about a different axis inside the Oculus Rift S.
  <ol><li>
At the end of <animation>, changed the target from "Third/rotationZ.ANGLE" to "Third/rotationX.ANGLE"</li>
<li><visual_scene> inside <node id="Third">, changed initial value of the "rotationX" angle from 10.0 to 0.0</li>
  </ol>
As a result, the Mac Preview app **did** make the ellipsoid octant spin about the (longest) x-axis instead of the (shortest) z-axis, but after the .glb file equivalent was imported into the Oculus Rift S, nothing changed, that is, the ellipsoid octant spun, as before, about the (longest) x-axis.  NOTE:  When viewed using the Mac Preview app, the ellipsoid octant spins in the opposite direction to the spin viewed inside the Oculus Rift S.
</li>
<li><font color="darkgreen">Try06_ZupXrot05.dae on 20 April 2020</font>:
<br />A few minor alterations &hellip;
  <ol><li>
Set start and end animation times to 0.0 and 20.0, respectively;</li>
<li>Set "end" value of angle to -135 degrees;</li>
<li>Inside the "Third" node of <visual_scene>, commented out the sid="rotationY" and sid="rotationZ" declarations.
  </ol>
Inside the Oculus Rift S home, the initial orientation of the ellipsoid octant remained as before, but this time it spun in the opposite direction [as desired/intended] and it seemed to be interpreting the unit of time as one second.
</li>

<li>
<table border="1" align="right" cellpadding="8" width="25%">
<tr><td align="center">Zup Zrot06</td></tr>
<tr><td align="left">
target="Third/RotationZ.ANGLE" <br />[0 --> -135]<br />
rotation X, Y, Z = 0.0, 0.0, 180.0
</td></tr>
</table>
<font color="darkgreen">Try06_ZupZrot06.dae on 20 April 2020</font>:
<br />A couple of seemingly minor alterations &hellip;
  <ol><li>
Assigned a unique "name" to each node under <library_nodes>;</li>
<li>Inside the "Third" node of <visual_scene>, retained all 3 "sid" rotations, but assigned a nonzero (180&deg;) ANGLE value to (only) the sid="rotationZ" declaration.
  </ol>
<font color="red"><b>WORKS!</b></font> &nbsp;&nbsp; This time, inside the Oculus Rift S home, the ellipsoid octant spun about the Z-axis, as desired.
</li>

<li><font color="darkgreen">Try06_ZupZrot07.dae on 20 April 2020</font>:
<br />Changed starting ANGLE of rotationZ from 180&deg; to 45&deg;
<br />RESULT:  Apparently Oculus does not pay attention to the starting angle for the axis (e.g., rotationZ) of rotation that is being animated.
</li>

<li><font color="darkgreen">Try06_ZupYrot07.dae on 20 April 2020</font>:
<br />Trying to animate "rotationY" instead of "rotationZ", starting from rotationY = 45&deg;
<br />RESULT:  This is the first time that Oculus correctly depicts rotation about the intermediate (Y) axis.
</li>
<li>
<table border="1" align="right" cellpadding="8" width="25%">
<tr><td align="center">Zup Yrot08</td></tr>
<tr><td align="left">
target="Third/RotationY.ANGLE" <br />[90 --> -45]<br />
rotation X, Y, Z = 90.0, 10.0, 0.0
</td></tr>
</table>
<font color="darkgreen">Try06_ZupYrot08.dae on 20 April 2020</font>:
<br />NEXT &hellip;
<ol>
  <li>Try inserting a different starting angle inside the "animation" specification of starting and ending ANGLEs; specifically told it to run "rotationY" from +90&deg; to -45&deg;</li>
  <li>Try spinning about the Y-axis after initially reorienting the X-axis; specifically set initial values of rotationX = 90; rotationY = 10; rotationZ = 0</li>
</ol>
RESULT:  It looks as though it **did** initially spin about the x-axis by 90&deg; and it looks like it spun about the Z(!) axis from 90&deg; to -45&deg;.  Why did it spin about the Z-axis instead of about the Y-axis?   Perhaps it will shift to the Y-axis if I set rotationY = 0.0 (instead of 10.0) initially.
<br />
<font color="red"><b>WAIT &hellip;</b></font>&nbsp; &nbsp; The observed behavior inside Oculus makes sense because after the ellipsoid octant is initially spun about the X-axis by 90&deg;, the body frame's Y-axis is pointing straight up, in the direction of the original Z-axis.  So, spinning about the (new) Y-axis looks as though the object is spinning about its original Z-axis.  Yeah!!
</li>
<li>
<table border="1" align="right" cellpadding="8" width="25%">
<tr><td align="center">Zup Zrot10</td></tr>
<tr><td align="left">
target="Third/RotationY.ANGLE" <br />[0 --> +135]<br />
rotation X, Y, Z = 180.0, 90.0, 45.0
</td></tr>
</table>
<font color="darkgreen">Try06_ZupZrot10.dae on 21 April 2020</font>:
<br />NEXT &hellip;
</li>
</ul>

<font color="red"><b>SUMMARY:</b></font>
<ul>
<li>If the animation targets rotation about the Z-axis (Y-axis), then the 3D visualization algorithm ignores the initially assigned [static] value of the rotationZ (rotationY) ANGLE.</li>
<li>It definitely matters in which order the rotations are implemented.  For example, inside the <node id="Third"> specification the rotations are executed from the top, down; if they are listed in the order &hellip; rotationX, rotationY, rotationZ &hellip; and the animation is about the Z-axis, then the initial setup executes rotationX before rotationY and it ignores rotationZ.  However,  if they are listed in the order &hellip; rotationY, rotationX, rotationZ &hellip; and the animation is about the Z-axis, then the initial setup executes rotationY before rotationX and it ignores rotationZ.  </li>
</ul>