The thing that most annoyed me at the time was there wasn't a good open source JPEG2000 decoder I could use to slice up the imagery to go along with the DEMs. But that must have changed by now...
I don't know if many existing ray tracers, but if you want to build one give me a shout. Rendering spheres with height maps and volumetric covering is am evening or weekend project from scratch once you know what you doing :)
Rendering the planets themselves was simple enough once I figured out how raymarching worked, but once I started adding volumetric atmospheres with scattering (needed to make clouds and their shadows work), it got complex. Coming up with the optimal arrangement of atmospheric samples and how many subrays to cast got very complex very quickly and while I could make it work, it was never very satisfactory and Povray, with its years of optimisation, was vastly faster.
...although I see now that Mitsuba has had a new release. Hmm.
Wow. It's so... special.
That said, even though the format is clunky and horrible, it genuinely is self-documenting. I managed to parse it in a surprisingly small amount of code without needing to refer to the documentation at all (which is good because I couldn't find any). Some datasets needed special treatment because the value that came out of the formula specified in the PDS label needed to be offset to produce a physically valid value. But it all worked. They're even mmap friendly. So, ancient and loathesome yes, but also pragmatic and effective yes.
The C++ parsing code, if anyone cares, is at https://github.com/davidgiven/flooded-moon/tree/trunk/terrai... in the pds.h and pdslabel.h files.
Incidentally, if anyone knows of:
(a) a raytracer with volumetric rendering that has a programmatic API (right now I'm using a hacked version of Povray) (b) higher-resolution terrain data of the moon than the 6GB Lunar Reconnaissance Orbiter DEMs available here: http://wms.lroc.asu.edu/lroc/view_rdr/WAC_GLD100
...please let me know?