Introduction

Today, we begin by seeing how we can do simple debugging of our WebVR apps using an Oculus Go.
To do this, we first want to set up our Oculus Go so that it is convenient to do development on.
One basic convenience is to be able to manipulate the file system on the Oculus Go.
On a PC, if you connect an Oculus Go via a USB cable it should appear as a USB device and you can look at its file system.
On a Mac, you should get the Android File Transfer App.

Setting Up Developer Mode on the Oculus Go

Another thing we want to do to make debugging go smoothly is to enable developer mode on our Oculus Go.
This will also will be needed to create and install native apps later.
Enabling developer mode can be done from the phone associated with your Oculus Go, by opening the Oculus App and going to Settings.
Click on a paired Oculus Go to see the setting for that device.
Then click on More Settings > Developer Mode, turn the switch you see to On.
Below is a sequence of screen shots showing the process:

Android Device Bridge

The Oculus Go is essentially an Android device, so to debug it we will make use of the Android Device Bridge (adb) command line tool.
We can install this by installing Android Studio, an IDE for Android development.
If you prefer to do things from the command line, and just want the command line tools for Android development, you can scroll down on the same page till you see the links for command line tools.
Another way to install the command line tools is to use apt, brew, or choco. For example, on my Mac I did:
```
brew cask install android-platform-tools
```
After installing the tools, and maybe playing with your path variables, you should be able to launch a terminal, CMD shell, or Power Shell and type:
```
adb devices
```
and see a list of connected Android devices.
If you have your Oculus Go connected via USB to your computer, you might see something like the following as the output for this command:
```
List of devices attached
1KWPH810RN8115	device
```

Logcat

You can use the Android Device Bridge to get a log of recent activity on your Oculus Go by typing:
```
adb logcat
```

This might output to your terminal a bunch of lines like:

...
03-06 09:41:59.956  1322  1765 I ovrsensors: Setting sensor 2 sampling rate to 0.00, 
  batch size=0
03-06 09:41:59.956  1322  1351 I GattConnection: onDisconnect - closing gatt
03-06 09:41:59.956  1322  1351 D BluetoothGatt: close()
03-06 09:41:59.956  1322  1351 D BluetoothGatt: unregisterApp() - mClientIf=5
03-06 09:41:59.956  1074  1109 D BtGatt.GattService: unregisterClient() - clientIf=5
...

The default browser in the Oculus Go is Chromium based. To see only messages from the browser, we can type:
```
adb logcat -s chromium
```

console.log messages such as the one from last day's code when we started VR Presenting will appear in this stream of log messages:

03-06 09:46:52.175  4379  4379 I chromium: [INFO:CONSOLE(129)] "hi there!! presenting",
  source: https://www.cs.sjsu.edu/faculty/pollett/185c.1.19s/WebVR.html (129)

Connecting to Oculus Over Wifi using adb

Sometimes it is convenient to be able to use the device bridge with the Oculus Go over Wi-Fi rather than via a USB cable.
To do this we first need to find the Wi-Fi address of our device. We can find this while connected via USB with the command:
```
adb shell ip route

10.1.10.0/24 dev wlan0  proto kernel  scope link  src 10.1.10.37
```
Still connected with USB, we can tell our Oculus Go to enable Wi-Fi debugging at the TCP/IP port of our choice:
```
adb tcpip 5555
```
We can now disconnect the USB cable from our device, and connect from our computer to this Oculus Go using:
```
adb connect 10.1.10.37
```

Screencasting

One thing that works for me better using Wi-Fi rather than USB cable, is screen casting to my laptop.
You can easily screencast to the phone paired with your Go by going to the Oculus Go app on your phone, then Settings and clicking on the Screencast Icon:
To screencast using adb you need to have an app that can receive and display video streams on your computer.
One app that works on Mac, Linux, Windows is VLC.
You can install this using brew, apt, or choco, depending on the kind of computer you have with a command like:
```
brew cask install vlc
```
Assuming you have both adb and vlc in your path variable and assuming you are already connected to your Oculus Go via Wi-fi, you can then type:
```
adb exec-out "while true; do screenrecord --bit-rate=2m --output-format=h264 
   --time-limit 180 -; done" | vlc --demux h264 --h264-fps=60 --clock-jitter=0 -
```
to do a screencast (above should all be on one line).

