vm6502q / OpenRelativity

An open source framework to add the effects of traveling at relativistic speeds to visualizations or games
17 stars 2 forks source link

Free-fall / stationary-at-infinity bug #53

Closed WrathfulSpatula closed 3 years ago

WrathfulSpatula commented 3 years ago

I think there's a basic problem with my ComoveOptical() method, for ConformalMap instances: if I'm using free-fall coordinates, there is not simultaneously also a change in the object's velocity and finite difference iteration on its stationary-at-infinity "world" coordinates. If I want to use the free-fall coordinates, (and I think I do,) then I should probably pass the viw velocity to ComoveOptical() to be transformed into and applied in free-fall coordinates, but we can store viw in stationary-at-infinity form at the same time, so long as we don't then double-count on updating velocity/position in stationary-at-infinity coordinates.

WrathfulSpatula commented 3 years ago

If we ComoveOptical() without any consideration for viw, I never really properly considered this, be we can update the change in position due to "peculiar velocity" in stationary-at-infinity coordinates, I think. What I'm worried about, is that viw is also compounded by the apparent gravitational acceleration for a stationary-observer-at-infinity. I'm thinking about it, still.

WrathfulSpatula commented 3 years ago

The temporary attempt at a fix is to keep ComoveOptical(), track viw in stationary-at-infinity coordinates, but use viw plus the relatvistically added opposite of free-fall coordinates velocity to update piw due to "peculiar velocity" besides comovement.

The original reason for ComoveOptical() stemmed from my confusion, that viw=0 objects nearby the player didn't seem to fall inward, in Schwarzschild. In retrospect, I might have misjudged that they just fell inward really slowly, because they started close to the black hole, but at rest with respect to a stationary observer at infinity.

There are advantages to keeping ComoveOptical() and subtracting the free-fall velocity from piw update. However, we should perform a simple test: an object with orbital velocity, at a right angle to the radial unit vector, should actually orbit. We can test escape velocity, as well.

I'll test that tonight, and update as necessary.

WrathfulSpatula commented 3 years ago

I think I "solved" my mystery, for why viw=0 (relative to a stationary observer at infinity) lead to no movement of an object in a Schwarzschild gravity well.

It's not mysterious, and it's not wrong: Schwarzschild metric freely falls with Newtonian limit escape velocity in the inward radial direction. Therefore, by initializing any object at any distance with viw=0, meaning no velocity relative to a stationary observer at infinity, this implies exactly radially outward escape velocity relative freely falling coordinates.

So, again, that's actually right, just very counterintuitive. In fact, I really like the idea of keeping indices on both "world coordinates" as relative a stationary observer at infinity and "comoving coordinates" relative free fall. User code can easily use both, now.

As natural as it to initialize a "peculiarVelocity", i.e. relative to free fall, this whole situation becomes much less confusing. Also, in a simulation that prioritizes local mechanics, this probably sets a better frame for reducing numerical error. We'll keep it.

WrathfulSpatula commented 3 years ago

The above comment makes we realize something: our support for Unity's "quasi-Newtonian" gravity acceleration parameter in the physics system breaks allowable "gauge" for velocities, according to the possibility to Lorentz transform. However, it was always intended as an approximation to gravity, in this way! Rather than considering this a "bug," we recognize the potential for a new feature: alongside the Minkowski ConformalMap-sub-type, we'll have a RindlerNewtonian map, which sets the Rindler acceleration parameter from the Unity physics system, sets "gauge" by a plane through the origin, and already correctly treats peculiarVelocity by strict Rindler coordinates. If one wants better gravity approximation via the assumption of constant acceleration, (but less intuitive velocity definitions for viw and peculiarVelocity,) then one may use this new ConformalMap.

The original bug should be fixed, so I'm closing this.