I'm trying to render the moon, to scale. The USGS provide a detailed
topographic map of the moon in the form of about 270000 points in the
form of latitude, longitude and radius tuples. Are there any cunning
tricks I can use that will help me render this?

Right now I've got a little program that will convert it to xyz tuples,
and then I run the result through tetgen to produce a quad mesh, and
then I run it through yet another little program to produce a Povray
mesh2 object. The results are rather unsatisfactory --- it's slow (the
file takes about a minute just to parse!), some of the polygons don't
meet exactly at the edges, and the crude conversion I'm doing from quads
to triangles isn't helping with the shading.

I would think that it should be possible to use a parametric surface for
this, but I'd need a way to somehow get it to interpolate between the
data points in the topographic model --- any suggestions?

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│
│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver

Post a reply to this message

David Given wrote:

> I'm trying to render the moon, to scale. The USGS provide a detailed
> topographic map of the moon in the form of about 270000 points in the
> form of latitude, longitude and radius tuples. Are there any cunning
> tricks I can use that will help me render this?

one way to combine the data into a more managable format would
be to "paint" the radius values into an image at the coordinates
given by latitude and longitude, in effect defining a height
field in spherical coordinates.

Although spherical height_fields are not directly supported
you can load the the data as an image_map pigment with spherical
mapping and define a pigment function based on it.

You could then either render it as an isosurface or derive
a mesh from the pigment function in SDL. For the isosurface
method have a look at the second example on

   http://www.econym.demon.co.uk/isotut/pigment.htm

where you would replace F with your height function.

Alternatively, you could also try a simple blob with
270000 components. But parsing will be even slower than
with the mesh2 approach then.

Post a reply to this message

On 02/01/10 20:52, Christian Froeschlin wrote:
[...]
> Although spherical height_fields are not directly supported
> you can load the the data as an image_map pigment with spherical
> mapping and define a pigment function based on it.

Yes, I'm experimenting with that approach. It takes an age to render,
alas, and I'm getting lots of peculiar noise where the rays of light
from the light source are at a tangent to the surface --- even with a
simple sphere. I'm still tuning, though.

> http://www.econym.demon.co.uk/isotut/pigment.htm

Thanks, that's better than the example I'm looking at now.

[...]
> Alternatively, you could also try a simple blob with
> 270000 components. But parsing will be even slower than
> with the mesh2 approach then.

Interesting you should mention that --- another object I'm going to want
to render is the lunar geoid, represented as a 90-degree spherical
harmonic model. As I understand very few of those words I'm probably
going to end up with another spherical heightmap based on Clementine
data, but it would be rather nice to be able to render the model
directly. I wonder if the blob approach might help there...

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│
│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver

Post a reply to this message