Editing Appendix/Ramblings/RiemannMeetsOculus (section)

==Assemble Components==

<ul>
  <li>
<font color="darkgreen"><b>RiemannBuild00.dae</b></font>:
<ul>
<li>This model, with <up_axis>Z_UP></up_axis>, contains a set of purple cubes that lie in the Y<sub>0</sub>-Z<sub>0</sub> plane, and along the inertial frame's X<sub>0</sub> axis from -5.0 inches to +5.0 inches; the last purple "cube" (at X<sub>0</sub> = +5) is actually a rectangular box whose longest axis is parallel to the Z<sub>0</sub> axis.
<table border="0" align="center" cellpadding="10"><tr><td align="center">
<table border="1" align="center" cellpadding="5"><tr><td align="center">
Mac Preview of RiemannBuild00.dae</td></tr>
<tr><td align="center" bgcolor="lightgrey">[[File:RiemannBuild00Small.png|400px|Mac Preview of RiemannBuild00.dae]]</td></tr>
</table>
</td></tr></table>
</li>  
<li>The scene also includes a red ellipsoid with axis ratios b/a = 0.41 and c/a = 0.385.  The "EntireEllipsoid" has been ''scaled'' such that its longest ( c ) axis has a length of 4 inches; and it has been ''translated'' in the Y<sub>0</sub>-Z<sub>0</sub> plane to a location along the Y<sub>0</sub> axis where the center of the ellipsoid is 8.0 inches from the origin of the inertial coordinate system.  The ellipsoid's "First" quadrant <node> was, in addition, scaled by (1.1, 1.1, 1.1) in order for it to stick out a bit from the other quadrants to help the viewer decipher its rotational behavior.
<pre>
          <node id="EntireEllipsoid" name="OculusRift_EFE">
             <translate>0.0 8.0 0.0</translate>
             <rotate sid="rotationY">0.0 1.0 0.0  90.0</rotate>
             <rotate sid="rotationZ">0.0 0.0 1.0  90.0</rotate>
             <rotate sid="rotationX">1.0 0.0 0.0  90.0</rotate>
             <scale sid="scale">4.0 4.0 4.0</scale>
                <node id="First" name="First_instance_EFE">
                  <translate>0.0 0.0 0.0</translate>
                  <rotate sid="rotationX">1.0 0.0 0.0  0.0</rotate>
                  <rotate sid="rotationY">0.0 1.0 0.0  0.0</rotate>
                  <rotate sid="rotationZ">0.0 0.0 1.0  0.0</rotate>
                  <scale sid="scale">1.1 1.1 1.1</scale>
                  <instance_node url="#ID3_EFE" />
                </node>
                ...
</pre>
</li>  
<li>The default orientation of the "EntireEllipsoid" is <math>~(a, b, c) \Leftrightarrow ~ (X_0, Y_0, Z_0)</math>.  But for this model, before the animation starts, the "EntireEllipsoid" is reoriented by turning it 90&deg; in Y, then 90&deg; in Z, then 90&deg; in X; as displayed in the above image, this resulted in an alignment of <math>~(a, b, c) \Leftrightarrow ~ (Y_0, X_0, -Z_0)</math>.
</li>
<li>
The set of <animation> instructions includes a specification that, (1) TIME start at 0.0 seconds and end (one animation loop) at 10.0 seconds; (2) over this time interval, the rotation ANGLE should start at 90&deg; and end at 270&deg; [in COLLADA, it is understood that the ANGLE will vary ''linearly'' with TIME, unless explicitly specified otherwise]; and (3) via the <channel/target> instruction, the rotation should be about the longest (rotationX) axis of the ellipsoid.
<pre>
      <float_array id="First_rotation_euler_Y-input-array" count="    2">
    0.0000
   10.0000
      </float_array>
                ...
      <float_array id="First_rotation_euler_Y-output-array" count="    2">
    90.0
   270.0
      </float_array>
                ...
    <channel source="#First_rotation_euler_Y-sampler" target="EntireEllipsoid/rotationX.ANGLE"/>