In-Class Exercise

Imagine you knew how to write object-oriented Javascript.
You make one object VRExperience to represent your VR experience.
It has a method drawScene (much like our method for cube drawing), which draws all the VRObject's in the scene.
Suggest three methods that might be useful for VRObject to have in order to facilitate drawScene.
Post your solutions to the March 6 In-Class Exercise Thread.

OO Javascript

I'd next like to introduce how to write object-oriented Javascript.
There are two ways to do this, the traditional way, and the Ecmascript 2015 way.
The latter way is syntactic sugar that the browser under the hood can be thought to rewrite to the former.
I will first talk about the traditional way then briefly mention the modern way.
The traditional way is based on using the fact that Javascript can be made to treat functions as objects.

Javascript onstructors are special methods that create and initialize the properties for newly created objects. For example,

function car(new_make, new_model, new_year)
{
   this.make = new_make;
   this.model = new_model;
   this.year = new_year;
}

I could then create an object with

my_car = new car("Ford", "Contour SVT", "2000");

Methods

To create methods, I can do things like the following way to create a display method to pretty print cars:

function display_car()
{
    document.write("Make:", this.make, "<br />");
    document.write("Model:", this.model, "<br />");
    document.write("Year:", this.year, "<br />");
}
function car(new_make, new_model, new_year)
{ 
    //same as before
    this.display = display_car;
}
my_car = new car("Ford", "Contour SVT", "2000");
my_car.display();

this always refers to the enclosing object. If you haven't defined any objects yet this will usually end up being the window object.
Notice we wrote this.display = display_car not this.display = new display_car. When we do my_car = new car("Ford", "Contour SVT", "2000"); the enclosing object for this.display and the occurrences of this within display_car as used within car will be my_car.
The drawback of the above code is that each time we create a new car we have a separate pointer to display_car. Instead, we can use the prototype property of the car function. This will only create one pointer.
```
function car(new_make, new_model, new_year)
{ 
    //same as before
}
car.prototype.display = display_car;
```

If we want to define the methods in the function body, we can also write:

function car(new_make, new_model, new_year)
{ 
    //same as before
    car.prototype.display = function()
    {
        document.write("Make:", this.make, "<br />");
        document.write("Model:", this.model, "<br />");
        document.write("Year:", this.year, "<br />");
    }
}

More on the Prototype Property

When Javascript looks up a property of an object, it:
- Looks up property in the instance,
- If it is not found then it looks in the prototype object of the given function object,
- Since prototype is an Object, it too has a prototype subobject. So it looks at the prototype property of this subobject to see if the property is set there.

We can use the prototype property to achieve something like inheritance:

function A() {
}
A.prototype.foo = function() {
   alert("foo");
}
function B() {
}
B.prototype = new A();
/*
  we just made B's prototype an instance of an A function object 
  which has its own prototype. So property look up for B,
  looks within its instance, then within it prototype,
  which is an instance of A, to see if it is a property of A,
  then it looks at A's prototype to see if the property is there.
  As A's prototype is an Object, it finally looks at Object's
  prototype to see if the property is there.
*/ 
B.prototype.goo = function() {
   alert("goo");
}
a = new A();
a.foo(); // alert with foo in it
b = new B();
b.foo(); // alert with foo in it
b.goo(); // alert with goo in it
a.goo(); // type error goo is not a function of A

The Module Pattern

In PHP, Java, etc, we can declare the visibility of a variable: We can make them public or private.
In Javascript, we can fake this by using parent function objects as a scope in which to declare variables that are used in an inner function declaration.
The parent function objects are sometimes called a closure.
If the parent function object is anonymous and immediately called, it is called an immediately invoked function expression (IIFE, pronounced "iffy").

