Double precision xyz files

[chris]

When Celestia loads an xyz trajectory (SampledOrbit), it stores the points of the trajectory as single precision values. This is not adequate for a lot of applications. I made the decision to use single precision in order to reduce Celestia's memory usage, but I don't think that it's too much of any issue. My feeling is that we should just make all SampledOrbits double precision, but this could cause some problems:

- Compatibility with existing add-ons. It's possible that add-ons which use xyz files and have objects very closely placed to each other will not look right after a switch to double precision.

- Cel URL compatibility. Cel URLs that position a camera next to a spacecraft with an xyz trajectory will probably not work.

- Memory usage. Are there add-ons that use many megabytes worth of xyz files? The extra memory consumed by double precision numbers could be a problem.

If there are big problems, I can find some sort of compromise--either a config file setting, or an ssc file option. But, the simplest thing to do, and what I would definitely do now if I wasn't concerned about compatibility, is to make all SampledOrbits double precision.

To give a sense of the magnitude of position differences, single precision floating point numbers have 23 bits of precision, or roughly 1/8 million. If your xyz file positions an object at 8 million km from the center of it's reference frame (parent object), then the maximum difference you'd see when switching from single to double precision is half a kilometer. The error scales linearly with distance, thus at 80 million km, the max difference is about 5 km.

Opinions?

--Chris

[Cham]

IMO, an option at the SSC level, which gives the user the freedom to use single or double precision, would be best. That way, some spacecraft could be defined with single precision, while another one could be defined with double precision. The default should be single precision (for addon compatibility and memory usage).

Is that possible ?

[chris]

IMO, an option at the SSC level, which gives the user the freedom to use single or double precision, would be best. That way, some spacecraft could be defined with single precision, while another one could be defined with double precision. The default should be single precision (for addon compatibility and memory usage).

Is that possible ?

It's possible. It could take the form:

Code: Select all

SampledOrbit
{
    Filename "mytrajectory.xyz"
    DoublePrecision true
}


. . . and the old form would still work and produce single precision orbits. The thing that I don't like about this is that it makes people do extra work to get double precision. Alternately, DoublePrecision could be true by default whenever the new form of SampledOrbit is used. That would make me a little bit happier, but there's still possible confusion from overloading SampledOrbit.

--Chris

[Cham]

The thing that I don't like about this is that it makes people do extra work to get double precision

Doh ! The "extra work" of adding the command DoublePrecision true isn't extraordinary. On the contrary, by adding this small bit to the SSC, the user knows exactly what is happening in his code. I think this is the best solution.

[chris]

The thing that I don't like about this is that it makes people do extra work to get double precision

Doh ! The "extra work" of adding the command DoublePrecision true isn't extraordinary. On the contrary, the user knows exactly what is happening in his code, adding this small bit to the SSC. I think this is the best solution.

No, it's not extraordinary, but I hate for users to do the straighforward thing and have it not work because the precision isn't adequate. What I currently favor is to make DoublePrecision default to true, so that both of these orbit definitions would be double precision:

Code: Select all

SampledOrbit
{
    Filename "trajectory.xyz"
    DoublePrecision true
}

SampledOrbit
{
    Filename "trajectory.xyz"
}


While these are single precision:

Code: Select all

SampledOrbit "trajectory.xyz"

SampledOrbit
{
    Filename "trajectory.xyz"
    DoublePrecision false
}


--Chris

[chris]

By making the double precision the default may bring some problems to many of the old and currently nicely working addons, URLs, and more memory usage. I don't feel the default should be double precision, but I may be wrong.

My last proposal won't affect old add-ons. SampledOrbit "blah.xyz" would still do exactly what it used to.

--Chris

[Cham]

Yes, but you replied to fast to my last message, I erased it immediately after creating it !

Edit : However, I'm a bit afraid about the memory usage. Celestia 1.4.1 on the old PCs at my work place are already having an hard time running Celestia. Using Celestia 1.5.0 may even be a real problem, there.

[BobHegwood]

Code: Select all

SampledOrbit
{
    Filename "trajectory.xyz"
    DoublePrecision true
}

SampledOrbit
{
    Filename "trajectory.xyz"
}


While these are single precision:

Code: Select all

SampledOrbit "trajectory.xyz"

SampledOrbit
{
    Filename "trajectory.xyz"
    DoublePrecision false
}


--Chris

For what it's worth, I LIKE the proposed methodology. If you have
an old, slow machine, (Which I was VERY used to) you can simply
change the code with the few lines as described above. None of
my business, but it's easily understandable, it works and it's
EASY. What else do we need?

Thanks, Brain-Dead

[rthorvald]

If there are big problems, I can find some sort of compromise--either a config file setting, or an ssc file option. But, the simplest thing to do, and what I would definitely do now if I wasn't concerned about compatibility, is to make all SampledOrbits double precision.

Oops, there my Ran project went poof again, with its 86 XYZ files

- rthorvald

[chris]

If there are big problems, I can find some sort of compromise--either a config file setting, or an ssc file option. But, the simplest thing to do, and what I would definitely do now if I wasn't concerned about compatibility, is to make all SampledOrbits double precision.

Oops, there my Ran project went poof again, with its 86 XYZ files

Wow . . . ok, I'll try and come up with something that doesn't mess up Ran. The proposal I made would maintain backward compatibility.

--Chris

[chris]

Here's what I have implemented in a patch (not yet checked in):

Code: Select all

SampledTrajectory
{
    Source <filename>
    DoublePrecision <boolean>
    Interpolation <string>
}


The Source property is required, while the others are obption. Valid values for interpolation are currently "linear" and "cubic", with cubic the default. DoublePrecision defaults to true.

Why not overload SampledOrbit instead of introducing a new orbit name?
It would be just as easy to overload SampledOrbit so that it if a string followed SampleOrbit, it would work just as before, and if a table followed, it would work in the new manner. But, I think that the new nomenclature is better, because orbit suggests to me a specific type of trajectory.

This is a new SSC property and will not affect existing add-ons that use SampledOrbit.

--Chris

[Adirondack]

Chris,

I tried your samptraj.ssc but it doesn't work since the parent object in your
SSC is "Sun" instead of "Sol". If I rename "Sun" to "Sol" it works anyway.

Adirondack

[chris]

Chris,

I tried your samptraj.ssc but it doesn't work since the parent object in your
SSC is "Sun" instead of "Sol". If I rename "Sun" to "Sol" it works anyway.

Adirondack

Hmmm . . . It should work because Sun is a synonym for Sol in nearstars.stc. Maybe it only works in the English version of Celestia?

--Chris

[Adirondack]

Maybe it only works in the English version of Celestia?

Yes, in deed. "Sun" works on the english version!

Adirondack