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}
)

 

[n72.75]

I'm coming back to this one after a long while, and finally manager to get this building under cmake-OpenOrbiter:

Here's a nice shot of 64bit Orbiter. Phobos is behaving nicely, as you can see (this is obviously quite unsurprising, given that Ajaja's original version is from circa 2008)




The only bit thing I'm still stuck on is what to do with all the VSOP87 code in the orbiter source tree. It's no longer needed with the spice modules, but on the other hand it is an extremely useful reference for implementing a Celbody module in orbiter. Rather than remove it, I'm doing this in the /src/Celbody/CMakeLists.txt

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


if(SPICE_BUILD)
    add_subdirectory(SPICE)
    add_subdirectory(Atmosphere)
else()
    add_subdirectory(Sol)
    add_subdirectory(Vsop87)
    add_subdirectory(Moon)
    add_subdirectory(Phobos) #Problem for x64
    add_subdirectory(Deimos) #Problem for x64
    add_subdirectory(Vesta)
    add_subdirectory(Galsat)
    add_subdirectory(Satsat)
    add_subdirectory(Miranda) #Problem for x64
    add_subdirectory(Ariel) #Problem for x64
    add_subdirectory(Umbriel) #Problem for x64
    add_subdirectory(Titania) #Problem for x64
    add_subdirectory(Oberon) #Problem for x64
    add_subdirectory(Triton) #Problem for x64
    add_subdirectory(Proteus) #Problem for x64
    add_subdirectory(Nereid) #Problem for x64
endif()

I do need to put together some detailed documentation on how to use this. Out of the box it should be a massive improvement in planet/moon position position/velocity accuracy, but as far as potential for addons goes, it should be super easy to add additional spice moons/TNOs/asteroids etc, and update for future versions of ephemerides are published. I was able to update update the DE440 (25 June 2020) kernels to DE442 (13 May 2024), which adds some improvements to the Uranus barycenter.

I'm not feeling super organized at the moment, and I'd like to to a bunch of testing before considering merging this, but I'm hopeful it makes it into the full release.

A few items, in case there are questions:

• The code that makes this work is by @Ajaja and NAIF not me. I'm just doing the integration
• Info on SPICE https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/Tutorials/pdf/individual_docs/03_spice_overview.pdf
• The module that this change adds (spice.dll/spice.so) is still just an a derived version of the CELBODY2 class (just like the VSOP87 modules were). The only difference is that it's a single module for all bodies, you just load different kernels (file containing the ephemeris/ides data), which is specified in the celbody's config file.
• I'm not currently building cspice from source, partially because there are ~2200 .c and .h files that would need to be added to the Orbiter source tree, and also because NAIF customized a bunch of these files x86 vs.64 and for MSVC vs. GCC, and I would need to conditionally include the at least 4 full copies of 2200 files, which seemed absord. I had a bunch of problems actually getting it to build because of a static/extern linkage problem too, so I'm just conditionally linking to the .lib/.a files for now. In theory the origionally Fortran 77 source could be included and the C89 source for cspice could be generated using f2c...but this is where I gave up.

 

[n72.75]

@Ajaja

I'm trying to understand a few things and put some documentation together.

The sun.cfg has:

   Kernel = Kernels\orbiter.bsp,Kernels\codes_300ast_20100725.tf,Kernels\naif0012.tls,Kernels\pck00010.tpc

But only orbiter.bsp for the other bodies. Why are these needed for the sun, but not for other bodies?

 

[Ajaja]

But only orbiter.bsp for the other bodies. Why are these needed for the sun, but not for other bodies?

Strictly speaking, the orbiter.bsp in the body configuration files are not necessary. The SPICE library needs to load each kernel file only once. I had previously used multiple kernel files for different bodies before merging them into a single orbiter.bsp file. Repeating this orbiter.bsp entry in each *.cfg file was simply a lazy way to avoid config parsing errors when a kernel was not specified. SPICE just ignores them, it does not try to load orbiter.bsp again if it has already been loaded.

 

