User:Tohline/Appendix/Ramblings/OculusRift S

Success Importing Animated Scene into Oculus Rift S

In an accompanying discussion, we have illustrated how an animated, interactive 3D scene can be largely defined via the xml-formatted language named COLLADA. Here we explain what steps we followed as we attempted to figure out how to import such 3D scenes into the VR/AR environment offered by the Oculus Rift S.

Events from 1 April to 11 April 2020

Notes that Joel Recorded Over the Period 1 - 11 April 2020

01 April 2020 -- opened Lenovo box and began various setup steps -- established logins to ... lenovo.com microsoft (in connection with windows 10 operating system) McAfee Adobe Dropbox Already had accounts established at all of these; it was mostly a matter of finding the userid information and updating passwords. -- Adobe: Along with the Lenovo order, I paid for 1-year use of a large suite of Adobe tools. I was able to successfully send the relevant key code to Adobe, so it immediately allowed me to begin downloading various applications from this suite. I only downloaded two: (1) Creative Cloud; and (2) Photoshop. -- Dropbox: I successfully mounted Dropbox on the Lenovo/Windows10 system. EUREKA!! I was able to point Photoshop to a sample .dae file inside Dropbox. It opened the file immediately and noticed that it was a 3D scene. Then, with no complications, it opened the 3D scene. The colors/transparency values were darker than they had been on the Mac/Preview app, but otherwise no complaints! -------------------------------------------------------------------------------------------- 02 April 2020 -- From my Mac desktop, I established a "Lenova" folder in Dropbox and copied half-a-dozen already-developed .dae files into that folder. The plan is to pull from this set of files from the Lenovo side of things in order to more thoroughly test and get familiar with photoshop's handling of these files. -- Lenovo notified me that it needs to update the BIOS of my system. It recommended that I save the existing BIOS state before performing this update, so I have been poking around to see where Windows10 stores this BIOS information. "Setup will install Lenovo BIOS Update Utility into C:\BIOS\BVCN12WW ======================= https://store.hp.com/us/en/tech-takes/how-to-reset-bios-settings-on-windows-pcs ======================= https://windowsreport.com/flash-bios-windows-10/ For the line-command window, type "Command Prompt" or "cmd" or ... "Run" then "cmd". Also: Press "Windows Key + X" to open Win + X menu. Choose "Command Prompt (Admin)"; then, enter "wmic bios get smbiosbiosversion" and press "enter"; ANSWER on Lenovo: SMBIOSBIOSVersion BVCN11WW(V1.07) ---------------------------- or, enter "systeminfo" and press "enter"; ANSWER on Lenovo: Host Name: LAPTOP-36EUPT5N OS Name: Microsoft Windows 10 Home OS Version: 10.0.18362 N/A Build 18362 OS Manufacturer: Microsoft Corporation OS Configuration: Standalone Workstation OS Build Type: Multiprocessor Free Registered Owner: joeltohline@gmail.com Registered Organization: N/A Product ID: 00325-81656-19754-AAOEM Original Install Date: 4/2/2020, 6:49:57 AM System Boot Time: 4/1/2020, 6:23:16 PM System Manufacturer: LENOVO System Model: 81UF System Type: x64-based PC Processor(s): 1 Processor(s) Installed. [01]: Intel64 Family 6 Model 158 Stepping 10 GenuineIntel ~2592 Mhz BIOS Version: LENOVO BVCN11WW(V1.07), 7/4/2019 [Joel successfully updated to V1.08 on 4/2/2020] [Joel successfully updated Firmware as well on 4/2/2020] Windows Directory: C:\Windows System Directory: C:\Windows\system32 Boot Device: \Device\HarddiskVolume1 System Locale: en-us;English (United States) Input Locale: en-us;English (United States) Time Zone: (UTC-06:00) Central Time (US & Canada) Total Physical Memory: 16,303 MB Available Physical Memory: 8,965 MB Virtual Memory: Max Size: 19,247 MB Virtual Memory: Available: 9,861 MB Virtual Memory: In Use: 9,386 MB Page File Location(s): C:\pagefile.sys Domain: WORKGROUP Logon Server: \\LAPTOP-36EUPT5N Hotfix(s): 6 Hotfix(s) Installed. [01]: KB4537572 [02]: KB4497727 [03]: KB4506933 [04]: KB4537759 [05]: KB4541338 [06]: KB4551762 Network Card(s): 3 NIC(s) Installed. [01]: Killer(R) Wireless-AC 1550i Wireless Network Adapter (9560NGW) 160MHz Connection Name: Wi-Fi DHCP Enabled: Yes DHCP Server: 192.168.0.1 IP address(es) [01]: 192.168.0.37 [02]: fe80::1907:dc1e:d957:9d70 [03]: 2600:8807:100:40:915e:ec3f:bf47:822e [04]: 2600:8807:100:40:1907:dc1e:d957:9d70 [02]: Realtek PCIe GbE Family Controller Connection Name: Ethernet Status: Media disconnected [03]: Bluetooth Device (Personal Area Network) Connection Name: Bluetooth Network Connection Status: Media disconnected Hyper-V Requirements: VM Monitor Mode Extensions: Yes Virtualization Enabled In Firmware: Yes Second Level Address Translation: Yes Data Execution Prevention Available: Yes ======================================= Also successfully plugged "gaming mouse" into Lenovo laptop. -------------------------------------------------------------------------------------------- 03 April 2020 -- Intalling Adobe "Dimension" in order to see if it can read .dae files. Evidently it cannot read .dae files. -- Noticed that a "3D Viewer" app now exists in the Windows 10 startup menu. But, on the Lenovo, it does not recognize .dae files. ========= -- Successfully installed Oculus Rift ocul.us/riftsupport Installed software should be located in ... C:\Program Files\Oculus\ Default download location for Oculus Store app purchases ... C:\Program Files\Oculus\Software Headset hardware ... -- Plugged in (1) Mini DisplayPort connector; and (2) USB -- Updated firmware on goggles -- Inserted batteries into handsets -- Update Firmware on handsets (controllers) Oculus/Devices/Rift S ==> -- Serial Number: (see notes) -- Firmware Version: 2.2.0 -- Successfully completed Oculus Rift S Tutorial; it is "Wally" robot game that Quang (Kevin's work colleague) introduced me to over a year ago. -- Also downloaded and installed "Oculus Medium"; evidently this was part of my originally purchased Rift S package, because the button said "purchased". -- Used Photoshop to store 3D "hologram" file in glb format ... Then figured out where to import the file into the Rift S model store ... I needed to store the file in ... PC\Documents\Oculus Home\_Import\ExampleUGC I noticed that two model files (placed there by the Oculus team) already existed in this folder and I was able to find both models under "Imported Models" on the Oculus Rift side. This was very useful as a starting point for understanding what I was **supposed** to be able to do. Oculus Rift S actually found my "hologram" file (and a separate "Cube" that I loaded), but it was unable to execute the file and therefore I could not place these objects into my "Home" scene. It was nevertheless encouraging that the Oculus "app" actually found both files. -- https://www.oreilly.com/library/view/photoshop-cc-the/9781491905593/ch21s06.html "Photoshop CC: The Missing Manual, 2nd Edition by Lesa Snider" (1) Choose 3D --> Export 3D Layer (2) Choose one of these file formats: Collada DAE, Flash 3D, Google Earth 4KMZ, STL, or OBJ. -------------------------------------------------------------------------------------------- 04 April 2020 -- It appears as though I should disconnect the Oculus Rift S system from the Lenovo PC before I put the PC to sleep (e.g, before I close the laptop). Then, when reattaching the Rift's pair of cords, I should plug in the USB connection and wait about 5 seconds before attaching the "video monitor" cord. You can see connection confirmations within the Oculus app ... go to the "DEVICES" menu item. EUREKA!! Under the Windows app/start menu, I found a "Paint 3D" app. -- I started the app; I clicked on the "3D Shapes" menu choice; then I "drew" a simple light-purple cube (default color). I spun it around to a viewing position where multiple surfaces were visible. -- I clicked "Menu" (upper-left corner of app window) then chose "save as ... 3D model"; this saved as a ".glb" formatted file only 3K big. -- I then copied this file into the "Oculus Home\_Import\ExampleUGC" folder. -- I climbed back into the Oculus Rift S AR room and was able to see/grab this newly created 3D model. YEAH!!! CAUTION: I tried to repeat the "EUREKA!!" moment, this time drawing a yellow torus. But, for some reason, when I enter the AR environment, even though the purple "CubeFirst" object is still available, it does not offer the torus to me. I notice that it also does not recognize the (BAD) photoshopped object. OK!! The "Import" window worked again after I did two things: (1) Closed the Oculus app, then reopened it; (2) Took the detailed file-name specification (.glb) off of windows folder/file system. Not sure which was the culprit ... probably #1. EUREKA!!! Successfully coverted Try06.GREAT.dae to "glb"-formatted file named Try06.glb -- Well .... actually, this was only partially successful, but the successful aspect was TERRIFIC! -- Instead of asking Photoshop to do the dae --> glb conversion, I used an online web-based conversion tool. It is a "glTF Converter" presented by "BlackThread.io". After performing the conversion, this "tool" gave me a couple of warning messages... (1) Animation transform type "rotate" not yet implemented; (2) Use MeshStandardMaterial or MeshBasicMaterial for best results -- Despite the warnings, I decided to move the "glb" file into the Lenovo directory that is used for Oculus model importing. I then activated the Rift S headgear (about 10:15 pm CDT) and, sure enough, it showed my COLLADA-created model in the inventory window!!!! I was able to grab this model and drop it into my "Home" AR scene. Once I grabbed the model, Oculus posted a warning that suggested I pay attention to and correct errors that were encountered during the step of dae --> glb conversion; it also put a dashed-red box around my model with a red circle/exclamation mark. So ... something needs to be fixed, but at least I proved that the entire process of placing COLLADA-based models into the AR environment ultimately should work out. GREAT!!! -------------------------------------------------------------------------------------------- 05 April 2020 CONTINUED SUCCESS: -- This morning I went to my Mac Pro and opened up the "Try06.GREAT.dae" file inside the Preview app in order to prove that I was handling the appropriate .dae file. Then I edited the file, deleting only the "library_animations" section of the XML-based COLLADA code; I looked at the file in Preview to acknowledge that the edits did not harm the code. I stored the edited file -- now, named "Try06C.dae" -- in a new Dropbox folder named, Dropbox\Lenovo\BlackThread. Still on my Mac Pro, I next got into Safari and located the BlackThread.io website. I found the "glTF Converter" app by clicking on the (additional menu) icon in the upper-right-hand corner of the site's home page. I dragged-and-dropped the "Try06C.dae" file onto the "Upload or Drop Files Here" button; the file was automatically converted into a "glb-formatted" file. As before, a few lines of Warning messages appeared, but this time they **did not** include an animation transform warning; they were only MeshMaterial warnings. I downloaded the file by clicking on the "Export as GLB (21kb)" button; I then moved the "Try06C.glb" file into the Dropbox\Lenovo\BlackThread folder. -- Then I moved to my Lenovo laptop, opened up the relevant Dropbox folder, made a copy of "Try06C.glb" file, then pasted the file into the "Oculus Home\_Import\ExampleUGC" folder. I put on the Rift S goggles and, sure enough, I was able to "grab" and play with the new object from the Oculus imported inventory page. YES!!!! While playing with the new object, I figured out what handset buttons needed to be clicked/held in order to "scale" (e.g., shrink or expand) the object. This, of course, worked on other objects as well. NOTE: I learned from this that the COLLADA file can contain instructions that rotate as well as scale and translate each item in a scene but, apparently, if the file contains any animation instructions, the BlackThread converter will complain. ADDITIONS: -- Made model "Try08" available as imported inventory; it is basically the same as Try06, except the larger, tilted cube is colored red while all other smaller cubes are purple. Oculus was able to load this ".glb" file without complaint. -- Cut all animations out of "TL15.lagrange.dae" and got rid of planes that slice the Type 1 ellipsoid into various octants (these were not previously active anyway). Then used BlackThread.io to convert it into a .glb file; it had no complaints, aside from the same "BasicMaterials" issues already encountered. When I "grabbed" this object in the Rift S environment, it warned me that there was an error in the translation to glTF (.glb) -- [it also put a dashed-red box around my model with a red circle/exclamation mark] -- but it nevertheless loaded the basic elements of the Type 1 ellipsoid **and** the clock on the wall. The parameter labels were not complete/readable (also true of the image shown after the BlackThread.io conversion) but this is a relatively minor issue, for now. INTERESTINGLY ... in Oculus, the purple ellipsoid was hugh!! After grabbing it, I was able to manually shrink its overall scale. Thereafter, is was fun to move around, rotate, and examine the generated 3D structures -- even though the complaining red circle/exclamation mark was always in tow. -------------------------------------------------------------------------------------------- 06 April 2020 This morning I went back to my Mac Pro to simplify even further the TL15.lagrange.dae file. I kept the purple ellipsoid, its spin axis, the grey "equatorial plane" frame, and the clock-on-the-wall. But I deleted all the parameter specifications and all of the yellow boxes that outlined 2 of the 3 lagrange-particle orbits. I kept the yellow cube markers for **one** of the orbits. I named this file, "TL15lagrangeC.dae". Then I "dropped" this file into the BlackThread.io glTF converter and it created the converted file named, "TL15lagrangeC.glb". On the Lenovo PC, I put a copy of this new ".glb" file into the Oculus "ExampleUGC" folder, then I dawned the headset and was able to grab this new inventory item. Oculus complained in the same way as yesterday evening; in particular, the purple ellipsoid was hugh! But, again, I was able to manually shrink the entire object field to a manageable size and add it to the set of objects in my Home AR environment. ================ On the Mac Pro, I edited the "TL15" file again. This time I simply added one new, all-encompassing "node" to the visual_scene and assigned an overall scaling of 0.05 (in all 3 dimensions) to this node. I named the file, "TL15lagrangeD.dae"; used the glTF converter to create the ".glb" equivalent file; and, on the Lenova PC, put a copy of the file into the Oculus "ExampleUGC" folder. When I dawned the headset and "grabbed" this new file from the inventory shelf, it was indeed a much more manageable size. Of course, the Oculus still complained about improper coding in the .glb file. ================ I have discovered that a unique "id" must be assigned to each "node" in a visual_scene. This is why the yellow orbit markers were not showing up in the conversion from .dae to .glb (glTF). This change was made, and now the model named "TL15lagrangeF" properly displays all of the "yellow cube" markers for one lagrangian particle orbit in the Type 1 Riemann ellipsoid. Hurray! This edit did not fix everything, however, as Oculus still complains that there is something wrong with the .glb file. I'll keep looking ... ================= Worked for a while, editing COLLADA file and converting it to .glb (using BlackThread and/or PhotoShop) in order to try to figure out what Oculus doesn't like. Finally, I stripped the .dae model down to just the purple ellipsoid and I was able to import it into Oculus without complaint. The name of this file is... TL15lagrangeIshort.dae (and .glb). I guess, now, I am going to step backwards and see when the glitch appears (or, really, no longer appears). -------------------------------------------------------------------------------------------- 07 April 2020 Starting from TL15lagrangeIshort.dae, I tried adding the yellow Lagrangian markers back into the (otherwise only) purple ellipsoid scene. This was not successful, as even the Mac Pro's Preview app crashed, time after time. TL15Kshort.dae (and .glb) -- So ... I instead tried to add just the "equatorial plane" picture frame. This **did** work. I successfully imported the "TL15Kshort.glb" model into the Oculus Rift S home! For the first time, while I was wearing the Rift S headset and standing in my VR/AR home room, I took one color photo that shows how I had placed a variety of my homemade objects in the room; I then turned the camera around and took my first selfie. Fun!! By default Oculus stores these camera shots in ... This PC\Documents\Oculus Home\Camera In order to delete an imported object, try the following (using Google, I retrieved this advice from forums.oculusvr.com/Home/Community/Oculus Medium ... (1) Make sure the particular model is not placed in one of my worlds; (2) In the inventory, bring up the Details menu by pressing B; (3) Click the button that says "Remove Upload" TL15Mshort.dae (and .glb) -- In this model I have added the green spin axis ... in addition to the purple ellipsoid, and the grey midplane frame. Rift S has a problem loading this model. So, something changed when I simply added the green spin axis. TL15Nshort.dae (and .glb) -- Added one, and only one, yellow (cube) marker. Rift S has a problem loading this model, but it may be the spin axis and **not** the marker. Who knows? What's wrong with .glb files in Oculus? -- One thought is that Oculus does not like for two separate pieces of a scene to intersect each other. This will happen when the spin axis is added (as in TL15Mshort.dae) **and** it will happen when a lagrangian marker is added (as in TL15Nshort.dae) to the scene. As a test, I went back to TL15Mshort, in which the green spin axis had been added, and I adjusted the position + length of the axis so that it no longer insects the purple ellipsoid. The new output file was named "TL15M2short.dae" (and .glb). This did not fix the problem; hence my "thought" cannot be the problem. -------------------------------------------------------------------------------------------- 08 April 2020 RESCALING PROPERLY ... Tried rescaling object by setting meter="0.0254" up front, and simultaneously deleting earlier (successful) step of inserting an overarching "ZERO" node in the final scene. Doing this in a file named, "[New]TL15K2short.dae (and .glb)". This worked! In the future I should set all scenes up in such a way that the overall scaling is done by establishing this early definition to "meter". ADDITIONAL DIAGNOSTICS ... Went back to TL15Mshort and tried the following: -- implement proper rescaling, as described above, but leave in SpinAxis; --> TL15M3short -- also get rid of "level ONE" nodes in visual_scene (since they are really only needed when implementing animation) and leave in Spin Axis; --> TL15M4short -- comment out Spin Axis. --> TL15M5short Result is that Oculus Rift S is only happy with the last (TL15M5short) model. This tells me that proper rescaling + getting rid of "level ONE" nodes is okay, but there is still something wrong with the SpinAxis. What the heck is it??? FOUND A HINT ... I kept the various pieces of "SpinAxis" alive, but inside the <visual_scenes> step, I told the SpinAxis instance to refer to the "Equatorial Plane" geometry instead of the "Cylinder" geometry. (I also changed the scaling of the "SpinAxis" scene so that it would look more like a frame than a stick.) This file is TL15M7short.dae (and .glb). This worked inside the Oculus Rift S system!!! Yeah! This tells me that there is a funny bug inside of the "geometry" specification of the Cylinder. For a while this evening I have tried to find a bug in the geometry specification of the Cylinder, but have not found any. Hmmmmm. Tomorrow, focus on the "Markers" scene and, in particular, avoid using the <matrix> notation. -------------------------------------------------------------------------------------------- 09 April 2020 WORKING MARKER -- I started the day by making a clone of TL15M7short.dae --> TL15P1.dae. I then added all of the components that were necessary to draw one yellow Lagrangian marker. I placed only a single marker into the visual_scene; following the decisions that were made months ago, when I was originally detailing the orbits of Lagrangian particles in Type I Riemann ellipsoids, it was necessary to insert this Marker node in such a way that it was a sub-node of the primary, "ellipsoid02" node. -- Then I cloned TL15P1.dae --> TL15P2.dae. All I changed, here, was to replace the <matrix> command with an explicit specification of <scale> and <translate>. -- I used BlackThread to create .glb versions of both TL15P1 and TL15P2, then imported both objects into the Oculus Rift S. Surprisingly (pleasantly), **both** objects were loaded without complaints. So ... (1) By re-introducing all of the Markers components into the overall COLLADA code, I somehow cleared up the problem that I was previously having with this model; and (2) I have demonstrated that it is okay to continue specifying scale/translate instructions via the more compact, <matrix> command. ALL 30 MARKERS ... -- In a new file named "TL15P1many.dae" I inserted an additional 29 markers to define orbit #a. Based on the result, immediately above, I have kept all <matrix> instructions in place. IT WORKS !!!! ALL THREE ORBITS -- Now I have successfully set up Lagrangian fluid markers on three separate orbits, each with 28 - 30 markers. I have imported this "scene" into my Oculus Home without any errors/complaints. The file is TL15P3many.dae (and .glb). <lines> ... I spent some time today trying to figure out what is wrong with the "SpinAxis" instance, which relies on my own designed "Cylinder" geometry. Never could find an obvious mistake. Then, in reading back through some pages of the hardcover book on COLLADA (2006 by Arnaud & Barnes) that I purchased several months ago, I noticed that in addition to <triangle> and <polygon> structures, COLLADA also defines a <lines> command. From the sketchy example in the book, I was unable to figure out how to insert this command into my model. Fortunately, Google pointed me to a github site where I could see a more complete example of a <lines> command. Following this example, I was able to successfully use the <lines> command to insert a (very thin) z-axis into my TL15 model; the model file is "TL15P3line.dae". Confirmation of success came via the Mac's Preview app. Tomorrow I will load this file into the Oculus Rift S to make sure that it works there as well. COLLADA2gltf ... KhronosGroup I tried, in vein, to figure out how I might **thicken** the line that is drawn by COLLADA's <lines> command. (Evidently there is no option for line thickness.) But while looking at online COLLADA documentation, I was reminded that the COLLADA design group -- the Khronos Group -- supplies a tool to convert from COLLADA's xml-based file format to the glTF format. It is called "COLLADA2gltf". Tomorrow I will see whether this application works as well as the BlackThread glTF Converter. COLLADA2GLTF-bin evidently generates a .glb file, which I would prefer. -------------------------------------------------------------------------------------------- 10 April 2020 COLLADA2gltf ... KhronosGroup https://github.com/KhronosGroup/COLLADA2GLTF/blob/master/README.md I downloaded and installed the Mac version of this converter app on my Mac Pro. I stored the executable, etc. under ...\Dropbox\Lenova\COLLADA_to_gltf\COLLADA2GLTF-v2 From the BlackThread folder, I copied "Tl15P3many.dae" into the same folder where the executable has been stored. I then typed ... ./COLLADA2GLTF-bin -i Tl15P3many.dae The excution happened without complaint, and it put the resulting file under ... output/Tl15P3many.gltf I then made a clone of the .dae file, naming it "TL15P3test01.dae", and typed ... ./COLLADA2GLTF-bin -i TL15P3test01.dae -b The execution happened without complaint, and it put the resulting file under ... output/TL15P3test01.glb So I **should** have a functioning .glb file that I can import into the Oculus Rift S. NEW OCULUS RESULT: I put two new .glb models into the Oculus import/example folder... (1) As explained immediately above, I used COLLADA2GLTF-bin to create TL15P3test01.glb (no <lines> instruction). (2) I used BlackThread to create TL15P3line.glb (includes <lines> instruction; The file with <lines> command completely bombed in Oculus! On the inventory shelf, the relevant cube was red through-and-through **and** it displayed the warning exclamation mark (!). ******************* Poking around thru Google, it appears as though the <lines> command is ignored (not activated) in various COLLADA display tools, such as Blender (for efficency reasons) and PhotoShop. ******************* But the "...test01.glb" trial was a success! Without any complaints, Oculus imported/loaded the model perfectly. Hence, while the <lines> command seems not to be working (except on the Mac), the first test of COLLADA2GLTF-bin was a success!! Yeah!!!! -------------------------------------------------------------------------------------------- 11 April 2020 TRANSPARENCY: I stumbled on a web site that shows a variety of (lighting) effects that can be specified in COLLADA. It involves a <phong> rather than <lambert> specification; and in addition to <diffuse> lighting -- which I have been using almost exclusively and which **appears** to let you specify 4 color values (RBGA) but which seems to work only in the Mac Preview app -- it shows how to specify a <transparency> value with a single floating-point value (alpha). This <phong><transparency> setting appears to work in (1) the Mac Preview app; (2) the BlackThread glTF (glb) converter; and (3) the Oculus Rift S. The relevant test file carries the name "Try04_alpha.dae" (and .glb). HOORAY!!! I also tried adding this transparency specification to the file named Cube/Simplest/ Try06.GREAT.dae. This is a relatively simple example of ANIMATION. The BlackThread converstion to .glb seemed to work without complaint, but I was unable to import the model into the Oculus Rift S. (On the import "shelf", I was able to see that the transparency level had been incorporated properly, but the "red warning box" appeared when I tried to grab the object off of the shelf.) I blame this on the attempt to load a file containing animation, rather than blaming it on transparency. Next, let's convert these same two files to .glb using the KhronosGroup (KG) conversion routine. Will the animation work by taking this route to the Oculus Rift S? FANTASTIC !!!!! Using the KG's COLLADA2GLTF, the animation actually works perfectly!! --------------------------------------------------------------------------------------------

See Also

• Tohline, J. E., (2008) Computing in Science & Engineering, vol. 10, no. 4, pp. 84-85 — Where is My Digital Holographic Display? [ PDF ]

© 2014 - 2021 by Joel E. Tohline |   H_Book Home   |   YouTube   | Appendices: | Equations | Variables | References | Ramblings | Images | myphys.lsu | ADS | Recommended citation:   Tohline, Joel E. (2021), The Structure, Stability, & Dynamics of Self-Gravitating Fluids, a (MediaWiki-based) Vistrails.org publication, https://www.vistrails.org/index.php/User:Tohline/citation