How big is space in Orbiter?

[Acepilot]

Anyone know how far one can travel in Orbiter?

I was wondering if traveling to an Extrasolar planet could be possible?

Such as Gliese 581c. The newly discovered "Earth-like" planet that has a habitable zone.

Link to Gliese 581c: http://www.age-of-the-sage.org/planet_gliese_581_c.jpg

Thanks

 

[Donamy]

Depends what you mean by traveling.

 

[Tommy]

Orbiter doesn't support interstellar flight, only one solar system at a time. That said, there's an add-on called MSS or somesuch that provides a sort of "work around" for that, but it's not true interstellar flight.

It's possible to have "alternate" solar systems, such as the Gliese system, someone just needs to make it.

 

[Hielor]

When you get too far away from the center of the solar system, precision begins to drop, and it makes docking pretty much impossible. This is a limitation of the floating point type.

 

[Acepilot]

Ok, so if I venture off to Neptune and try to dock with something it'll be harder to control?

 

[Hielor]

Ok, so if I venture off to Neptune and try to dock with something it'll be harder to control?

The difference shouldn't be noticeable at Neptune, but if you were at an accurate distance for another star system (~4ly) it would definitely be noticeable.

 

[tblaxland]

The difference shouldn't be noticeable at Neptune, but if you were at an accurate distance for another star system (~4ly) it would definitely be noticeable.

Correct me if I'm wrong, but from what I've seen Orbiter uses double precision internally and single precision when parsing scenario files. At Neptune double precision will yield a position precision of about 1.5um, so you should have any trouble with that. If you save and reload the scenario just prior to docking, you may have some issues since single precision will yield a position accuracy of only 800m. So when you reload the scenario you ships could be up to 400m closer or further apart than when you saved it. This is only my theoretical musings - I haven't tested this but I would be most interested if someone did.

EDIT: At 4ly, double precision would have a position precision of about 12m.

 

[Acepilot]

Ok, I understand now.

Is the future version of Orbiter going to support interstellar space flight?

 

[MajorTom]

If future versions of Orbiter stick to realistic, currently achievable spaceflight, then adding interstellar destinations would be sort of pointless, unless you're prepared to simulate decades, centuries & millennia of travel time. Which would only be supportable by crew hibernation technology, or advanced robotics, or more advanced space propulsion techniques, none of which are "realistic" by today's standards. Oops, there goes interstellar travel.

But if we're to decide Orbiter should also embrace Sci-fi simulation and enhance its support for Star Wars / Star Trek ships or anything with a fantasy space drive that allows FTL travel, then sure, Martin might as well make space big enough to include interstellar destinations. But then, the name of the simulation might as well be changed to something different, like "Star Voyager" or even "Eve Online" or "Celestia." Merely orbiting would, in such a universe, seem pretty low tech.

 

[flytandem]

My furthest as far as a planned flight was a series of slings that at midpoint had a fly-by of Pluto followed by a nice arcing ellipse that after Pluto, took 18 hours at warp100K passing an Ap about 1.5 times Pluto height before arriving back at Neptune for a reversing series of braking slings down the outers like a celestial pinball to finally land back on Earth. 350 or 400 sim years as I recall. It took a week of real time to complete.

My wife still wonders where I went that week. My answer "looking over new horizons" didn't mean a thing to her.

 

[garyw]

Nice flytandem, I'd like to try out NASA's proposed TAU (Thousand AU) mission.

 

[cjp]

About the range:
The maximum value of a double precision number is 1.7976931348623157 x 10^308. Assuming that Orbiter works with meters internally, and a lightyear is 9.461×10^15 meter, this is a range of 1.9 x 10^292 lightyears.

Assuming the size of the visible universe is 13 x 10^9 lightyears, the range is, uhm, more than enough.

It would be better if Orbiter were able of trading some range for accuracy, but unfortunately there are only a few floating point formats that can be used easily on standard PC hardware.

For accurate interstellar travel, I think the software architecture needs to be redesigned such that any relative coordinates don't depend on the accuracy of any absolute coordinate system. For the simulation, Orbiter might need to 'guess' which coordinate system is the most important (e.g. by looking at proximity of objects). Sounds like it makes a lot of things more complicated.

 

[Kozak]

The maximum value of a double precision number is 1.7976931348623157 x 10^308. Assuming that Orbiter works with meters internally, and a lightyear is 9.461×10^15 meter, this is a range of 1.9 x 10^292 lightyears.

Unfortunalely, you will hit the barrier earlier.
see http://en.wikipedia.org/wiki/Double_precision
When the distance to reference body exceeds 2^52m ~= 4.5*10^15m, Orbiter will work with a 1-meter precision. That is, no docking and high numerical instabilities. Futher - worse.

 

[Artlav]

Currently, it starts to look slightly jerky at Sedna's distance. Going some distance away makes quite a jumpy show.
Also, there appears to be a looping at some Kpc's away.

Yet, this is not an unsolvable problem - all you need is to define a coordinate grid on top of a coordinate grid, effectively doubling the range's order of magnitude.

 

[cjp]

Currently, it starts to look slightly jerky at Sedna's distance. Going some distance away makes quite a jumpy show.
Also, there appears to be a looping at some Kpc's away.

Yet, this is not an unsolvable problem - all you need is to define a coordinate grid on top of a coordinate grid, effectively doubling the range's order of magnitude.

I thought I just calculated that range is not a problem.

Accuracy is a problem however, especially at large distances. I never tried to deny that, in fact I assume the posts about accuracy are simply true.

