Optical speed of light delay
WrathfulSpatula opened this issue · 8 comments
(Sorry if I'm putting a lot of newbie activity on the repo, but I'm new to the social aspects of Git. Thank you for open-sourcing your engine!)
Is optical speed of light delay completely handled in the engine? There's a clock delay from the Lorentz transform, but I think that the optical appearance of time to the player should also be delayed by the distance between the player and a relativistic object. I've worked with this before, and I think we need a getter like:
public double totalOpticalTime { get { /*Total time on the world clock...*/ return state.TotalTimeWorld /*...Delayed by the distance between the player and object in Minkowski space*/ - (transform.position.RealToPosition(-state.PlayerVelocityVector) - state.playerTransform.position).magnitude / state.SpeedOfLight; } }
The "optical clock" should be used as the effective clock of the object for physics updates, both Lorentz transformed and delayed by the finite velocity of light, since the player should see the optics rather than the bare Lorentz transform.
(Specifically, I think the shader might be right, but the rigid body mechanics might not be. We need local rigid body update loop clocks.)
I need to tweak the collision parameters in the latest commit, and reimplement the sender/receiver test pairs, but this commit contains an attempt at speed of light propagation delay logic. Without speed of light delay, (and without accelerated frames,) there's no "twins paradox," or an incorrect twins paradox. (The twins "paradox" is actually a well-established feature of relativity.)
If anyone is paying attention, note the sender/receivers still aren't right, despite the note on the commit. For "simultaneous" start, (which is technically impossible in relativity,) or apparently simultaneous in the world frame, the initial launch needs to be delayed by the distance between player and sender at start, and the timer update should probably use the optical time, but this doesn't seem entirely right, yet. Partially, this might have to do with the optical time being (potentially unstably) sometimes delayed by one frame. I haven't figured it out completely, yet.
(The shader might also need a small parallax propagation delay correction, with an optical clock. Sorry to talk to myself, but trying to document for reference.)
"tisw" is "time in SEEN world," isn't it? Boy, I just reinvented the wheel. I'm reverting that part while leaving the accelerated frames and collision mechanics in. Thank you!
I've undone changes related to "tisw." Thinking the shader was performing a bare Lorentz transform, I treated f(-x) as if the inverse of f(x), which it is not, with f(x) being the shader transform as a function of velocity. I need to find the inverse, but my time has become more limited after last week. Know that the code on my fork still needs this inverse mapping, right now. Thank you!
You folks really have a beautiful engine, by the way. I see that you relied on the native rigid body mechanics to update position, by accounting for player frame time dilation in the rigid body velocities, and then you project to the optics with your shader. I'm going to try to bring accelerated player frames into line with this approach. (I'm not going to worry about drag for the moment, or the tiny correction for changing player position.) Then, I'm going to try to invert the transformation by your shader to use it to keep optical position constant under changes of rigid body velocity. (I think my original angular correction to the shader was wrong, so I'm going to comment that out for the moment.)
(Sorry to spam, by the way, but I'm hoping this thread might be useful as a reference.)
Okay, sorry to talk with myself. My original question is in fact answered: speed of light delay is factored by the shader, so I'm closing this issue. Thank you again.