Refactor, organize, document, squash work relative original repo

[WrathfulSpatula]

When I started working on expanding this fork of the OpenRelativity repo, a few years ago, I didn't know what I was doing with Git. As a physics student, it was a fun project I started on a week of vacation, for a video game I wanted to make, but I had no collaborative Git or Agile experience. (Apologies to MITGameLab for the spam and intractable PR, from that time.)

I've since been (co-)lead developer of https://github.com/vm6502q/qrack, a high performance quantum computer simulation framework, along with https://github.com/bennbollay, having started the project in November of 2017. Basically, now I want to bring this fork to a similar standard to Qrack. That other project is at a good place, for now, and I find my curiosity and attention pulled naturally back to relativity and video game development, with some regular free time on my hands.

Some of what I develop with OpenRelativity for my game project is intended as strictly game mechanics, "for fun." I originally wanted, and still want, everything that was more-or-less "textbook physics," in my understanding, to go back to this open source repository, under the MIT license. I hope it's useful to someone else, or fun.

Some of the current work is physically "half-baked." In particular, the "ConformalMap" class is meant to let the developer apply generally curved background geometry to the space-time, and I think the "Schwarzschild" subclass is just broken. Even if that class is fixed, the intervals might be correct, then, but not necessarily the "lensing" effect it should have on where objects appear. By the design of the original shader and RelativisticObject class, I think apparent position is only correct if the space is flat.

On the positive side, in retrospect, I think the collision mechanics are physically passable, in concept. Video game collision mechanics often use the "impulse mechanics" of Newton. I think it is well motivated to replace the nonrelativistic velocity of the impulse mechanics with the relativistic rapidity (https://en.wikipedia.org/wiki/Rapidity). Similarly, the work I've done with lighting relies on a restriction already commonly placed on "baked" video game lighting--that light sources, shadow casters, and receiving surfaces are all respectively static and stationary relative "world coordinates," in which case the relativistic aspects of lightmap baking and live display are almost "trivial." (As I said above, this doesn't hold with curved background geometry, though, including a pseudo-Newtonian gravity background acceleration, which would be roughly equivalent to "Rindler metric," https://en.wikipedia.org/wiki/Rindler_coordinates.)

On that note, liberal application of Rindler coordinates, under the assumption of Einstein equivalence principle, (that a gravitational field is locally indistinguishable from a uniform acceleration,) opens up a lot of quasi- general relativistic effects, though not the coupling of stress-energy-momentum ("SEM") to curvature, as per the Einstein field equations. It lets us approximate what the player sees in the presence of a "background" gravitational field to which the player's SEM makes a negligible perturbation, such as a human being standing in the gravitational field of earth. Further, at "game-realistic" magnitudes of first-person acceleration, the Rindler-like effects of player acceleration are indispensible, we see at "second iteration," for even video game physics.

I'm picking this project back up, partly motivated by the desire to complete my original game project. (http://pastinfinityvr.com) I want this fork to be rigorous and clean, in hope that it's of use to others, if "for fun."

[WrathfulSpatula]

4 #5 and #6 in particular "fix" Schwarzschild, I think, and maybe general problems. I believe the "ConformalMap" class and subclasses can be considered production quality, now.

[WrathfulSpatula]

Schwarzschild is actually still very broken. I think generally curved spaces (beyond Minkowski under uniform acceleration) is outside of my immediate scope. I think I'm just going to cut "ConformalMap" from the repo, for the time being, until such a time that I need it. The game I am working on has no particular need of it.

It is my personal priority to refactor the current code-base to a production quality point that would be acceptable for a pull to the original repo, whether that pull ever happens, before moving on from physics module development to finish the rest of my game. Anything that doesn't work, (namely curved spaces beyond Minkowski under uniform accelerations,) will be cut. Everything that does, (I think I can say, basically everything else, to acceptable physical rigor,) will be cleaned up and squashed for potential use upstream, or downstream.

Next up is bringing all shader variants to one file with shader_feature options, if feasible. (https://docs.unity3d.com/Manual/SL-MultipleProgramVariants.html) I want to use this code, and return it to the open source community, with the benefit of years of experience writing code since I first started playing around with it.