I occasionally search for Stellarium in Google when I’m bored. It’s a good way to find out what good (or bad) things software reviewers are saying about Stellarium (and sometimes about me). It’s also a good way to catch bugs that haven’t been reported to Stellarium’s bug tracker.
Some of the stuff I come upon during these vanity searches is rather amusing, though. A recent example is a series of videos on YouTube that convinced me that I need to explain how Stellarium handles comets and asteroids and how the Solar System Editor plug-in works. I’m going to discuss the videos themselves after the explanation.
All of this applies to Stellarium 0.11.0, released in July 2011. Some parts of the description may no longer apply to future versions.
First, let’s make something extremely clear. Stellarium is a simulation. It is based on mathematical modelling. It can’t display an object that is not in its databases, and its databases don’t contain all objects that exist or even all that are known. This applies to stars, Solar System objects, nebulae, satellites, etc.
Stellarium’s database of Solar System objects is kept in the ssystem.ini file. It’s a plain text file, so you can open it with something like Notepad++ and look at what data Stellarium is using for a given object. (You may have two copies. The one in your user directory overrides the one in Stellarium’s installation directory.) Indeed, before the introduction of the Solar System Editor plug-in, manually editing that file was the only way to add Solar System objects to Stellarium.
All Solar System objects can be rendered in two ways – as star-like objects with a fuzzy halo and as spheroids wrapped in a texture (an image showing the surface of the body). How a particular body is rendered in any given moment depends on its size and the current FOV/zoom/magnification – when the view is “zoomed out” enough, the object is rendered as a star.
When Solar System objects are rendered as star-like objects (fuzzy blobs), they are treated as stars – their apparent size reflects their current brightness (i.e. apparent magnitude), not the size of the body itself. The size of the fuzzy blobs can be manipulated using the “Absolute scale” and “Relative scale” parameters in the “Sky” tab of the “Sky and viewing options” window.
Stellarium doesn’t render comets realistically – it can’t display they tail and coma. Instead, they look just like the other Solar System objects – star-like if you are zoomed out, textured balls when you zoom in enough. Realistic rendering of comets has been on the wishlist for quite some time now, but no willing OpenGL programmer has stepped forward to do something about it.
The situation is the same with asteroids – they are rendered as balls, instead of irregular lumps.
When you import new bodies with the Solar System Editor plug-in, you pull the information from the website of the Minor Planet Center. They maintain both prepared lists of interesting objects and a search engine, hence the two tabs in the “Import data” window – “Lists” and “Online search”. In both cases, the provided information contains only the object name and/or designation, its current orbital elements and data for predicting its brightness.
All comets and asteroids imported via the Solar System Editor plug-in use the same surface texture – nomap.png. (It is also used with some of Stellarium’s default Solar System bodies when there’s no available surface map of the body, for example for some of the gas giants’ satellites.)
All comets imported via the plug-in get the same radius – 5 km (see lines 518 and 969 in SolarSystemEditor.cpp).
All asteroids imported via the plug-in have their approximate size calculated from their absolute magnitude with an assumed albedo of 0.15 (see line 737 in SolarSystemEditor.cpp).
For both asteroids and comets imported with the plug-in, the apparent magnitude (brightness) is calculated using simplistic two-parameter models that provide only a crude approximation. Despite the fact that both use “absolute magnitude” and “slope parameter” as parameters, apparent magnitude is calculated in different ways for comets and asteroids.
There are also a few known bugs:
- Sometimes, when zooming in on a comet or asteroid, both the 3D textured spheroid and the star-like fuzzy blob are visible at the same time, and the star texture is “dancing around” the “solid” spheroid.
- There is a bug where the value of the epoch of the mean anomaly is off by 0.5 Julian Days, due to faulty parsing of the Julian date value (see bug #836839 in Launchpad). As a result, the orbital elements of bodies imported with the Solar System Editor plug-in are a bit wrong, leading to a slight error in predicted positions. (Adding to the error already introduced by the low precision of the source data, the fact that it uses a fixed epoch that is often not the desired moment and the general inexactness in Stellarium’s comet orbit model.)
All of this should probably go to the Solar System Editor’s page in the Stellarium Wiki when I finally get around to writing it.
The reason for writing all of this is a rather funny series of videos that I found on YouTube yesterday. All of them have been created by a user called J7409 and concern “Comet Elenin”, a comet that has become the center of some rather daft conspiracy theories. (See the article on Comet Elenin in RationalWiki for examples. Or read the readers’ comments on Leonid Elenin’s blog.)
So, I first came upon the “Pictures of Elenin from Nasa Skyview 9-24-11” video, because it contained “stellarium” in its description. My reactions were something like this:
Oh my, another one that thinks that NASA’s SkyView is real-time… (It’s not, it shows images from various surveys created at various points in the past.) Wait, what? Did he just try to measure the comet’s coma by measuring the halo texture in Stellarium? And its “core” by measuring the fictitious spheroid model? Ouch! 
Looking through the rest of his videos, it seems that he’s been doing it since August (“Elenin Coma and Nuclie Pics Today Thru Oct 16th On Stelluirum Watch How It Gets BIGGER!”). For the record: the “coma” is actually the star texture. Its size reflects only the current brightness of the object. It’s “growing”, because comets becomes brighter the closer they come to the Sun (at least in the simplistic comet brightness model that Stellarium is using). The “nucleus” is actually the default rendering of a Solar System object, with a fictitious radius of 5 km, because the data pulled from the Minor Planet Center’s website doesn’t contain information about its size or its surface features.
Further digging found more fun videos by the same user. In “Elenin Bringing Friends? Maybe? Might Not Be Elenin We Should Be Looking At.” he shows Stellarium screenshots of the comet surrounded by background stars inside the ocular simulation of the Oculars plug-in, and implies that this is some kind of “cluster” surrounding the comet. (I tried to post a comment to that one and it still hasn’t been approved.) But the record for amusingly wrong statements is held by “Elenin WHY Over 2,000 Observations made and only a Few Used, If Its A Whimpy COMET???”:
- J7409 notices a bug in Stellarium’s rendering of the comet’s trail. (Kudos for that, I haven’t noticed it.) His assumption? Something is pulling the comet back! *facepalm*
- According to him, the pixelated orbit line in the orbit visualization applet on the comet’s page in the JPL Small-Body Database browser is evidence for the same. *facepalm* Does he really think that this simple Java applet is some kind of ultra-precise astronomical simulation?
- He is astonished by the number of observations used to determine the orbit and assumes that they are done by NASA. (This is a common claim in Comet Elenin conspiracy theories.) The observations are actually done by amateur astronomers from all over the world and submitted to the Minor Planet Center. JPL gets them from there, and you can get them too from Comet Elenin’s entry in the MPC Database.
- After that he misreads the Physical Parameters Table to claim that only 353 of those observations “have been used”. Helloooo? I can haz reading comprehension? First, it’s a separate table from the “Orbit Determination Parameters” box where the 2218 observation is mentioned, and the “353″ figure clearly applies to the row – “comet total magnitude”. (Apparently not all observations contain an estimation of the magnitude, some are just coordinates.) J7409 also ignores that the “from 1786 observations” line two rows below (which applies to “comet nuclear magnitude”).
I am really curious about J7409′s thought process about all of this. Does he realize that Stellarium is a simulation? Where does he think it gets its data? Given the “cluster” and the “orbital pull”, it seems that on some level, there’s the assumption that Stellarium can suck information directly from the fabric of the Universe.
(And I just wrote more than a thousand words mocking some random YouTube teenager. I need to get a life. Though given the amount of crap citing Stellarium in YouTube and elsewhere, I can turn “you are using it wrong” into a regular feature of this blog.)
Of course, one of the reasons is that I’m working on a netbook and operations such as compilation, version control and code comparison are slow. I also had to study other people’s code and re-factor some of it. Nevertheless… It’s still ten hours of my life that I’m not getting back.
I’m going to leave the implementation to someone else, though. I’ve had enough of Stellarium for now.
