Here are some pictures of the moon.

This is the island of Jura, looking north. (Normally visible on the
north-west limb of the near side of the moon.) It's about 600km long,
making it about two-thirds the size of the British Isles.

This is a copy of a rendering I did a couple of years ago, but the main
interesting thing here is that rather than using a massive mesh for the
terrain, it's using the plugin code I posted to .general the other day
to read the data directly out of NASA PDS files (a 6GB data set!). There
should be some procedural noise overlayed on top, so it gets a bit bland
when you get up close, but it's working really well.

However, as you can see, I suck at media; the sky is dire. Last time I
made it work by brute force and ignorance, just increasing the samples
to about 30 and living with achingly long rendering times. I want to do
better this time.

(The weird stripe is an artifact of the *sky*, not the terrain. I assume
it's a sampling glitch of some kind. No idea what's going on there. To
prove it, I enclose another picture with the sky turned off, and you can
see the ocean is fine.)

My sky media is:

  media {
    method 2
    ratio 1
    samples 10
    scattering {
      RAYLEIGH_SCATTERING
      color 2.3 * Rayleigh_Colour / Atmospheric_Scale
      extinction 1
    }
    density {
      function { Rayleigh_Density_Function(x, y, z).x }
    }
  }

The density function calculates atmospheric density with altitude.

Any suggestions?

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
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 'newmoon.jpg' (54 KB) Download 'newmoon.nosky.jpg' (93 KB)

Preview of image 'newmoon.jpg'

Preview of image 'newmoon.nosky.jpg'

Am 01.10.2015 um 00:12 schrieb David Given:
> Here are some pictures of the moon.
...
> However, as you can see, I suck at media; the sky is dire. Last time I
> made it work by brute force and ignorance, just increasing the samples
> to about 30 and living with achingly long rendering times. I want to do
> better this time.
> 
> (The weird stripe is an artifact of the *sky*, not the terrain. I assume
> it's a sampling glitch of some kind. No idea what's going on there. To
> prove it, I enclose another picture with the sky turned off, and you can
> see the ocean is fine.)
...

Uh... wait - sky? ocean?

We are talking about the moon, as in, /our/ moon, right?


As for the media, for starters be advised that sampling method 2 is
generally considered the worst of all choices; depending on what you
want to achieve, you're typically better off with either method 1 or 3.
Also, when using method 3, make sure to use its adaptive sampling
feature, using "samples MIN,MAX" with low min and high max, and tweaking
aa_level and aa_threshold to your taste.

Now for the main course, the artifacts: The bad news is that whenever
your density function is non-linear, contrary to intuition you will
/always/ get banding artifacts as long as you aim for a smooth result.
You can crank up the number of samples like mad, but you will never get
rid of them entirely, and our perceptual system is very sensitive to
this type of artifacts.


The first step to solving the problem is to throw the goal of smoothness
overboard, and replace the banding artifacts with noise artifacts; even
if the total error between the ideal image and the actual output remains
the same, our eyes are much more forgiving if they can't find any
pattern in the artifacts.

Introducing noise to the sampling process can be achieved in a number of
ways; you probably only want one of them:

- Add a random element to the density function; for instance, multiply
with a function that gives a value between, say, 0.9 to 1.1, based on a
very small-scale granite pattern. Drawback: This does not play nicely
with adaptive sampling method 3.

- Use sampling method 1 with "intervals 1"; this always gives you an
entirely random distribution of media samples. Drawback: This is also
the slowest method.

- Use sampling method 3 with "intervals 1" and jitter (you may want to
be bold and try "jitter 1.0"); this will vary the distance between
sample points.


Now that you have converted your artifacts to noise, it is time to
reduce its amplitude by throwing more computing power at it; again, you
have several options:

- Possibly the easiest, grab a copy of UberPOV and use anti-aliasing
mode 3 ("+am3"); reduce the threshold parameter ("+a") if you think you
have too much noise overall; increase the confidence parameter ("+ac")
if you think you have too many stray speckles; increase the recursion
depth parameter ("+r", not actually recursion depth in mode 3, but still
governing maximum number of samples) if your results remain poor in some
regions, or reduce it if you think POV-Ray is spending an inacceptable
lot of time on some regions.

- Use standard POV-Ray with a little bit of focal blur; the effect is
about the same as UberPOV's anti-aliasing mode 3, with "variance" and
"confidence" settings taking the role of the +a and +ac parameters,
respectively. (UberPOV's "+am3" might be superior at avoiding stray
speckles though.)

- If you're using media sampling method 1, increasing the "samples"
parameter will throw more computing power directly at reducing the
noise, albeit in a less selective fashion.

- If you're using media sampling method 3, and using "jitter" to
generate the noise, possibly the most efficient way of throwing
computing power at the problem is to reduce "aa_threshold" and possibly
increase "aa_level".

Post a reply to this message

Am 01.10.2015 um 10:08 schrieb clipka:

> Now for the main course, the artifacts: The bad news is that whenever
> your density function is non-linear, contrary to intuition you will
> /always/ get banding artifacts as long as you aim for a smooth result.
> You can crank up the number of samples like mad, but you will never get
> rid of them entirely, and our perceptual system is very sensitive to
> this type of artifacts.

(As a side note, colour banding might even remain a problem if POV-Ray
could compute the media perfectly. In that case, banding would occur due
to colour aliasing in the output image generation. Again such artifacts
can only be avoided by replacing them with a tiny bit of noise, known as
dithering in this context.)

Post a reply to this message

Hi(gh)!

