Lunar DTM100 to Blender displacment map

This post is an aggregration of multiple threads created on google plus and additional findings, the scattered nature of those threads made it impossible to find all the information in one place hence this post.   It's also a work in progress with some blank spots- help is welcome!

(I've mostly moved to google plus which is great for mini-blogging (as opposed to the micro blogging of twitter and full size regular blogger blogging) and has very good engagement once you find good people to put in your circles.  I expect greater plus/blogger integration in the future probably starting with comments becoming plusified.)

From LROC Lunar Map

Lunar Elevation Data

Source DTM files are in the IMG files:


The highest resolution maps are in the 100M.IMG files, which means 100 meters/pixel (which seems large for an object so close as the moon- why don't we have 1 meter per pixel, or 0.1 meter yet?).

I haven't written a script for handling the files that don't completely cover the lunar globe, and will probably use other tools to get that right.  (grass gis http://grass.fbk.eu/gdp/index.php?)

TBD detail on file format.

Generating 32-bit elevation tifs with Python

Conversion to viewable

Not a lot of programs can display those 32-bit tifs correctly, and Blender didn't like them.  Get a version of imagemagick with hdri enabled (./configure --enable-hdri when building it from source) so they can be converted to friendlier formats.

Making an easier to view jpg from the 32-bit tifs:

convert -define quantum:scale=255.0 -normalize moon.tif moon_fromtif.jpg

And the following is the result:
From LROC Lunar Map

The jpeg is usable in Blender but doesn't hold up well with a lot of zooming- the 255 levels of elevation possible in a jpeg produce stair step artifacts:
From LROC Lunar Map

Conversion to blender usable

So Blender could use a 16-bit format like openexr for 255x smoother gradations, use this conversion:

convert -define quantum:scale=255.0 moon.tif moon.exr

The quantum scale there seems like it ought to be 65535.0 but the 255.0 works, and imagemagick identify -verbose shows that the range of values is 65535.0.

Setting up image based displacement + bump in Blender 2.6x Cycles (latest svn)

TBD flesh this out in greater detail

Add | Mesh | UV sphere

Object Modifies | Add Modifier | Subdivision Surface | Render 6

Material | Surface | Use Nodes

Shift-A | Texture | Image Texture | Open moon.exr

Connect the color to the diffuse bsdf, then should see texture on sphere if in texture or render view mode (maybe have to do something to force redraw/update).

Edit Mode | Select all edges

Mesh | UV Unwrap | Sphere projection | Align to object

Connect image texture to color to bw converter and then to displacement input on material output.  TBD proper height scaling of craters.

Object Data | Displacement | Method | Both

Link to .blend file:


From LROC Lunar Map

UV Sphere Projection Polar Problems

The UV spheres generated by blender have the problem of having triangles instead of quads around the poles.  The spherical projection will produce distortion at the poles, smoothing the sphere prior to uv unwrap helps minimize it.  I wonder if there is something problematic about making the pole polygons quads because it would involve multiple polygon points and edges right on top of each other.

You can see the problem areas in the uv image below- the nice quad projections become distorted triangles at the top and bottom.

The result is these pinched areas:

Lunar Visual Mosaics

The moon isn't perfectly grey, there are many interesting light and dark features.  I haven't located a good texture generated from LROC or Clementine data (LROC would be ideal since it would probably guarantee all visual features line up with elevation features).



There are some random ones to be found on the web but I haven't tried them yet.


Grass gis http://grass.fbk.eu/gdp

gdal - has python bindings    (ubuntu intall python-gdal gdal-bin)  http://www.gdal.org/
Turn python generated tiff images into geotiffs

osgearth - uses geotiff output from gdal to produce lod/paged terrain databases viewable in OpenSceneGraph osgviewer.

Use 100M data (the 256P IMG files).  Parse dtm within python to do this?  Minimum is extracting width x height.


Original discussions that originated this post:


Google Docs Storage

I've been playing with google docs storage for about a month. The user interface is inferior to Amazon S3 + S3Fox in every way, but for 1/5th the cost I'm willing to put up with it (though it's only 1/5th the cost if I fill up all the storage for the given price tier, I think they expect most users not to use a large fraction). AVIs and JPEGs can be dragged-and-dropped in quantity, but NEF and .ini files have to use the 'select more pictures' dialog which can only handle 10-15 files at a time (otherwise a strange character appears instead of a list of all the files). Upload speeds seem good (a megabyte every 3 seconds or so), better than I remember S3 being last time I tried it.

There are some linux filesystem programs that can mount my entire google online storage (including blog posts), but only allow uploading of the google docs formats and not any file at all like can be done with the upload dialog. Hopefully this changes.

5/8/2011 update

Folder upload is now possible (no more shift selecting the contents of a folder and having to cut and paste folder names), and it looks like subfolders are uploaded properly. But sometimes a file fails to upload properly, and using the file method it was possible to see which file failed and re-queue for upload. Now after I've uploaded a folder with 90 items and it took 20 minutes, there is an error message saying that one file failed to upload, but no way to know which one. Retry fails repeatedly. Some reports of same, though I haven't seen the other bugs mentioned.