The general format of how to fake private variables using IIFE's is called the module pattern:

var object_we_are_making = (function () {
    // private variables
    return {
       // public data and methods
    }
}());

Here is an example of using this pattern:

var employee = (function() {
    var salary = 20000; 
    return {
        name: "John Smith",
        getSalary : function () {
            return salary;
        },
        setSalary : function (sal) {
            salary = sal;
        }
    }
}());
alert(employee.name); // John Smith
alert(employee.getSalary()); // 20000
employee.setSalary(100000);
alert(employee.getSalary()); // 100000
alert(employee.salary); // undefined

More Faking Visibility

The example of the last slide let's us create single objects with private variables.

If we want to create something like a class with private variables, we can use an idiom like:

function Employee(name, sal) {
    var salary; // scope within constructor
    this.name = name;
    salary = sal;
    this.getSalary = function () {
        return salary;
    }
    this.setSalary = function (sal) {
        salary = sal;
    }
}
var emp1 = new Employee("John", 100000);
var emp2 = new Employee("Sally", 150000);
alert(emp1.name); // John
alert(emp2.name); // Sally
alert(emp1.getSalary()); // 100000
emp2.setSalary(200000);
alert(emp2.getSalary()); // 200000
alert(emp1.getSalary()); // 100000
alert(emp1.salary); // undefined

OO in Ecmascript 2015

Ecmascript 2015 introduced the ability to define classes:

class MyClass
{
    contructor(arg1, arg2,...)
    {
       // code
       this.foo = arg1; //an example of setting a field
    }
    //getter methods...
    get myGetterFunction(arg1, ...)
    {
       // code
    }
    // a bunch or instance methods...
    myMethod1(arg1, ...)
    {
       // code
    }
    // a bunch or static methods...
    static myStaticMethod1(arg1, ...)
    {
       // code
    }
}

