Cutting the edge in planetary rendering


Cutting the edge in planetary rendering

Planetary rendering in JPARSEC has been a great feature more or less well solved from the beginning. Renderings were overall good and better than in many other tools. Anyway, I always wanted to spend some time on this to try to reach the maximum level of quality, performance, and accuracy, and during the last month I have done a great effort to convert JPARSEC into a quite serious rendering tool.

The design of the RenderPlanet class has suffered dramatic changes. No more integer arrays to hold the image, now everything is integrated in BufferedImage objects in the class AWTGraphics (which implements the jparsec.graph.chartRendering.Graphics interface for the Java desktop platform). This organization means that planetary (and sky) rendering is completely independent from the target platform, and probably memory is better handled. Indeed, the implementation is also independent from the orientation (left/right, up/down) required for the rendering, and this allows to render the sky as it would be visible through different kind of telescopes, as they are defined in the TelescopeElement class. The implementation also considers the distances to the objects drawn (I use x, y, and a z coordinate), and this allows to create excellent 3d images using the Dubois anaglyph technique.

From the mathematical view the accuracy is much better, specially when rendering Saturn rings and their shadows. The squeme implemented before is replaced by a more simple and fast algorithm to rotate the view between the Earth and the Sun. FastMath class is used almost always, with a more accurate but still very fast implementation of the atan2 function. The performance is better by a factor of 3, so I have added the possibility of controlling the quality of the rendering with a simple static variable that holds the size of the rendering relative to the final output size. It can be modified to any value, but useful ones are 2 or 3 for very high quality, or 0.5 and 0.25 to reduce the quality in slow computers. The rendering is calculated for a bigger or smaller sizes, and later resampled using the accurate resize method of the Picture class. The result is an extremely smooth image.

The RenderSky class has been revised completely. In fact, I have tested it in a very throughout way. A lot of small bugs have been fixed, performance slightly improved, and I have also added some Milky Way textures to show a realistic view of the galaxy. The SkyChart component includes a new popup menu with the typical options you will find (spread over a lot of menus) in most planetariums for desktops.

A few tests

I have done some quality tests of the new implementation against other tools. The best reference for a real image is the HST. The images below shows some tests for the triple eclipse in Jupiter (March 28, 2004, 08:02:30 UTC), and the transit of Titan on Saturn (February 29, 2009, 12:09:30 UTC)


The tools used for the comparison are Stellarium, Celestia, SkyChart (or Cartes du Ciel), and the Solar System Simulator of the JPL. As you can see, differences with the real view of the planets are evident. The only other piece of software giving a correct view is SkyChart, which in fact gives almost the same output as JPARSEC. The other tools gives wrong positions for the satellites since they are not corrected for light-time effect, and only Celestia gives the shadows, but obviosly not the correct ones as seen from an observer on Earth. Since Io moves faster than Ganymede the renderings doesn't seem to represent the same instant. Respect JPARSEC it is noticeable some lack of accuracy in the position of Janus. This is due to the use of 10-year old elliptic elements (precessing ellipses) from JPL, but still the position is quite acceptable. Mimas is slightly closer to the edge of Saturn than it should, maybe the position is slightly wrong, or maybe the HST shoot was at 12:10 UT and not at 12:09. As an exercise I would ask you to clic on the Saturn image and look at the JPARSEC and HST images very closely. It seems to me I'm able to guess the shadow of Pandora on the HST image, exactly where JPARSEC predicts it, but I'm not completely sure.

The implementation of SkyChart is clearly the best after JPARSEC. Looking at the source code I see it uses the satxy program of the BDL, which gives the apparent X-Y position of the satellites from Earth with an accuracy of 0.5” or better. Good decission, but limited in time between 1990 and 2020. Note that compared to numerical integration techniques my implementation is better than 0.1" over a few centuries from J2000. Respect planetary ephemerides I saw errors of 3” in Stellarium (maybe also due to light-time). I also tested for these dates the ephemerides in XEphem (version 3.7.3 compiled in my old 32-bit computer and working without sky simulation due to some kind of conflict with libraries, since latest version doesn't compile in amd64). My first reaction was wow! the errors in the positions were 3' (minutes of arc) for Jupiter and 10' for Saturn! Finally I realized the equinox of the results was selected by default in J2000 instead of equinox of date, after correcting the errors were around the arcsecond. The tilt of Saturn rings was wrong by 0.5 deg (respect a correct value around 3 deg), and looking at the code XEphem uses a very old program for the satellites of Saturn (I remember I used it 15 years ago!), which is completely wrong for current dates, producing very bad ephemerides for saturnian satellites. XEphem is not exactly a friendly or visually excellent program, but it is used in some astronomical observatories despite of being so ugly and outdated in certain algorithms.

