On 01/10/15 17:11, Jörg 'Yadgar' Bleimann wrote:
[...]
> According to what I know about Moon nomenclature, this region is named
> after the Jura mountains in France and Switzerland, not after the
> Scottish island... and you're not looking north, but rather north-east,
> with Sinus Iridum (the large half-circular feature) to the right!

It is *actually* looking north --- I know because the bearing setting in
the code is 0. The perspective is deceptive. Yes, that's the Bay of
Rainbows. The Chang'e 3 lander is somewhere underwater out there. The
big crater lake is Mairan, and is about 40km across.

Here it is in real life: http://www.moon.com.co/atlas/sections/b2.shtml

In the foreground you can see the twin mounds of Mount Gruithuisen,
facing each other across the strait. They're about a kilometre high.

> This is VERY interesting... how much RAM did the calculation of the
> mesh2 object (I suppose it is a mesh2 rather than a classical mesh -
> otherwise parsing would have taken almost forever) use? How many
> elevation points (i. e. vertices) did you use?

*facepalm* I forgot to mention the core feature here: the terrain is an
isosurface. So there are no polygons.

The last time I tried this was a couple of years ago, using a bespoke
tool to generate a LOD-optimised mesh based on the camera position
(using ROAM). It worked really well, but was very slow, mostly due to
I/O. Loading a 15 million mesh into Povray is a bit painful. I also have
a very neat piece of code called Propmaster that populates the terrain
with trees. The algorithm may even be novel!

See: http://cowlark.com/flooded-moon

(Sorry about the poor layout, it needs a rework.)

I enclose a couple of test renders of the mesh generation in action. You
can see that the amount of detail goes up around places that need it,
and the closer they are to the camera.

However, using an isosurface is, I believe, faster, and also means fewer
moving parts to go wrong. Once I bolt on the procedural detail and start
rendering the closeups we'll see how well it really works.

> About two years ago I tried the same with ASTER Earth elevation data
> tiles (https://www.youtube.com/watch?v=R5pCZdj_VGM)... and had to limit
> the used elevation measuring points from the original 3601 x 3601 down
> to 2600 x 2600, as otherwise it would not have been possible with "only"
> 16 GiB of RAM...

Yeah, you totally need to change your level of detail with distance, I'm
afraid. Trying to keep a high-resolution mesh in memory is going to eat RAM.

You're welcome to give my code a try, if you like --- it should do
mostly what you want. But it's, hmm, not terribly well documented.
You'll need to find the elevation data in PDS files containing radius
from the centre, but you don't need coverage of the entire globe. It's
all at the above site.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There is nothing in the world so dangerous --- and I mean *nothing*
│ --- as a children's story that happens to be true." --- Master Li Kao,
│ _The Bridge of Birds_

Post a reply to this message

Attachments:
Download '716670282.jpg' (56 KB) Download '717660611.jpg' (94 KB)

Preview of image '716670282.jpg'

Preview of image '717660611.jpg'