</pre>
</li>
</ul>
</li>
<li>
<font color="darkgreen"><b>RiemannBuild02.dae</b></font>:
<ul>
<li>
Got rid of all of the <visual_scene><nodes> that had been used to create the line of purple "cubes";  set the "EntireEllipsoid" <translate> coordinate to zero in all three dimensions so that the center of the red ellipsoid coincided with the origin of the principal frame of reference; set to zero the values of all three <rotate> ANGLEs for the "EntireEllipsoid" so that the red ellipsoid was initially positioned in its default orientation, that is, <math>~(a, b, c) ~\Leftrightarrow ~(X_0, Y_0, Z_0)</math>; 
<br />
<pre>
            <node id="EntireEllipsoid" name="OculusRift_EFE">
             <translate>0.0 0.0 0.0</translate>
             <rotate sid="rotationX">1.0 0.0 0.0  0.0</rotate>
             <rotate sid="rotationY">0.0 1.0 0.0  0.0</rotate>
             <rotate sid="rotationZ">0.0 0.0 1.0  0.0</rotate>
             <scale sid="scale">5.0 5.0 5.0</scale>
                <node id="First" name="First_instance_EFE">
                  <translate>0.0 0.0 0.0</translate>
                  <rotate sid="rotationX">1.0 0.0 0.0  0.0</rotate>
                  <rotate sid="rotationY">0.0 1.0 0.0  0.0</rotate>
                  <rotate sid="rotationZ">0.0 0.0 1.0  0.0</rotate>
                  <scale sid="scale">1.1 1.1 1.1</scale>
                  <instance_node url="#ID3_EFE" />
                </node>
                ...
</pre>
and set the <animation> parameters such that, over a 10 second interval of time, using the <channel &hellip; target="EntireEllipsoid/rotationZ.ANGLE"/> directive the ellipsoid was instructed to spin ''about the shortest ( c ) axis'', from 0&deg; to 180&deg;.
<br />
<pre>
      <float_array id="First_rotation_euler_Z-input-array" count="    2">
    0.0000
   10.0000
      </float_array>
                ...
      <float_array id="First_rotation_euler_Z-output-array" count="    2">
    0.0
   180.0
      </float_array>
                ...
    <channel source="#First_rotation_euler_Z-sampler" target="EntireEllipsoid/rotationZ.ANGLE"/>
</pre>
</li>
</ul>
RESULT:  Using the Mac's Preview app to view this modified COLLADA file, the (now) isolated red ellipsoid did spin, as desired, through 180&deg; about the ellipsoid's shortest axis.  <font color="red">But when imported into the Oculus Rift S environment, the isolated red ellipsoid was spinning about the ellipsoid's longest axis.</font>  I don't understand why!
</li>
<li>
<font color="darkgreen"><b>RiemannBuild03.dae</b></font>:
<br />Here, we implemented only two changes to the COLLADA code: &nbsp; (1) We modified the "EntireEllipsoid" <node>'s "rotationZ" instruction to specify that, prior to implementing the rotation, the ellipsoid should be turned 1&deg; [instead of zero degrees] about the shortest ( c ) axis; 
<br />
<pre>
            <node id="EntireEllipsoid" name="OculusRift_EFE">
             <translate>0.0 0.0 0.0</translate>
             <rotate sid="rotationX">1.0 0.0 0.0  0.0</rotate>
             <rotate sid="rotationY">0.0 1.0 0.0  0.0</rotate>
             <rotate sid="rotationZ">0.0 0.0 1.0  1.0</rotate>
             <scale sid="scale">5.0 5.0 5.0</scale>
                ...
</pre>
and (2) inside the set of <animation> instructions, we specified that the time-dependent ANGLE should have a ''starting'' (TIME = 0.0) value of 1&deg; and an ''ending'' (TIME = 10.0) value of 180&deg;.
<br />
<pre>
      <float_array id="First_rotation_euler_Z-output-array" count="    2">
    1.0
   180.0
      </float_array>
                ...
</pre>
<br />
RESULT:  The desired behavior &#8212; that is, spinning about the shortest ( c ) axis from 1&deg; to 180&deg; &#8212; was observed in ''both'' the Mac's Preview app and in the Oculus Rift S environment.  But I don't actually understand why the Oculus import resulted in two quite different spinning motions, given that the starting ANGLE was only changed from 0&deg; to 1&deg;.
</li>
<li>
<font color="darkgreen"><b>RiemannBuild05.dae</b></font>:
<br />Pulling from the file named, b41c385_DI.dae, we added a "MidPlane Frame" to the visual_scene.  This worked in the Oculus Rift S environment as well as in the Mac's Preview app (see image immediately below).
</li>
</ul>