I wrote a few lines about these programs in the past. For me Celestia is too complicated to use, although for those used to it Celestia would be great and full of extensions. Stellarium is visually impressive and reasonably easy to use, but also not fully accurate for an astronomer. SkyChart is extremely slow and full of unrecognizable buttons, and XEphem ugly and outdated. The main drawback of my implementation is that it uses only the CPU, so it can't be as fast or visually as impressive as Stellarium, but the renderings appear more realistic to me since graphics cards produces very soft images. Overall, for me the best free planetarium for desktops continues to be KStars, although now I prefer my own ClearSky project or the applet, which are clearly better in many ways, even in terms of performance. For a better experience the applet now includes a button to show the sky in full screen mode, working fine at least on Linux. Stellarium is the best choice for an excellent visual quality.

Testing against commercial software

I also did a few test with some commercial products, obviously only those which offer free evaluation versions runnable using Wine (Windows emulation layer for Linux). I will not consider here XEphem, which has a commercial version, since the source code of the free version is provided and I mentioned it in the previous section. Among the programs I found SkyMap and CyberSky, but I also tested some images produced using Guide (screenshots taken from its website) and Starry Night (found in Wikipedia). In CyberSky I only tested the triple eclipse in Jupiter in 2004, it was correct but with poor visual quality. Anyway, CyberSky seems nice and easy to use, and also quite fast. On the contrary, SkyMap is very slow. Here are the results of the tests.


In the web page of Guide there are several screenshots of the program. I took two of them to simulate the same phenomena with JPARSEC. Visual quality is clearly below, but accuracy in the positions of the Jupiter satellites is quite good, although it uses the E5 theory by Lieske, supported in JPARSEC but not as accurate as the L1 theory. Upper image shows Io eclipsed by Ganymede, which is also observed in JPARSEC but not exactly in the same way. Probably this is due to a little difference in the value of the TT-UT1 correction, since I simulated the event using both E5 and L1 with identical results. Anyway, the maximum magnitude of the eclipse is 88% according to IMCCE, and this is more compatible with my results. Another eclipse took place 11 hours later as you can see in the mutual events observed by the IMCCE (predictions and observations). The image below shows Mars transiting Jupiter in 1170. Here Guide clearly shows Jupiter without correcting the disk for polar flattening. I tested the same event in SkyMap 11 and obtained the same output as in JPARSEC, but with poor visual quality. JPL DE 406 ephemerides shows a minimum but appreciable difference with the algorithms by Moshier.


Upper image shows a test on Starry Night thanks to an image found at Wikipedia. Again, flattening is not corrected in this program, resulting in an inaccurate simulation. SkyMap gives again the same output as JPARSEC. The second image shows a real observation of Jupiter and a simulation with JPARSEC. You can clearly appreciate the flattening of Jupiter. I selected this observation among the ones I found since I wanted to test the curious alignment of satellites and shadows. After flipping and rotating the image the result is impressive, the satellites are projected in the exact positions respect the clouds in Jupiter, and even the Great Red Spot is exactly where it should be, thanks to the guys tracking its movement.

It is common to see other software packages saying great things about the accuracy of their ephemerides, but without any kind of justification or test, and usually without specifying the algorithms used. I would say the only commercial package I have always trusted in is SkyMap (to reproduce its results to the millisecond is quite easy), but due to competition SkyMap seems dead. Other software packages contains bugs or inaccuracies, and probably are not as well tested as SkyMap or JPARSEC. My conclusion is evident from these tests: JPARSEC is the best implementation of ephemerides ever made, and this conclusing comes from tests against other tools or real observations, it is not a statement on its own. Since the latest algorithms are used in JPARSEC (including, for instance, the precession of Vondrák et al. 2011), the only way to improve it is by using numerical integration theories (I mean, to reproduce the results of JPL ephemerides using numerical integration and extending this to natural satellites). For planets this is a planned feature in JPARSEC, but for satellites it is still far away from my possibilities. There are handy integrations already done at IMCCE, but time span is poor and they require hundreds of MB, so it is not practical to include that in JPARSEC.

Other more deep tests


The images above show more in depth the power of JPARSEC when rendering planetary phenomena. The lunar eclipse shows the increase in the output quality of JPARSEC, using a texture for the Earth shadow taken from Stellarium. In fact, the images of both tools are very similar. In case you change the location from Spain to, let's say, Australia, JPARSEC shows a little difference due to the parallax of the Moon of 1 degree. I cannot see this effect in Stellarium. Next two images show the eclipse/occultation of a jovian satellite by another one (mutual phenomena). The SkyChart component includes an animation feature to modify the sky in different time intervals, allowing to see the sequence of an eclipse very confortably. According to the tests I did the difference with the predictions of the BDL for Jupiter are below 1 minute almost always, and usually below 10s, while for Saturn and Uranus JPARSEC and BDL agree to the second except in rare cases. I still haven't studied this little discrepancy.

The only big feature I would like to add to my planetarium is the ability to show a list of astronomical events and to simulate them. It would be good to have such a list of events and to simulate them just with one clic. I will work on that for the next version of the ephemerides server.

Creating videos from still images