Using a floating point grid with the same origin but a different scale doesn't solve the problem: you need to move the origin. If you want 'docking accuracy' around Alpha Centauri, you need a new coordinate system with the origin within the Alpha Centauri system.

 

[Artlav]

I thought I just calculated that range is not a problem.
Accuracy is a problem however

"Range" as in "useful accuracy range".

Using a floating point grid with the same origin but a different scale doesn't solve the problem:

No, what i meant is a triple grid.
One grid is the same as in Orbiter.
Second grid is for interstellar travel scale, in Spaceway that is 112 AU per unit.
Third grid is for intergalactic travel scale - 246000 LE per unit.

When a vessel approaches a unit border of a second grid, the origin of the first grid is shifted to the center of the next tile in second grid, same for second-third.

That way you can avoid bothering with closest object determination, and have the docking-grade accuracy even in deep intergalactic space.

 

[martins]

Note that orbiter's current physics engine already takes some measures to improve numerical precision over large dynamic distance ranges compared to a naive floating point implementation.

The main problem is the loss of accuracy when adding floating point numbers of widely different magnitude. The way this is implemented in the processor is

1. step one: equalize the exponents of the operands by shifting the digits in the mantissa.
2. step two: add the numbers by adding their mantissae.

Step one is the one that can lead to a loss of precision, since it may shift any number of significant digits out of the mantissa. In the extreme case, if the exponents differ by more than the number of digits stored in the mantissa, you will shift out all digits and end up with zero. You can find out this precision limit by finding an eps > 0 such that
1+eps = 1

Orbiter tries to overcome the worst of the loss of precision by storing position variables in two separate numbers:

- a base position
- an offset position

At each time step, the position change is added to the offset part of the position variable. At regular time intervals, the offset is flushed into the base, and the offset is reset to zero. The update intervals are chosen such that there is a compromise between the loss of precision when adding a single step to the offset, and the loss of precision when adding the offset to the base. Effectively, this scheme simulates a floating point representation with a longer mantissa.

If higher precisions are required, this scheme could be augmented by adding more stages. This would make calculations slightly less efficient, since each time you need the actual position of an object, you first have to add the contributions from all stages.

A better solution would probably be a reference frame that is moving with the observer, rather than one that is fixed at the solar system barycentre, as suggested above. This would however make a lot of computations more awkward than they are now.

 

[cjp]

Orbiter tries to overcome the worst of the loss of precision by storing position variables in two separate numbers:

- a base position
- an offset position

At each time step, the position change is added to the offset part of the position variable. At regular time intervals, the offset is flushed into the base, and the offset is reset to zero. The update intervals are chosen such that there is a compromise between the loss of precision when adding a single step to the offset, and the loss of precision when adding the offset to the base. Effectively, this scheme simulates a floating point representation with a longer mantissa.

That sounds smart.

How would that work if you try to do a docking between two spacecraft when the accuracy of their absolute position is not sufficient for this?

Let me try:

• Both ships have a base position and an offset position
• Normally, time propagation of both ships is only done on the offset position
• For rendering and for the 'docking port check', the difference between the ships' positions is used
• This difference is calculated as (base2-base1) + (offset2-offset1)
• Normally, base2-base1 doesn't change, and is sufficiently small for not ruining the accuracy of offset2-offset1. Therefore, the position difference is very accurate.

But what I don't understand is how you can safely flush the offset to the base. This is what it would do to the position difference:

• Before the flush, the difference is (base2-base1) + (offset2-offset1)
• After the flush, the new base becomes base+offset, and the new offset becomes 0
• So, after the flush, the difference is ((base2+offset2)-(base1+offset1)) + (0-0)

As far as I can see, the precision is largely lost in the addition of base+offset. Normally you wouldn't notice it, but when it happens during a docking procedure, I can imagine you suddenly see a jump in the relative position.

How do you avoid this? Do you delay the flushing as long as objects are in close proximity to each other, or do you 'fix' the offset values to maintain the same combined (base+offset) value as before the flush?

Sounds like a nice job for a cool C++ class with operator overloads etc.. Maybe even a template class to be able to change the number of stages.

 

[martins]

I didn't actually try to achieve anything remotely as sophisticated with the scheme I described. The only objective was to improve the precision of cumulative updates of small changes to a potentially large absolute position. If I added the small changes of a single step directly to the absolute position, I would lose most of the precision. The two stage scheme means that the (small) position updates are always added to a number which is itself fairly small, so the loss in precision is small. When the offset variable has grown in size due to continuous updates, it can be flushed into the base variable, again without too much loss of precision.

I am not trying to take advantage of this scheme to improve the relative position accuracy of two separate objects, e.g. by forcing their base positions to be equal. This would be an interesting idea, but I guess it essentially is equivalent to a change of reference frame (i.e. the frame in which the base positions happen to be zero). For example, you could divide space into "cells", where within each cell the base positions are constant, and the offsets describe the position within the cell. This way, all objects within a cell can calculate their relative positions purely from the offsets.

 

[cjp]

I think a flush that maintains accuracy can be made quite easily:

void flush(double &base, double &offset)
{
    double oldBase = base;
    base += offset;
    offset -= (base - oldBase);
}

In fact, if you don't mind the extra calculations, I think you can do this on every time frame. Offset will automatically maintain the correct magnitude to optimally improve the accuracy w.r.t base.

It can also easily be extended to more than two stages, at the cost of increased computation time. Not flushing every frame may make it faster, but improves code complexity, because you need to find out when flushing is needed (e.g. once every N frames, as a simple example).