<table border="1" align="center" cellpadding="5">
<tr>
  <td align="center" colspan="3">Mac Preview of &hellip;</td>
</tr>
<tr>
<td align="center">
RiemannBuild05.dae
</td>
<td align="center">
RiemannBuild06.dae
</td>
<td align="center">
RiemannBuild09D.dae
</td>
</tr>
<tr>
<td align="center" bgcolor="lightgrey">
[[File:RiemannBuild05small.png|250px|Mac Preview of RiemannBuild05.dae]]
</td>
<td align="center" bgcolor="lightgrey">
[[File:RiemannBuild06.png|250px|Mac Preview of RiemannBuild06.dae]]
</td>
<td align="center" bgcolor="lightgrey">
[[File:RiemannBuild09D.png|250px|Mac Preview of RiemannBuild09D.dae]]
</td>
</tr>
</table>

<ul>
<li>
<font color="darkgreen"><b>RiemannBuild06.dae</b></font>:
<br />Pulling from the file named, b41c385_DI.dae, we added a "Black Cylindrical Pointer" to the visual_scene.  This worked in the Oculus Rift S environment as well as in the Mac's Preview app.
</li>

<li>
<font color="darkgreen"><b>RiemannBuild09D.dae</b></font>:
<br />After much trial and error, we have successfully introduced two separate animation instructions.  In addition to instructing the visual scene to spin the red ellipsoid about its "c" axis at a specific rate, we can now instruct the visual scene to spin the "MidPlane Frame" about the same axis, but in the opposite direction (at any specified rate), in order to mimic a rotating frame of reference.  As the above image from the Mac Preview app shows, we have also added a second "Black Cylindrical Pointer", orienting it in the positive Z<sub>0</sub> direction; and we have removed the special scaling of the "First" quadrant of the ellipsoid that had been introduced in earlier models to break the geometric symmetry of the object, thereby helping us to keep track of changes in the model's spin directions and rates.
</li>

<li>
<font color="darkgreen"><b>RiemannBuild09G.dae</b></font>:  Fixed the way the second "Black Cylindrical Pointer" is handled.
</li>
</ul>


<table border="1" width="75%" cellpadding="5" align="center">
<tr>
<td align="center" bgcolor="#FFFF66">

<table border="1" width="100%" cellpadding="10" align="center"><tr><td align="left">
<div align="center">CAUTION!</div>

As we have been developing 3D VR/AR scenes using <xml>-based COLLADA coding, we have come to appreciate that this approach to code development can be very unforgiving.  Generally speaking, the application that is used to render a scene based on the COLLADA-code's instructions &#8212; our primary choice is the Mac Pro's Preview app &#8212; must by necessity be picky about how it interprets each line of code.  But when a coding error occurs, feedback from the app is very poor: at best the app renders a quirky scene; more often than not, it simply balks and offers no explanation.  

Of more concern is our realization that an entirely different app that &#8212; according to online documentation &#8212; is supposed to be able to render COLLADA-designed 3D scenes will balk at displaying a scene despite the fact that the Mac's Preview app has done so without complaint.  In the context of this discussion, the "different app" to which we are referring is the Khronos Group's (KG's) COLLADA2GLTF-bin converter which translates the xml-based COLLADA code into a format that the Oculus Rift S can import/read.  This appears to indicate that the KG &#8212; and/or the Oculus Rift &#8212; developers place stricter interpretations on various COLLADA-code instructions than does Apple via its Preview app.  But from our point of view, this raises the level of code-development frustration.