[n72.75]

Strictly speaking, the orbiter.bsp in the body configuration files are not necessary. The SPICE library needs to load each kernel file only once. I had previously used multiple kernel files for different bodies before merging them into a single orbiter.bsp file. Repeating this orbiter.bsp entry in each *.cfg file was simply a lazy way to avoid config parsing errors when a kernel was not specified. SPICE just ignores them, it does not try to load orbiter.bsp again if it has already been loaded.

Ahh okay. I think I'd perhaps misunderstood a few things. How is this stored in memory?

 

[Ajaja]

How is this stored in memory?

In the kernel pool. It's all managed by SPICE library, I didn't dig deep into the details.

 

[n72.75]

@BrianJ has very generously contributed his Ceres Addon. Now Vesta's sister has joined the party, and thanks to the same Dawn mission that brought us Vesta textures, elevation, and gravity model, Ceres also has these things.

 

[n72.75]

The MIT license friendly version of Amalthea here in all it's Level 5 glory. It's quite low res, but it's a good representation. Maybe someone can release a high-res version under GPL. Good enough to prevent a "Missing textures error". It's a very lumpy potato. It's also huge, given it's shape (257 km long)

 

[n72.75]

I swear I'm not completely distracted making moons

L5 Phoebe, also from Phil Stooke shape models.

 

[Ajaja]

But only orbiter.bsp for the other bodies. Why are these needed for the sun, but not for other bodies?

Finally, I’ve fixed this in https://github.com/Ajaja/spice_orbiter
There is now no need to duplicate kernel loading in each *.cfg file.
I’ve also updated orbiter.bsp for the latest SPK versions and added a GitHub Actions script to build spice.dll.

 

[n72.75]

Finally, I’ve fixed this in https://github.com/Ajaja/spice_orbiter
There is now no need to duplicate kernel loading in each *.cfg file.
I’ve also updated orbiter.bsp for the latest SPK versions and added a GitHub Actions script to build spice.dll.

Nice! Thank you.

I will merge this into my branch and hopefully we can get it merged into Orbiter soon. I think the missing textures that I see you've added were one of the last pieces of that. Thank you.

 

[Ajaja]

The one important thing that is missing now is celestial body orientation. SPICE can handle this very easily.
I think the simplest way is to add something like this to Celbody.cpp, in CelestialBody::GetRotation(..):
if (module && module->bRotation())
return module->clbkRotation(mjd, rot);
...
Then it will be possible to implement this rotation in spice.dll.
It will also be possible to implement any custom rotation for any Celbody using external modules.

 

[n72.75]

The one important thing that is missing now is celestial body orientation. SPICE can handle this very easily.
I think the simplest way is to add something like this to Celbody.cpp, in CelestialBody::GetRotation(..):
if (module && module->bRotation())
return module->clbkRotation(mjd, rot);
...
Then it will be possible to implement this rotation in spice.dll.
It will also be possible to implement any custom rotation for any Celbody using external modules.

I think I may do this as a seperate pull request but this is a high priority on my list. The current rotation rate necessitates a lot of compromises if you want long-term accuracy. Having neutation would be really nice too.

 

[n72.75]

The one important thing that is missing now is celestial body orientation. SPICE can handle this very easily.
I think the simplest way is to add something like this to Celbody.cpp, in CelestialBody::GetRotation(..):
if (module && module->bRotation())
return module->clbkRotation(mjd, rot);
...
Then it will be possible to implement this rotation in spice.dll.
It will also be possible to implement any custom rotation for any Celbody using external modules.

I'm going to add these. I will create a CELBODY3 class, so that I don't break any vtables (not that there are huge amounts of legacy celestial body addons, but still good practice).

I think I may do this as a separate pull request.

Scratch that idea, Matt. Going full-in on scope creep.