Closed WrathfulSpatula closed 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.
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.
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.
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.
I think there's a basic problem with my
ComoveOptical()
method, forConformalMap
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 theviw
velocity toComoveOptical()
to be transformed into and applied in free-fall coordinates, but we can storeviw
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.