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 "WALL*E" 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 donned 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 donned 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!!