It’s been a couple weeks since I released the “Living Mars” images, which took on a life of their own which I never expected. I expected maybe a few +1s or “likes”, but for it to go viral was amazing. I was sincerely humbled by the way the images were described by most of the articles, reshares, tweets, etc. A lot of the comments were very constructive, allowing me to learn a lot about what it takes for a planet to harbor an atmosphere, ocean, or even life.
Since then, I’ve continued to make changes to the rendering software I created, jDem846 (Java Digital Elevation Modeler then my son’s date of birth, or just “jDem” for short). Doing the Mars image project in jDem gave me some good insight into changes that I needed to make, primarily when it came to my own nitpicking of the images themselves, limitations of the software, and optimizations that I would need to make if I wanted to do anything better than “Living Mars”. These are ongoing efforts that I make whenever I have some free time (which is not very often, I do have a full time job and a family!), so changes are coming slowly.
Some of the changes I’ve made so far:
- Graphics Hardware Acceleration with OpenGL
Up until now, jDem had it’s own 3D rendering framework, if only for the personal challenge of writing one. The algorithms were largely based on the Mesa OpenGL implementation, with some tweaks here and there, mainly to specialize it to the modeling the program is intended for and for my own attempts at reinventing color and depth buffers.
However, I have just integrated OpenGL rendering using the JOGL library for Java. This has a couple of benefits:
- I don’t have to maintain it. Though I do plan to keep the software rendering implementation in there as an option/fallback if OpenGL is unavailable on a particular system.
- It’s considerably faster.
- It yields better results. My renderer was ok, but it did have it’s limitations. OpenGL gives me more accuracy, smoothing, blending, and the whole API when writing in some eye candy via model scripting.
- Memory Footprint Reduction with Mapped Memory Buffer Files
jDem has had, up to now, a massive memory requirement. This is in part to Java’s memory/GC overhead, but was mainly due to the softwares original design. Originally (back when it was my final Master’s Degree project at Rivier College) it was designed to render only smaller, city-sized models. Any of the data obtained from the USGS for those models could easily be held in active memory and allow fast data processing. I mediated it for a while with some caching tricks, but overall, the application needed vast quantities of memory. For example, I configured the JVM with thirteen gigabytes of memory when I rendered the Living Mars images.
In an effort to greatly reduce the memory footprint, I implemented the use of Java’s memory mapped buffers. This allows me to put all the buffers that had been in active memory into temporary files on disk. Now, this does add plenty of additional overhead, and actually eliminates most of the time savings that had been gained with OpenGL rendering (fortunately, I just installed a solid state drive in the PC I’m doing all this work on). I do plan to do additional work to move back towards a happy medium between heap resident buffers or the mmap’d buffers, which should speed things up a bit, but that’s in the future when I complete the buffers framework.
An example of this working is the attached image, originally rendered at a resolution of 8000×8000 pixels. Before the mmap’d file buffers were added, the JVM needed more memory than my system actually has (16GB), thus couldn’t been done at this high a resolution. As it is, the model is rendered in a two-step process, first as a flat texture (which for the attached image was 40115×40769 at 80% quality) Now, that rendered with the JVM using less than 700MB. Better? The buffer files were enormous, but that’s ok, there’s a lot more room on the disk than an active memory, especially if you run the program on a 32bit PC.