There are some minor difference with respect to definition hoisting between the traditional way (which supports it, and the new way doesn't) to define classes and the new way.
The code inside a class definition must satisfy Javascript strict mode; whereas, the traditional way does not have to.

To get one class to inherit another one can use the extends keyword much like Java:

class B extends A
{
   //code
   //can refer to parent in child using super keyword. I.e., super.foo()
}

Private versus public variables are still experimental using class definition and have not been standardized yet.

Modules in Ecmascript 2015

In Ecmascript 2015, you can put functions, classes, etc into a file and put the export keyword in front of some of them:

//my_module.js
function hideme() {
   return "from hideme";
}
export function showme() {
   return showme();
}
export class goo
{
}
//another syntax for this is
function foo1()
{
}
function foo2()
{
}
export {foo1, foo2}

You can load such a module using the syntax:

<script type="module" src="my_module.js" >

You can also declare modules inline within your html code:
```
<script type="module">
// some code
</script>
```
One speed-up of modules is that if you accidentally import a module twice, your browser will only process it once. So
```
<script type="module" src="my_module.js" >
<script type="module" src="my_module.js" >
```
would have the same effect as just a single copy of the above line.
Modules must be written as if a "use strict"; declaration had been made. This means, that in a module you must declare variables before using them, function arguments names can't be repeated twice, you can't use the older Javascript with blocks, etc. For example, you would need to write
```
var x = 3.14; // if this was the first occurence of x
```
rather than the more lazy
```
x = 3.14;
```

Modules are allowed to import functions, etc. from other modules without having to import everything:

//my_second_module.js
import {showme} from "./my_module.js";
// I can now call showme()
import "some_other_module.js" //executes module only for side-effects
import * as ModuleName from "./module_name.js" //import everything with a name
/* if module_name.js exports foo(), 
   I could then use this function as ModuleName.foo();
*/

Making our Web VR Code More Object Oriented

To make our Web VR code more object oriented, we can have a kind of object called VRExperience:

function VRExperience()
{
    this.vr_objects = [];
    this.then = 0;
    this.gl = null
    //... other initializations    
}
VRExperience.prototype.init = function ()
{
    /*
      set up this.gl
      create all VR Objects use for scene add to this.vr_objects
      for each this.vr_objects element i 
      this.vr_objects[i].init(this.gl)
     */
}
VRExperience.prototype.start = function ()
{
    //used to start drawing scene
    window.requestAnimationFrame(this.render);
}
VRExperience.prototype.render = function (delta_time)
{
    var now *= 0.001;  // convert to seconds
    var delta_time = now - this.then;
    this.then = now;
    this.draw(delta_time);
    requestAnimationFrame(this.render);
}
VRExperience.prototype.update = function (delta_time)
{
    /* code to update positions of all vr_objects using delta_time
       can have code which is a for loop over vr_objects array.
       and for each element in the array call its update(delta_time)
     */
}
VRExperience.prototype.draw = function (delta_time)
{
    /* for each eye for each element i in vr_objects 
       this.vr_objects[i].draw(this.gl, current_view_matrix,
          current_projection_matrix_for_eye)
     */
}

I wrote the above with the old style way of using classes, but you could easily rewrite using a more modern syntax.
VRObject's init method can then be used to set up any shaders or buffers that need to be set up for that object. It might also set up any initial model matrix.
In addition to update, and draw methods, VRObject might also have methods to change the position (moveTo) or scale of the object.

Light and Optics

To make a realistic VR scene, we need to understand how to make light emitted from VR displays arrive at our eyes in a way that convincingly reproduces the way light naturally arrives through normal vision of the physical world.
In a VR system, engineered and natural lenses guide the light.
In VR world, we also often have light sources, so we need to understand how the physics of how light from these sources propagates around the world.
In the VR setting, the understanding of light is also helpful to understand how cameras work. We can use this understanding to effect how we present the virtual world.

Basic Behavior of Light

Light can be described in three ways:
1. Photons: Tiny particles of energy moving through space. This view is helpful when considering the amount of light received by a receptor.
2. Waves: Ripples through space similar to waves on the water, but in 3D. The wavelength is the distance between peaks in such a wave. This view is useful when considering the spectrum of colors.
3. Rays: A ray traces the motion of a single hypothetical photon. The direction is perpendicular to the wavefronts. This view is useful when trying to understand visibility.

Spreading Waves

The previous slide's picture shows how waves would propagate from a point light source.
The density would be the same in all directions, but would decrease as the light source becomes more distant according to the surface area of the sphere at a given distance. i.e., `4 pi r^2`.
So the total number of photons hitting a screen of radius 1 would be the same as for a screen of radius 2, but the photons/unit area would fall by a 1/4.
The curvature of the wavefronts also decreases with distance.
For distant objects, one essentially has parallel wavefronts.
For a non-far away light source, the rays of light from that source will always appear to diverge, and it is impossible to make them converge without lenses.

Interactions with Materials

Once light hits a material, it can either be: reflected back from the material, transmitted through the material, or absorbed by the material.
For a transparent material, the transmitted light rays are slowed down and bent according to Snell's Law:
`(sin theta_{o\ut})/(sin theta_{i\n}) = v_{o\ut}/v_{i\n} = n_{i\n}/n_{o\ut}`
where the `theta`'s are the angles with respect to the normal to the surface, `v`'s are the velocities of light in the different media, and `n`'s are indexes of refraction.
For a perfectly polished surface, the rays reflect in the same way: the exit angle is equal to the entry angle. This kind of reflection is called a specular reflection.
For a rough surface, the rays reflect in many different directions. This kind of reflection is called a diffuse reflection.
Usually, all the processes above, specular reflection, diffuse reflection, absorption, and transmission, all occur, but to varying degrees.
When dealing with lenses, one can often have addition effects going on which may be simulated, such as lens aberrations.
We will say more about light and optics next week.

WebVR Debugging - OO Javascript -- Light

Outline