Reaching out to those who work on procedural universe generation, you math geniuses (or maybe even directly to the I-Novae magicians 
), I need some advice for my prototype to implement a robust “Travel-To-Target” strategy. No matter how simple it is.
I found some time to continue on my custom double implementation of Unity3D running as a sandbox within Unity3D, and utilizing Floating Point Projection to render large “double”-distances within Unity3D, I’ve finished my custom ransform-Class Extension that allows me to define positions on a Universe scale on a detailed sub-meter level. To do so each gameobject’s Transform stores a tuple with a “meter” and a “lightyear” value (both double types). You could image the lightyear coodinate of the tupel (e.g. 0,0,5) defines a “box” for the meter tupel wherein the meter coordinate is utilized from -9460730472580800.0d/2 (half a lightyear) to +9460730472580800.0d/2 (half a lightyear) range. That allows positioning on a precise submeter level (except for the very outer meter-tupel bounds where a bit of precision is lost, so to say while crossing border of a lightyear-“box” to the next one).
After implementing the instatiation of mesh-debug-prototypes of asteroids (that instanciate across a few lightseconds distances) and stars (that instanciate on a view multiple of ~1500 lightyears) I’d now like to add a simple travel mechanism for testing and to implement instanciation on a galaxy level.
However traveling turns out to be more complex than I thought, eventually one of you mathematicians can help 
My problem is that since I work with very large numbers for distances and velocity, I havent found a good way that prevents overshooting the target position or stopping too early, one that works with very different distances.
To find a initial working solution, for the ease of things at the begining the observer must have zero velocity.
I know the full distance from start to target once traveling is initiated.
For each physics-update in fixedupdate I know the remaining distance to the target as well as the distance already traveled, as well as the current velocity.
My current strategy is to split the overall travel-distance into phases, so an
- Acceleration Phase
- Travel Phase (constant velocity) and
- Deceleration phase.
Also for the ease of things I apply the same acceleration value in Phase 1) as well as for deceleration in Phase 3). Due to that I thought I could simply split the overall distance into 1/3 for each phase, calculate the velocity in Phase 2) which could e.g. be the velocity required to travel the distance in ~30 seconds, and lineary increase or decrease in Phase 1) and 3). Later my idea was to use the two point formula to check how much percentage of the distance of each phase is traveled and to smooth the acceleration using a sin.
However the condition changing between phases seems to be an issue, as the speed during traveling is at so distances that hight that even a moment too late makes the observer overshoot while too early makes the observer to stop too early. A typical travel speed to move to one of the next asteroids is approximately ~70Mm/s. So if the timing is not absolutely exact I miss the target during deceleration. So this static phase-approach might become a deadend.
So I start to think that I need a more dynamic approach, not one that simply works on the overall distance being split. But maybe one that more relies on the remaining distance to the target.
What I’ve tried also was to
- Add a fourth phase 4) Reach_Target that would differently try to reach the desired position once I overshooted or stopped too early. In fact that was the only approach where I managed to reach the target position, however I don’t like that approach as it feels like a workaround.
- Calculate the predicted brake-distance to move from Phase 2) (travel) to Phase 3) (decelerate). However again the problem with the condition occured leading to overshoot or stop too early.
- Use the overall- and the current distance and calculate the related value between 0 and 2 using the two point formula, and throw the result into a sin function which then defines a percentage amount of a maximum velocity - and completely skip phases. Even though the velocity was smoothed nicely I didnt reach the target, and the time traveling takes became hard to control.
Does anyone of you have an idea what could work better? Any advice is very much appreciated!
I feel I need a first simple robust strategy before dealing with more complex situations (shorter or very very long distances, or non-zero velocity during travel initiation).
PS: Glad to add a video of the different approaches once I get the recording tool back to work
PPS: All hands down 
to those who manage to implement these problems with much more dynamics like in games like I-Novae or even real world situations (autocontrols in automotives)…