On 01.10.2015 00:12, David Given wrote:
> Here are some pictures of the moon.
>
> This is the island of Jura, looking north. (Normally visible on the
> north-west limb of the near side of the moon.) It's about 600km long,
> making it about two-thirds the size of the British Isles.

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!

> This is a copy of a rendering I did a couple of years ago, but the main
> interesting thing here is that rather than using a massive mesh for the
> terrain, it's using the plugin code I posted to .general the other day
> to read the data directly out of NASA PDS files (a 6GB data set!).

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?

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...

See you in Khyberspace!

Yadgar

Post a reply to this message

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'

On 01/10/15 10:08, clipka wrote:
[...]
> Uh... wait - sky? ocean?
> 
> We are talking about the moon, as in, /our/ moon, right?

Oh, absolutely.

I enclose three more pictures; this is the same scene, taken from about
25km up, in twilight, dawn and daylight, respectively. They took a
drastically different amount of time to render; the daylight one was 235
seconds, while the dusk one was 1320.

These use these settings:

	method 3
	jitter 0.1
	ratio 1
	samples 3, 30

The jitter has helped with the banding, at the expense of some noise.
(The dark shadow in the dawn picture should be there; it's the planet's
shadow cast through the atmosphere. But it shouldn't be that grainy.)

Interestingly, in the dawn picture, it's the *sea* that's the expensive
bit --- presumably because of tangential rays from the sun (off to the
right). In the dusk picture, it's the atmosphere. In the daylight
picture, they're both cheap.

Unfortunately, UberPOV is largely out of the question, because I'm using
a custom patched POV anyway. (The DLL code.) So I'm going to have to
start playing with aa_level and aa_threshold, right? Although I hadn't
thought of fiddling with focal blur. I'll have to try that.

I know I can get good results by cranking up the power --- but I want to
do it *efficiently*, because my renders are slow enough as it is.
Imagine what it's going to be like after I drop a million trees onto the
landscape!

(Both the terrain and the ocean are isosurfaces, their shape controlled
by data provided by a DLL. Did you know the moon's gravitation field is
lumpy? The lunar ocean varies in height by about a kilometre.)

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
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 'newmoon.dawn.715.jpg' (76 KB) Download 'newmoon.daylight.235.jpg' (98 KB) Download 'newmoon.dusk.1320.jpg' (58 KB)

Preview of image 'newmoon.dawn.715.jpg'

Preview of image 'newmoon.daylight.235.jpg'

Preview of image 'newmoon.dusk.1320.jpg'

...incidentally, the weird stripe in the first image was, AFAICT, cause
by the bottom of the atmosphere brushing against the top of the sea.
Lowering the atmosphere a little made it go away. Very strange.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
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

Hi(gh)!

On 02.10.2015 01:06, David Given wrote:

> (Both the terrain and the ocean are isosurfaces, their shape controlled
> by data provided by a DLL. Did you know the moon's gravitation field is
> lumpy?

Yes, because of this lunar orbits cannot maintain a stable orbit for 
longer than a few months...

See you in Khyberspace!

Yadgar

Now playing: Genevieve (Jon & Vangelis)

Post a reply to this message

Am 02.10.2015 um 01:06 schrieb David Given:

>> Uh... wait - sky? ocean?
>>
>> We are talking about the moon, as in, /our/ moon, right?
> 
> Oh, absolutely.

Hm... maybe you'd be faster off rendering it in a realistic fashion then ;)

JK.

> The jitter has helped with the banding, at the expense of some noise.
> (The dark shadow in the dawn picture should be there; it's the planet's
> shadow cast through the atmosphere. But it shouldn't be that grainy.)

Here's where one of the drawbacks of method 3 surfaces: You have to
specify an absolute threshold, but in dark regions our eyes are more
sensitive to absolute differences. So to reduce the noise there, you
also have to throw more computing power at the brighter regions where
it's not really necessary.

IIRC adaptive focal blur is based on the relative error, so that might
be a more efficient way of getting more oversampling in the darker regions.

> Unfortunately, UberPOV is largely out of the question, because I'm using
> a custom patched POV anyway. (The DLL code.)

Sounds like it's time I got me a fresh batch of round tuits and
integrated the most recent POV-Ray changes into UberPOV. I presume that
would allow you to integrate your custom patch into UberPOV as well.

> So I'm going to have to
> start playing with aa_level and aa_threshold, right? Although I hadn't
> thought of fiddling with focal blur. I'll have to try that.

The focal blur algorithm includes the best general adaptive oversampling
mechanism that is available in official POV-Ray 3.7, so the idea is to
introduce a /tiny/ bit of focal blur, in order to make that mechanism
kick in.

> Did you know the moon's gravitation field is
> lumpy? The lunar ocean varies in height by about a kilometre.)

Well, I'm quite the "lunatic", but here's a fact that's news even to me.

Another reason to not flood the moon: You never know where the
shorelines will be ;)

Did you also factor in the gravitational pull from earth? That must be
"quite an attraction", and may even cause noticeable monthly tides -
despite the moon being tidally locked to the earth - due to libration as
well as variation in the distance to earth.

Then again, thinking about it, those tides must "drown" in immense
semi-monthly tides rolling around the moon due to the sun's
gravitational pull, given how low the moon's own gravitation is.

Post a reply to this message

Am 01.10.2015 um 21:05 schrieb David Given:

> 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.

I suspect you're wrong about the performance (presuming you'd use a
custom patch to get the data into POV-Ray either way); there's a reason
why people tend to convert isosurfaces to height fields or meshes before
use.

But you're probably right that using an isosurface should make it a
piece of cake to bolt on procedurally generated surface detail. With
meshes you'd be stuck with bump maps.

Post a reply to this message