Three specific examples of note:
<ul>
<li>In a portion of the <animation> specifications that appear in our model named, <font color="darkgreen"><b>RiemannBuild09D.dae</b></font>, we included instructions intended to spin the red ellipsoid about its "c" axis from ANGLE = +4&deg; to +48&deg; over a TIME = 0 to 10.0388 seconds.  Consistent with this <animation> instruction, we included within the <node id="EntireEllipsoid"> setup an instruction to set the "rotationZ" ANGLE = 4.0 initially.
<br />
<pre>
            <node id="EntireEllipsoid" name="OculusRift_EFE">
             <translate>0.0 0.0 0.0</translate>
             <rotate sid="rotationX">1.0 0.0 0.0  0.0</rotate>
             <rotate sid="rotationY">0.0 1.0 0.0  0.0</rotate>
             <rotate sid="rotationZ">0.0 0.0 1.0  4.0</rotate>
             <scale sid="scale">5.0 5.0 5.0</scale>
            ...
</pre>
<p>
This set of instructions produced the desired result when the ".dae" model file was opened in the Mac Pro's Preview app ''and'' when it's equivalent ".glb" file was imported into the Oculus Rift S.  <font color="red">SUCCESS!</font></p>

In the model file that we tested immediately preceding model <font color="darkgreen"><b>RiemannBuild09D.dae</b></font>, however, the <node id="EntireEllipsoid"> setup included an instruction to set the "rotationZ" ANGLE = 0.0 initially.  The Mac's Preview app generated an animated and interactive 3D scene that was identical to the one it generated from the <font color="darkgreen"><b>RiemannBuild09D.dae</b></font> file, apparently ignoring the fact that the initial angle of 0&deg; did not match the angle of 4&deg; that was specified for TIME = 0 inside the set of <animation> instructions.  However, when the ".glb" version of this model file was imported into the Oculus Rift S, the animation was quite different:  The red ellipsoid spun slowly about its longest (a) axis instead of about its shortest ( c ) axis.  [See a similar behavior discussed above in connection with our model named <font color="darkgreen"><b>RiemannBuild02.dae</b></font>.]   It is unclear why the two different visualization applications generated quite different results from one another.
</li>
<li>
At the same time we inserted into the COLLADA code <animation> instructions that were designed to spin the red ellipsoid (counter-clockwise) from +4&deg; to +48&deg; over the time interval 0 - 10.0388 seconds, we also inserted <animation> instructions that were designed to spin the MidPlane Frame (clockwise) from -30&deg; to -525&deg; over the same time interval.  This additional set of instructions worked as desired when the model was read into the Mac's Preview app.  But when viewed inside the Oculus Rift S, the spin of the MidPlane Frame was very (unacceptably) slow.  After some experimentation, we deduced that the MidPlane's spin would be incorrect if the MidPlane was asked to rotate ''clockwise'' through more than one full cycle (i.e., more than -360&deg;). After some thought, we decided to use <animation> instructions that would dictate a positive initial spin ANGLE (about the ellipsoid's "c" axis) whose value increases with TIME ''and'' use the <node>'s initial "rotationX" instruction to flip the MidPlane Frame over by an angle of 180&deg;.  This gave us the desired result &#8212; that is, a brisk clockwise spin &#8212; when the model was viewed via the Mac's Preview app ''and'' when it was imported/viewed in the Oculus Rift S environment.
<br />
<pre>
            <node id="MidPlane" name="instance_MidPlane">   <!-- TWO -->
              <translate>0.0 0.0 0.0</translate>
                  <rotate sid="rotationX">1.0 0.0 0.0  180.0</rotate>
                  <rotate sid="rotationY">0.0 1.0 0.0  0.0</rotate>
                  <rotate sid="rotationZ">0.0 0.0 1.0  30.0</rotate>
              <scale sid="scale">1.25 1.25 1.25</scale>
              <instance_node url="#EqPlane" />
            </node>                                         <!-- /TWO -->
</pre>
</li>
<li>
[[#Implement_Decrement_Idea|As has been addressed in a separate discussion, below]], we have figured out that a better way to achieve a clockwise spin is ''not'' to start with a small negative ANGLE then make it ''more'' negative over time, but rather to start with a large positive ANGLE then decrement it to make the ANGLE less positive over time.  Presumably this means that we should always specify this "decrement" scheme in such a way that the ANGLE value is never negative.  Actually, the Mac Preview app is okay with negative values of ANGLE, but it appears as though the Oculus Rift S (or, perhaps, the KG's converter) does not like negative ANGLE values at all!
</li>
</ul>
</td></tr></table>
</td>
</tr>
</table>


<ul>
<!--
<li>
<font color="darkgreen"><b>RiemannBuild10A.dae</b></font>:
<br />Here we check to make sure that  we can hold the red ellipsoid completely still at ANGLE = 4&deg; while the MidPlane Frame spins briskly clockwise.  We do this by literally typing in the floating-point value, 4.0, a dozen times to correlate with the twelve different specified increments of TIME.
<br />RESULT: &nbsp;<font color="red">Seems to work in both visualization venues.</font>  But (a bit later) we noticed that the extra "Black Cylindrical Pointer" is not exactly aligned with the Z<sub>0</sub> axis; it appears instead to be tipped a bit (perhaps, 4&deg;) and its direction appears to be changing over time.  This was also true in the above-discussed <font color="darkgreen"><b>RiemannBuild09D.dae</b></font> model.
</li>
-->
<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 <br />RiemannLagrange12L.dae</td></tr>
<tr><td align="center" bgcolor="lightgrey">[[File:RiemannLagrange12L.png|250px|Mac Preview of RiemannLagrange12L.dae]]</td></tr>
</table>
</td></tr></table>
<font color="darkgreen"><b>RiemannBuild10C.dae</b></font>:
<br />Hold the red ellipsoid completely still at ANGLE = 0&deg; while the MidPlane Frame spins briskly clockwise. In addition to typing in the floating-point value, 0.0, a dozen times to correlate with the twelve different specified increments of TIME, we also changed the initial value of "rotationZ" from "4.0" to "0.0" inside the "EntireEllipsoid" <node>.
<br />RESULT:  &nbsp;<font color="red">Seems to work in both visualization venues.</font>
</li>
<li>
<font color="darkgreen"><b>RiemannLagrange11B.dae</b></font>:
<br />Insert 51 small yellow (cube) "Markers" in the equatorial plane and on the surface of the red ellipsoid to identify the trajectory of a Lagrangian fluid element.
</li>
<li>
<font color="darkgreen"><b>RiemannLagrange12L.dae</b></font> (rotating frame):
<br />Include one solitary Lagrangian fluid element (red marker that is a bit larger than the previously inserted small yellow cubes), showing its "retrograde" motion in the equatorial plane and on the surface of the &#8212; now opaque, purple &#8212; ellipsoid (see Mac Preview image shown here, on the right).  In this model, the displayed time-dependent behavior &#8212; the spinning "MidPlane Frame" and the red Lagrangian fluid marker &#8212; is quantitatively correct for an S-Type Riemann ellipsoid that has the specific principal axis ratios &#8212; that is, b/a = 0.41 and c/a = 0.385 &#8212; of the displayed purple ellipsoid, and that is being viewed from a rotating frame of reference in which the ellipsoid is stationary.
<br /><font color="red">There is still a funny issure related to the "Zup Pointer".  Over time, it gains a bit of tilt.</font>
</li>
<li>
<font color="darkgreen"><b>RiemannLagrange12M.dae</b></font> (inertial frame):
<br />In an effort to diagnose/deal with the "Zup Pointer" issue (see RiemannLagrange12L.dae), this model attempts to move to the inertial frame of reference.  The Zup Pointer appears to remain stationary, and pointed precisely the desired direction.  <font color="red">This model</font> (or maybe it was model &hellip;14P) <font color="red">does not import properly into the Oculus Rift.  I can see the model, but Oculus outlines the scene in red, and displays red exclamation marks, to indicate that it does not like what the conversion routine has generated.</font>
</li>
<li>
<font color="darkgreen"><b>RiemannLagrange14Q.dae</b></font> (inertial frame):
<br />My guess is that the Oculus Rift (or the KG's conversion routine) has a problem dealing with the coordinate singularity along the Z-axis &#8212; that is, all longitudes lines reach the pole of the spherical coordinate system at the same (or at an undetermined value of the) azimuthal angle.  So, instead of using the geometric object [the "Cylindrical Pointer"] that was created to highlight the negative X-axis of the ellipsoid, here we are identifying the Z_0 axis by stretching the "Cube" geometric object into a "long" thin solid rectangle and placing it along the Z_0 axis.  <font color="red">This new "Zup Pointer" seems to work in both visualization venues.</font>
</li>
</ul>