Better Ephemerides, Rotation Models, and a Solution to X64 Builds

[Ajaja]

As I do not have any idea of the SPICE-library and it's inner workings, is it possible to give a rough ratio of the size differences?
Something like "basic" 10 MB vs. "max-fidelity" 300 MB ?!

It depends on the number of celestial bodies and the time period it covers.
I currently use the orbiter.bsp file, which is approximately 600MB in size, as described here:

Better Ephemerides, Rotation Models, and a Solution to X64 Builds

The major roadblock to OpenOrbiter 64bit stability is a lack of source code for some of the celestial bodies (mostly moons of Uranus and Mars). In past Orbiter releases, these were always packaged as just a DLL and I'm not sure Dr. Martin S. ever had the source, at least it was never added to...

orbiter-forum.com

If there are more bodies and a larger time period to be covered, the file size could potentially reach gigabytes:

Index of /pub/naif/generic_kernels/spk/satellites

 

[n72.75]

It depends on the number of celestial bodies and the time period it covers.
I currently use the orbiter.bsp file, which is approximately 600MB in size, as described here:

Better Ephemerides, Rotation Models, and a Solution to X64 Builds

The major roadblock to OpenOrbiter 64bit stability is a lack of source code for some of the celestial bodies (mostly moons of Uranus and Mars). In past Orbiter releases, these were always packaged as just a DLL and I'm not sure Dr. Martin S. ever had the source, at least it was never added to...

orbiter-forum.com

If there are more bodies and a larger time period to be covered, the file size could potentially reach gigabytes:

Index of /pub/naif/generic_kernels/spk/satellites

For reference though, that 600MB covers a typical Orbiter solar system (plus Pluto), from 1960 to 2050 right? So reducing that time range down to 5 years or so would around 30MB

 

[kuddel]

@Ajaja : Thank you for the clarification

@n72.75 : Reducing it to "only" 5 years feels a bit too much (my opinion). Orbiter is frequently used to simulate "Space Race" times
and also long duration missions, starting "today", taking several years (or even dacades).
So the choosen period from 1960 up to 2050 seems very reasonable.
The "~30 MB option" on the other hand is much more download-friendly (and github friendly as well) I guess.

However, my question was answered and I have now a much better grip on the sizes, thanks (to both of you)

 

[Ajaja]

For reference though, that 600MB covers a typical Orbiter solar system (plus Pluto), from 1960 to 2050 right? So reducing that time range down to 5 years or so would around 30MB

It's ~34Mb. But now it won't work very well outside of this 5 years. I've been testing this today, the elliptical orbits calculated on the edges of the kernel interval are very inaccurate. Pre-calculated mean orbits would be more accurate, but it will be impossible to connect them seamlessly with the SPICE trajectories. Planets and moons will just teleport from one place to other at that moments.

 

[n72.75]

Perhaps there's a middle-ground/best of both worlds scenerio.

Incorporate the SPICE models into OO, but leave VSOP87/ELP82/SATSAT/GALSAT modules in the config files as defaults with the SPICE module commented. For the Uranus/Mars moons we can include elements (@Ajaja I believe has recently generated some that we could use), and also leave the SPICE module commented.

Not quite as clean as a direct replacement, but it does allow or better models, without adding complexity for first time users (who maybe aren't as concerned with accuracy to the meter over many years out of the box)...but on the other hand anyone who wants to use these models has to edit config files.

Is there a better way to do this? Maybe a built-in config file editor that works from the launchpad?

 

[Sword7]

It's ~34Mb. But now it won't work very well outside of this 5 years. I've been testing this today, the elliptical orbits calculated on the edges of the kernel interval are very inaccurate. Pre-calculated mean orbits would be more accurate, but it will be impossible to connect them seamlessly with the SPICE trajectories. Planets and moons will just teleport from one place to other at that moments.

Yeah. Astronauts will scream "Huston, we see planet teleport to other place!". I recommend larger ones for long space exploration.

Thanks for providing Ajaja's Spice module on GitHub. I cloned it. I reviewed that and recommended making document about how to get SPICE toolkit from NAIF website and build them into Spice module (spice.dll or spice.so for Mac/Linux).

 

[n72.75]

(I'm still interested in the SPICE modules, but given the some limitations discussed in this thread, it probably shouldn't be the default packaged with Orbiter, even if it is technically better)


As a stop-gap to making x64 builds at least usable (or testable to the point where we can find other bugs) I have a simple branch that just omits:

• Ariel
• Deimos
• Miranda
• Oberon
• Phobos
• Titania
• Triton
• Umbriel

From being installed. This is all done with some CMake commands that detect if Orbiter is being built with CMAKE_CL_64.

I need some input from the CMake experts here though.

I have two files: sol.cfg, and sol64.cfg

I want to only install one of these: sol.cfg in 32bit builds, or sol64.cfg (but renamed to sol.cfg) in 64bit builds.

What's the best way to do this?


This is the CMakeLists.txt for Sol.

# Copyright (c) Martin Schweiger
# Licensed under the MIT License

srcdir_to_tgtlist("${CMAKE_CURRENT_SOURCE_DIR}/Config" "${ORBITER_BINARY_CONFIG_DIR}" srclist tgtlist)
add_custom_command(
    OUTPUT ${tgtlist}
    COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_SOURCE_DIR}/Config/ ${ORBITER_BINARY_CONFIG_DIR}
    DEPENDS ${srclist}
)
add_custom_target(Sol
    DEPENDS ${tgtlist}
)
add_dependencies(${OrbiterTgt}
    Sol
)

set_target_properties(Sol
    PROPERTIES
    FOLDER Celbody
)

# Installation
install(DIRECTORY Config
    DESTINATION ${ORBITER_INSTALL_ROOT_DIR}
)