mtwoodard / hypvr-ray Goto Github PK

Currently we have a hacky system that calculates the appropriate (Lorentz) dot products, but doesn't combine them in a sensible way.

While looking up information about antialiasing I found out that shadows can be calculated with little to no impact on performance. The method needs to be converted to fit with our current system but it seems very doable. http://www.iquilezles.org/www/articles/rmshadows/rmshadows.htm

There are a lot of issues with our current lighting model in euclidean space. We'll most likely need to redefine texcube, phongModel, and estimateNormal.

Get distances from light to object (distance_LO) and object to camera (distance_OC). Then have some choices of fall off function for light intensities based on distance. E.g. f(dist) = 1/(dist^2) is inverse square fall off, which is correct for 3d euclidean space. Then the light intensities (both diffuse and specular (?)) get multiplied by

f(distance_LO)*f(distance_OC)

(Since there is fall off from the light to the object and from the object to the camera.)

Choices for f:
f(d) = 1 (no fall off, should be same as what we are doing now)
f(d) = 1/d (linear fall off)
f(d) = 1/d^2 (inverse square)
f(d) = 1/(cosh(2*d) - 1) ("physically correct" fall off for hyperbolic space, according to surface area calculation given at https://math.stackexchange.com/questions/1445278/what-is-the-volume-of-the-sphere-in-hyperbolic-space)

The last few cases we probably want to add a constant term, so it's really f(d) = k/d, where k is some magic number chosen to make it look ok.

Henry pointed out that we need to be careful about performance because of the raymarching (cubes can be fast because of quick "inside" checking).

To do this generically and support any Wythoff construction, we'll need to iterate on simplices instead of cubes. That will allow supporting honeycombs like the {4,4,4} or non-loop Coxeter graphs. I guess we'll see how the speed goes with simplices and maybe there are some optimization tricks we can do to reduce the number of steps during ray marching.

I've noticed that we have various event listeners in different files and I think it would be more clear to have them contained in a single file. This way if we notice that some event isn't responding we won't have to search for its location. Also if we need to create a new listener it'll be easier to avoid naming conflicts.

Toggle stereo
Eye turning on/off (Turn eyes inwards so that rays from center of each eye meet at infinity)
Alter MaxSteps, toggle whether or not CalcMaxSteps alters MaxSteps

The rendering looks broken for r != 6.

Henry had worked this out already, so the other values of r must have been broken by some intervening changes.

I believe I've pinpointed the start of this problem to the revision made here 15ab2ca I have yet to go through and see what was changed.

The two scene options Sphere_horosphere and Sphere_plane are a bit awkward because we can automatically pick the correct cut for a vertex (sphere, horosphere, plane) depending on whether the vertex figure is spherical, euclidean, or hyperbolic. Though it can produce cool looking results, it doesn't really make sense to construct a horosphere cut when you have a hyperbolic vertex figure.

Another option would be to have separate scenes for whether to include cell-centered cuts, vertex-centered cuts, or both.

Real world distances include interpupilliary distance, movement of the headset, keyboard movement controls. Add as a UI slider.

This was allow for cleaner code and access to post processing effects such as antialiasing and bloom.

Possible Upsides:

• Able to switch scenes faster
• Better performance

For readability I think it would be wise to refactor all JavaScript global variables to the same formatting. There isn't a defined coding convention so I suggest ALL_CAPS for our global variables. I noticed there was two variables named the same but in different scopes during my refactor of the VRControlsHyperbolic file, this should solve this issue.

In globalsInclude.glsl, the geometryNormalize, geometryDot, etc. functions have if statements that check the geometry. I think it would be better to only declare the function signatures in this file and have the individual geometry files implement the functions, avoiding these if branches. Info on declaring is here:

https://relativity.net.au/gaming/glsl/Functions.html

Somewhat related, we can move some functions like sphereHSDF out of the specific geometry files because now that there is a geometryDistance function, the implementation is the same in every case. This should live in globalsInclude.glsl

In short, we should keep any geometry-specific code in the geometry files and any geometry-agnostic code in the globals file.

Hamish Todd having some trouble with the display. He writes:

"it's responding to orientation change but not displaying in headset, both for firefox nightly and chromium"

https://twitter.com/hamish_todd/status/991372931367342080

How does the lighting model change if the objects themselves have colours?

This is just to remind us about this code cleanup need.

It's +++- in the javascript, and ---+ in the glsl

(slightly related: it's a bummer that I had to add a separate lorentzDot method for the three.js vector structure. I wonder if there might be a way to avoid that.)

Currently an issue with moving between cells and the mapping onto global objects. It seems that as you switch cells the textures on the global sphere object change.

I bet this can be fixed by making gluing between cubes a consistent manifold.

When I first load, I get high quality, then it morphs to low quality. Chrome may be attempting to optimize the refresh rate, which slows the FPS, which affects the calculation for max steps in a negative way.

Anyway, if I set the maxSteps to a higher value, I can render smoothly with better results, so the heuristic needs to be improved.

WebGL is not being initialized in the current version of the program for mobile devices.

Antialiasing for ray marching means sending more than one ray per pixel, then averaging the result. With ray marching, we should be able to detect when this is worth doing: when a given ray takes a large number of steps, there is probably something interesting going on there, so its worth sending more rays inside this pixel.

There are a few tasks to be done for the VR controllers.

• Track controllers and pass info to shader

• Attach light objects to controllers

• Add simple flight controls in order to move around the scene

• Allow for different types of controllers (i.e. Vive, Oculus, etc.)

• Control brightness and hue from controller

• Add Ellipsoid like shapes for the controller body

Currently in headset the images appear blocky around the edges of objects. Currently we are outputting 960X1080 to each eye however the screen of the Vive supports 1080X1200 per eye. I will see if we can pass in the resolution of the Vive instead of the computer screen.

i.e. support any set of active mirrors in the Coxeter diagram. Right now, we're mainly supporting mirror 1 being active, and kind of supporting mirrors 1 and 2 being active with the "truncations".

This task depends on first extending the support for symmetry groups: #3

An important part of this will be to pick a good UI. Maybe 4 checkboxes for the active mirrors?

We need a set of methods like the current hyperboloid methods, but for S^3.

My main question: Do we want to try to mash this all into one shader, or do we want a separate shader for the spherical (and maybe euclidean) cases? A separate shader would avoid some branching within the shader execution, but that might be trivial performance-wise. I'm leaning towards two separate shaders, one for spherical+euclidean, and a second for hyperbolic. We could, however, share some of the include shader files between the two.

e.g. NSF/OSU logos

I saw Henry posted pictures on twitter for this a while back, and it seems like a standard scene we should include.

Detect position, have some indicator of position visible in the simulation.
Be able to use buttons etc for input.

We could provide a few options in a dropdown (zero, small, med, large). I wonder if a slider is easily doable.

Should be lit by the lights. Maybe also implement cuboids (as min of abs of distance from three geodesic planes).

Some of the uniforms that we have in place for the material/shader are not being used and can be removed.

Predistort the positions of the rays so that they undo the distortion from the headset lenses. From http://doc-ok.org/?p=1677, the data of the distortion mesh should be available to us?

On iOS we seem to bail out of the ray marching for loop early (for some noisy flickering collection of pixels) resulting in us getting the background colour.

For r=5 it looks like something is wrong with the geometry = 1 case. Perhaps HalfKleinCubeWidth is not getting set properly?

For r >= 7, rays that should be going off to infinity are not - they seem to be getting hitwhich = 3 when they shouldn't.

I figure adding object constructors to the JS should be pretty simple and help cleanup a bit of the code.

I wasn't certain what the values needed to be changed to for each different edge case. In scenemanipulator.js it should be easy enough to switch them to their proper values in the switch case block.

Reset currentBoost to the identity, and reset the cellBoost (?) matrices as well.