Jupiter System - Galileo Mission with Spice Kernels

[volcanopele]

I have uploaded a newly created addon for Celestia for the Jupiter system and Galileo that uses Spice kernels. This addon requires the latest SVN file that implements CustomRotations, SemiAxes, and Timelines for ssc files. What is special about this file is that it adds spice kernel file support for Jupiter, Galileo, the Galileans, Thebe, and Amalthea. This increases the position accuracy for those bodies between 1972 and 2050 for Jupiter, 1995-2003 for Galileo, and 1995-2050 for the satellites. I tested the accuracy using the I24 encounter, a Galileo flyby of Io that took place on October 11, 1999 at 611 km. Celestia (before I changed Io to a tri-axial ellipsoid) came up with 610.5 km for the C/A distance. There appears to be an issue with the Galileo encounter with Amalthea in November 2002. The actual C/A distance was 500 km, Celestia gives 38,000 km. The position of Amalthea should be correct since I was able to accurately simulate this view of Amalthea and Io from November 1997. So probably the Galileo spice file isn't very good for very late in the mission.

I am going to try to do something similar for the Saturn system and Cassini. Right now I still need to fix the double appearance of the minor moons (probably because minormoons.ssc is loaded after my cassini.ssc file, so I get two Pans, two Atlases, etc.

The file is located at http://pirlwww.lpl.arizona.edu/~perry/C ... rSpice.zip

Please wait about 1 hour from the time of this post to download. I am still uploading the file and I need to go to sleep. Warning, file is 143 MB in size.

EDIT: File now completely uploaded!
I want to be sure to thank chris for his help in debugging my ssc file and in checking on my spice kernel files!

Enjoy!

[volcanopele]

A couple of screenshots:

IoandJupiter.jpg

GalileoPreI25.png

[volcanopele]

Here is a screen shot as a preview of my Cassini addon:

Enceladus_Rev131.jpg

[chris]

Here is a screen shot as a preview of my Cassini addon:

Enceladus_Rev131.jpg

Very cool! I'm downloading the Galileo add-on now, and am looking forward to the Cassini one--especially the 25km flyby during the XM.

You mentioned adding the triaxial shape of Io . . . Celestia doesn't correctly calculate the distances to triaxial ellipsoids right now. Calculating the distance between a point and triaxial ellipsoid involves finding the roots of a 6th degree polynomial. That's not so hard to do numerically, but there are also divisions by zero that tend to occur when the point is near the coordinate planes. I'll sort this out before too long, though.

--Chris

[volcanopele]

The 25-km pass seems to be pretty spot on in Celestia, though it gives a slightly different number due to the semiaxes issue.

It looks like Celestia just uses the a-axis value (or the maximum axes) value for radius (as seen in the Enceladus screenshot above) and for calculating distances. One possible stopgap measure would be to have both radius and semiaxes values in the SSC entry. semiaxes would be used for drawing the body, while Radius would be the average value used in the text at upper left and for calculating distances.

BTW, it seems like the only way to resolve the multiple copies of certain moons is to remove their entries in numbermoons.ssc or minormoons.ssc . For the Jupiter System add-on, you would need to delete Thebe from the minormoons.ssc file.

I am going to upload an update soon. This would just include those files I've updated, so you don't have to download that huge file again, and I don't have to upload it. Mostly some slight edits to the SSC file, and I rotated the Jupiter map back 180 deg. I thought that the map on Steve Albers page was rotated 180 degrees from what it should be for Celestia, but it appeared to be correct as is according to the Solar System Simulator. It wouldn't be in the upcoming update, but I am also considering investigating creating a specular map for Io (some of Io's volcanoes glint at V. High phase angles, like Loki).

[selden]

.BTW, it seems like the only way to resolve the multiple copies of certain moons is to remove their entries in numbermoons.ssc or minormoons.ssc . For the Jupiter System add-on, you would need to delete Thebe from the minormoons.ssc file.

I would think that the Replace prefix would be appropriate. That should cause the existing definition to be replaced by your new Timeline definition. Unless there's a bug in Celestia

[volcanopele]

I tried that, but it still generates duplicates copies of moons that are in both my SSC files and in minormoons.ssc or numberedmoons.ssc. It seems like it might be related to the fact that those two SSC files are loaded last by Celestia.

[selden]

Sounds likely. SSC files and directories are loaded alphabetically, so you might either give yours a prefix of zz or put them in a subdirectory. As best I can tell, catalog files in /extras/ are loaded before catalog files that are in a subdirectory in /extras/

[chris]

I tried that, but it still generates duplicates copies of moons that are in both my SSC files and in minormoons.ssc or numberedmoons.ssc. It seems like it might be related to the fact that those two SSC files are loaded last by Celestia.

This is a deficiency of Celestia's add-on system. There needs to be something like a 'require' statement that would force certain files to be loaded before others. In lieu of that, there are a couple possible workarounds:

- Rename the add-on directory to something like 'zzcassini' so that it gets loaded last. At least on Windows, files in extras are scanned alphabetically.
- Create a different extras directory for the SPICE add-on and either add it to the end of the ExtrasDirectories list in celestia.cfg or start celestia from the command line like this:

Code: Select all

celestia --extrasdir galileo-spice


--Chris

[volcanopele]

Prefixing "zz" to the directory names solved the problem. Thanks!

[volcanopele]

Here is Io with the beginnings of a bump map. I am having way too much fun with this program now.

Io_Bump_Map_test01.jpg

[volcanopele]

The Bump map seems to be going well, see below for new screenshots. I am a little concerned that features are being seen a little too far from the terminator, either slopes being visible on the nightside, or topography being visible on the dayside away from the terminator when it should be nearly invisible, except near the terminator.

Also, I set BumpHeight to 16. The base greylevel is 128 in the bumpmap image. 256 should equal +16 km. 0 should equal -16 km. I think this is the way it should work.

Io_Bump_Map_test02.jpg

Io_Bump_Map_test03.jpg

[chris]

The Bump map seems to be going well, see below for new screenshots. I am a little concerned that features are being seen a little too far from the terminator, either slopes being visible on the nightside, or topography being visible on the dayside away from the terminator when it should be nearly invisible, except near the terminator.

The problems with the features appearing too far from the terminator is probably due to you using an older render path. The OpenGL 2.0, NVIDIA combiner, and fragment shader render paths include a self-shadowing term that should prevent bump maps from making features appear lit on the dark half of a planet.

Also, I set BumpHeight to 16. The base greylevel is 128 in the bumpmap image. 256 should equal +16 km. 0 should equal -16 km. I think this is the way it should work.

The way that bump maps and BumpHeight works is actually different than that. Bump map values between 0 and 255 are normalized to [0, 1] and then multiplied by the bump height. This is then converted to a gradient by calculating differences between neighboring pixels. With a bump height of 1.0, two neighboring pixels with values 0 and 255 will have a 45 degree slope between them. With a bump height of 16, the slope between these pixels will be about 86.4, or atan(16).

How bump map values and bump height translate into actual heights thus depends on the dimensions of the bump map (in pixels) and the diameter of the object mapped. If you have a 1024x512 bump map, on a body with a radius of 500 km, each pixel of the bump map represents (2*pi*500)/1024 km at the equator. With a bump height of 1, we know that a difference of 255 between neighboring pixels gives a slope of 45 degrees, so the max height of the bump map is the same as the pixel size at the equator. In general, the max height representable in a bump map is:

(BumpHeight * 2 * PI * BodyRadius) / TextureWidth
Each step is 1/255 of this. Note that to maintain the same height range, the bump height must decrease proprotionally with TextureWidth.

This is not the only complication associated with bump maps. What I would strongly recommend is to use Fridger Schrempp and Robert Skuridin's nmtools package. Download and documentation are available here:

http://www.celestialmatters.org/?page_id=39

With nmtools, you create a height map and then specify a much more intuitive set of parameters to generate a normal map for use with Celestia. Bump maps are automatically converted to normal maps by Celestia at load time; however, nmtools does a much better job with the conversion, especially if your source height map is 16-bit instead of 8-bit.

--Chris

[chris]

I found the problem with the Amalthea encounter: there's a gap in the coverage for Amalthea in galileo_traj.bsp between 1998 Jan 1 and 1999 Sep 27. If start the second timeline phase after 1999 Sep 27, everything works great. It's an impressively close fly-by. Here's the modified Amalthea definition:

Code: Select all

Modify "Amalthea" "Sol/Jupiter"
{
   Texture "amalthea.*"
   Color   [ 0.63 0.45 0.35 ]
   Mesh "amalthea.cmod"
   Radius    134 # maximum semi-axis
   MeshCenter [ -13.616 -0.448 -4.436 ]
   Timeline
   [
   # Before Galileo
   {
      EllipticalOrbit
      {
      Epoch      2452583.763194445 # 2002 Nov 5 06:19UT (Galileo encounter)
      Period          0.498179     # mean
      SemiMajorAxis   181994.78    # at epoch
      Eccentricity    0.0045045    # at epoch
      Inclination     0.384285     # at epoch
      AscendingNode   220.288958   # at epoch
      ArgOfPericenter 301.622765   # at epoch
      MeanAnomaly     315.352094   # at epoch
      }
      #Ending "1996 09 29 00:00"
      Ending "1999 09 29 00:00"
   }
   
   # Galileo Mission
   {
      OrbitFrame { EclipticJ2000 { Center "Sol/Jupiter_bary"}}
      Ending    "2003 01 02 00:00"


      SpiceOrbit
      {
         Kernel "galileo_traj.bsp"
                     Target "505"
                   Origin "5" 
         Period          0.498179     # mean
         Beginning "1999 09 29 00:00"
         Ending    "2003 01 02 00:00"

         BoundingRadius 1e10
      }
   }

   # JUP230
   {
      OrbitFrame { EclipticJ2000 { Center "Sol/Jupiter_bary"}}
      Ending    "2049 12 31 00:00"

      SpiceOrbit
      {
         Kernel "jup230.bsp"
                     Target "505"
                   Origin "5" 
         Period         0.498179
         Beginning "2000 01 02 00:00"
         Ending    "2049 12 31 00:00"

         BoundingRadius 1e10
      }
   }
   
   # After Galileo
   {
      EllipticalOrbit
      {
      Epoch      2452583.763194445 # 2002 Nov 5 06:19UT (Galileo encounter)
      Period          0.498179     # mean
      SemiMajorAxis   181994.78    # at epoch
      Eccentricity    0.0045045    # at epoch
      Inclination     0.384285     # at epoch
      AscendingNode   220.288958   # at epoch
      ArgOfPericenter 301.622765   # at epoch
      MeanAnomaly     315.352094   # at epoch
      }
   }
   ]
}


--Chris

[volcanopele]

Thanks, Chris. In my current version, I just ended up deleting that part of the timeline. Since Amalthea is defined by JUP230 during the encounter, it should still be fine. I am going to upload tonight a new version of the file to http://pirlwww.lpl.arizona.edu/~perry/C ... rSpice.zip if you want to play around with my new version. Again, this is a very large download.

This file includes my current bump map. I have added a few more mountains, plus I used the blur tool on some in Photoshop to make some of these mountains looks a little better. Here are a couple of screenies:

Io_Bump_10ISTOPMAP01.jpg

Io_Bump_32ISTERMAP01.jpg

[volcanopele]

I have uploaded a new version of my Jupiter system add-on to my website:

http://pirlwww.lpl.arizona.edu/~perry/C ... rSpice.zip

Among the feature updates:

* Hires textures improved to 4k
* Now includes all 4 inner satellites of Jupiter
* Jack Higgins's shape models for Metis, Adrastea, and Thebe used (though not included in this zip file; please see README file for link)
* Rotation model for inner satellites fixed
* Spice kernels for Galileans, Amalthea, and Thebe now cover period from 1950-2050 thanks to use of JUP230-long.bsp file
* Juno mission added (xyzv file covers entire mission from launch to Jupiter crash)
* HST Jupiter basemaps for 2007 and 2008 included as alternative textures

Please note that three of the spice kernel files used in this add-on are not included in this download. Please read the README file to get the links for these files. Make sure to download those to the add-on's data directory.

[John Van Vliet]

--- edit ---

[volcanopele]

BTW, I just noticed an error in the readme file. Make sure to put Jack's minor satellite models in the Celestia\extras\zzJupiter Spice\models, not the textures directory (though I am sure most of you who already download this in the last hour caught that

File updated accordingly.

[volcanopele]

Here are a few screenshots from the Juno part of the add-on (note, in the release version, I use Cassini as a stand-in for Juno until a 3ds model for the spacecraft is made available. In my in-house version, I use TERRIER's Mariner 9 model because its solar panel configuration is closest I could find to Juno's):

[volcanopele]

Updated the zip file one last time with an updated juno.xyzv file. Forgot to increase the temporal resolution of Orbit 2's perijove. I have also uploaded the file separately to:

http://pirlwww.lpl.arizona.edu/~perry/C ... /juno.xyzv