By rendering consecutive images at regular intervals of time and combining them (using, in my case, the free and excellent mencoder tool for Linux users), it is possible to create stunning videos of different planetary phenomena. I have created some test videos of a Lunar eclipse, the triple eclipse in Jupiter in 2004, the rotation of Saturn and the transit of 28 Sgr on it, and so on.

I present here the video for the triple eclipse in Jupiter at 1080p. It is remarkable the effect that produces the shadows of the satellites on the planet, since the different satellites moves at different speeds and the phase angle combined with the projection of the shadows produce a curious effect: the shadows move faster than the clouds on Jupiter sometimes (specially when they appear oblated), and in other cases they move slower. I have not seen this effect so clearly in any other tool or simulation. Looking this video in a high definition TV with 100 Hz feature is fantastic, the quality of the image and the smooth of the animation looks very realistic. In 3d it looks also excellent, but the effect is slightly lost when encoding to x264 codec. Click on the link below the player to see the video. I will eventually add more of them to this location.

Jupiter triple eclipse

Lunar eclipse

The planetary rendering algorithm is now independent from the position of the observer. This means that, in theory, videos can be created for an hipothetical observer located anywhere in the Solar System. One feature for the next version of JPARSEC will be to produce ephemerides and sky/planetary renderings for any point in the Solar System. Another great feature will be to see all this working on Android. Everything is ready for that, but I still don't know if it will be possible to solve the memory issues I observed.


Fernando Margueirat, 2012/09/25 18:49

Impresionantes resultados. Felicitaciones!

Hari Nair, 2013/02/16 20:18

Hi Tomas - this is great work! I am the author of xplanet ( and have also tried to achieve high accuracy. It properly renders eclipse shadows and corrects for light-time. It is written in C++ and is distributed under the GPL. Examples of its use are at

I've often thought of recoding it in Java but now I see you have done a much better job :)


Tomás Alonso Albi, 2013/02/19 09:35

Hi Hari! Sorry I didn't check/find your work when looking for programs for comparison. I have tried to use xplanet, but in my kubuntu 12.04 desktop it is not working properly (or I don't know how to use it, with the examples in your website the program freezes or gives errors about unavailable maps). So far my work has been focused on accuracy and portability, sacrifying slightly the visual quality and performance (not using the GPU) to render things also on Android with the same code. I would like to learn OpenGL to do things more similar to xplanet and obtain such beautiful images, but 3d programming scares me a little and there are too many libraries. My next step is to create a planetarium for Android, maybe i will learn libGDX…

Hari Nair, 2013/02/19 13:30

Hi Tomas - I wrote xplanet as a command line tool and it draws to the root X window. Most window managers cover this up with a fake root window so it's probably working; you just can't see the output! I'm using it on Ubuntu 12.04. You can use the -window option to draw to an X window, and the -verbosity option will add some diagnostic output. The -print_ephemeris option will dump the heliocentric equatorial positions in the J2000 frame of all of the planets and satellites in the code.


Tomás Alonso Albi, 2013/02/19 19:08

Thanks Hari! With the -window option now I can see everything! I have tested all renderings in this post with xplanet, and the results are extremely similar. It is not easy to obtain such level of accuracy in the position of natural satellites and shadows. I'll have a look into your code when possible to see your approach with more detail. Here are the list of xplanet commands I've used:

xplanet -light_time -origin earth -body jupiter -radius 45 -north orbit -date 20040328.080230 -utclabel -labelpos +0+0 -window

xplanet -light_time -origin earth -body saturn -radius 45 -north orbit -date 20090224.120900 -utclabel -labelpos +0+0 -window

xplanet -light_time -origin earth -body Jupiter -radius 45 -north orbit -date 19971111.043600 -utclabel -labelpos +0+0 -window

xplanet -light_time -origin earth -body Jupiter -radius 45 -north orbit -date 11700912.203000 -utclabel -labelpos +0+0 -window

xplanet -light_time -origin earth -body Jupiter -radius 45 -north orbit -date 20090820.005800 -utclabel -labelpos +0+0 -window

xplanet -light_time -origin earth -body Moon -radius 35 -north orbit -date 20110615.190000 -utclabel -labelpos +0+0 -window

xplanet -light_time -origin earth -body Europa -radius 35 -north orbit -date 20090602.015000 -utclabel -labelpos +0+0 -window

xplanet -light_time -origin earth -body Io -radius 25 -north orbit -date 20090521.053100 -utclabel -labelpos +0+0 -window

Hari Nair, 2013/02/19 20:54

I'm glad you got it to work! Xplanet can read the JPL digital ephemeris files using the -ephemeris option. Otherwise it will use an internal lower precision ephemeris.


Enter your comment
  __  __     __  _____   ___    ___ 
 / / / / __ / / / ___/  / _ \  / _ |
/ /_/ / / // / / (_ /  / // / / __ |
\____/  \___/  \___/  /____/ /_/ |_|
blog/advanced_planetary_rendering.txt · created: 2012/06/26 17:23 (Last modified 2020/12/14 18:30) by Tomás Alonso Albi
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki