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

On 02/10/15 22:20, clipka wrote:
[...]
> 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.

I'm actually having a great deal of difficulty getting the surface to
render cleanly after bolting on procedural noise; it goes all fuzzy
close up, which implies my isosurface doesn't have a well-defined
surface. (Enclosed.) I would suspect my multifractal routine, but it's
stolen from libnoise, and so should work...

So I'll stop fiddling with it and go back my old mesh code. Instead of
writing out a text file and loading into Povray I'll see if I can hack
in a dll-based callback interface, so my code can feed polygons directly
into Povray. That should be way faster.

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

Preview of image 'newmoon.fuzzy.jpg'

Am 02.10.2015 um 22:54 schrieb David Given:

> I'm actually having a great deal of difficulty getting the surface to
> render cleanly after bolting on procedural noise; it goes all fuzzy
> close up, which implies my isosurface doesn't have a well-defined
> surface. (Enclosed.) I would suspect my multifractal routine, but it's
> stolen from libnoise, and so should work...

To me it looks fine, except that you're doing it wrong.

It looks to me like you're just perturbing your terrain function, using
something like:

    f(x,y,z) = f_terrain(f_noise(x,y,z))

when what you actually want is more like:

    f(x,y,z) = f_terrain(x,y,z)+f_detail(x,y,z)*detail_amplitude

Also note that if you just plug in some generic noise function as
f_detail, you are prone to turn your isosurface into some foam or "swiss
cheese", when all you really want is a radial offset of the surface; you
probably don't want caves, nor even overhangs.

To avoid this problem, you need to make sure that f_detail(x,y,z) is
constant along any ray from the center outward; you can achieve this by
defining f_detail as follows:

    f_detail(x,y,z) = f_detail_(x,y,z,sqrt(x*x,y*y,z*z))
    f_detail_(x,y,z,l) = f_noise(x/l,y/l,z/l)

Also, my personal suggestion is to not hard-code this into your DLL, but
rather define the detail function in POV-Ray, making use of POV-Ray's
pigment function feature and one or more of POV-Ray's noise-based
patterns (such as "bumps").

Post a reply to this message

On 2-10-2015 22:04, clipka wrote:
> Am 02.10.2015 um 01:06 schrieb David Given:
>
>> 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.
>

This is also true for our own Earth in fact. Local variations of the 
gravitational field make the oceans' surface vary by several (tens of) 
meters, sometimes over quite short distances.

-- 
Thomas

Post a reply to this message

Am 03.10.2015 um 09:08 schrieb Thomas de Groot:
> On 2-10-2015 22:04, clipka wrote:
>> Am 02.10.2015 um 01:06 schrieb David Given:
>>
>>> 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.
>>
> 
> This is also true for our own Earth in fact. Local variations of the
> gravitational field make the oceans' surface vary by several (tens of)
> meters, sometimes over quite short distances.

I did know /that/ - but tens of meters is still quite a shot from a
kilometre.

But did you also know that fast-flowing rivers are higher in the middle
than at the banks - sometimes by as much as half a meter?

Post a reply to this message

On 10/3/2015 10:16 AM, clipka wrote:
>> This is also true for our own Earth in fact. Local variations of the
>> >gravitational field make the oceans' surface vary by several (tens of)
>> >meters, sometimes over quite short distances.
> I did know/that/  - but tens of meters is still quite a shot from a
> kilometre.
>

It certainly is. Mind boggling actually.

> But did you also know that fast-flowing rivers are higher in the middle
> than at the banks - sometimes by as much as half a meter?
>

Not the value but I am sure you can see it, on some rivers.


-- 

Regards
     Stephen

Post a reply to this message

On 3-10-2015 12:57, Stephen wrote:
> On 10/3/2015 10:16 AM, clipka wrote:
>>> This is also true for our own Earth in fact. Local variations of the
>>> >gravitational field make the oceans' surface vary by several (tens of)
>>> >meters, sometimes over quite short distances.

>> I did know/that/  - but tens of meters is still quite a shot from a
>> kilometre.
>>
>
> It certainly is. Mind boggling actually.

That is indeed true. Tells something about the composition of the Moon's 
interior.

>
>> But did you also know that fast-flowing rivers are higher in the middle
>> than at the banks - sometimes by as much as half a meter?
>>
>
> Not the value but I am sure you can see it, on some rivers.
>
>

Ah yes. I don't remember exactly why that is: something to do with the 
drag along the border?

-- 
Thomas

Post a reply to this message

On 02/10/15 23:41, clipka wrote:
[...]
>     f_detail(x,y,z) = f_detail_(x,y,z,sqrt(x*x,y*y,z*z))
>     f_detail_(x,y,z,l) = f_noise(x/l,y/l,z/l)

Yup, that's precisely what I'm doing. I have a set of functions which
will map an (x,y,z) point onto the surface of the terrain immediately
under (or over) the point. The noise calculation is then done on that point.

> Also, my personal suggestion is to not hard-code this into your DLL, but
> rather define the detail function in POV-Ray, making use of POV-Ray's
> pigment function feature and one or more of POV-Ray's noise-based
> patterns (such as "bumps").

Unfortunately I need to calculate the terrain shape in the DLL (because
I need to know it for prop placement, which will come later). I suspect
I don't want to go anywhere near adding code to call back into Povray
from the DLL, which is a shame, as a lot of the functions are really useful.

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

On 02/10/15 01:06, David Given wrote:
[...]
> 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.

Hey, guess what --- meshes are so much faster than isosurfaces! Who
knew? (Apparently everyone except me.)

Enclosed is an updated version of the dawn picture; all the settings are
the same, except instead of using isosurfaces for the terrain and ocean,
it's now using meshes. Total render time is 195 seconds (115 for the
parse, which includes the mesh generation, and 80 for the render).

The isosurface version took 715 seconds.

And this version has the procedural deformation on the terrain turned
on, so it's actually doing more work.

The meshes are about 5 million polygons each. The polygons are scaled so
there are ~800 horizontally across the picture, regardless how far away
they are. These are generated by my DLL stuff and the mesh handed
directly to Povray (which immediately takes a copy of it, and then takes
another copy, but never mind). Interestingly the slowest part of the
process is Povray thinking about the mesh after I've passed it the data.
Is it generating a bounding box octree? If so, it's working, because the
rendering is amazingly fast...

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

Preview of image 'newmoon.mesh.jpg'

And here's another one (yeah, yeah, I know you're sick of these by now);
late afternoon at Kastner S, a crater on the eastern limb of the moon.
Don't believe me? Here's a Google Maps link:

https://www.google.com/maps/space/moon/@-8.0337004,85.465223,90856a,20y,270h,69.93t/data=!3m1!1e3

My procedural noise needs a *lot* of work, and there's something very
odd about the sea texture. As does the surface texture, for that matter.
Also there's supposed to be a forest down there...

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
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 'kastner-s.jpg' (123 KB)

Preview of image 'kastner-s.jpg'

Am 06.10.2015 um 00:45 schrieb David Given:

> Interestingly the slowest part of the
> process is Povray thinking about the mesh after I've passed it the data.
> Is it generating a bounding box octree? If so, it's working, because the
> rendering is amazingly fast...

That's indeed what happens (except that it's a KD-tree :))

Post a reply to this message

Am 06.10.2015 um 01:05 schrieb David Given:
> And here's another one (yeah, yeah, I know you're sick of these by now);

No - actually, not at all.


> My procedural noise needs a *lot* of work,

I think the terrain looks gorgeous.

> and there's something very
> odd about the sea texture. As does the surface texture, for that matter.

Waves pattern?
Moiree effect, I'd guess.

Post a reply to this message

What exactly is causing those anomalies in Earth's gravity that cause
the ocean surface to be lower at some regions and higher at some other
regions (or similar effects on the dust on the moon)?



On 03.10.2015 06:28, Thomas de Groot wrote:
> On 3-10-2015 12:57, Stephen wrote:
>> On 10/3/2015 10:16 AM, clipka wrote:
>>>> This is also true for our own Earth in fact. Local variations of the
>>>> >gravitational field make the oceans' surface vary by several (tens of)
>>>> >meters, sometimes over quite short distances.
> 
>>> I did know/that/  - but tens of meters is still quite a shot from a
>>> kilometre.
>>>
>>
>> It certainly is. Mind boggling actually.
> 
> That is indeed true. Tells something about the composition of the Moon's
> interior.
> 
>>
>>> But did you also know that fast-flowing rivers are higher in the middle
>>> than at the banks - sometimes by as much as half a meter?
>>>
>>
>> Not the value but I am sure you can see it, on some rivers.
>>
>>
> 
> Ah yes. I don't remember exactly why that is: something to do with the
> drag along the border?
>

Post a reply to this message

On 16-12-2015 13:01, Sven Littkowski wrote:
> What exactly is causing those anomalies in Earth's gravity that cause
> the ocean surface to be lower at some regions and higher at some other
> regions (or similar effects on the dust on the moon)?
>
That is because the Earth's density is not constant and varies quite a 
lot. A mountain (and its roots) is a massive object for instance that 
deviates gravity. A pendulum is thus attracted towards the mountain when 
you are standing at its base. Very, very slightly of course. Those 
differences describe the /geoid/, the "true" shape of the Earth. See for 
instance this:
https://www.quora.com/If-you-were-to-measure-gravity-on-the-surface-of-the-ocean-over-the-deepest-place-in-the-world-would-it-be-9-81-ms-s2-Or-would-water-have-less-gravitational-pull-than-a-mass-of-rock



-- 
Thomas

Post a reply to this message

On 16-12-2015 13:01, Sven Littkowski wrote:
> What exactly is causing those anomalies in Earth's gravity that cause
> the ocean surface to be lower at some regions and higher at some other
> regions (or similar effects on the dust on the moon)?
>

That is because the Earth's density is not constant and varies quite a 
lot. A mountain (and its roots) is a massive object for instance that 
deviates gravity. A pendulum is thus attracted towards the mountain when 
you are standing at its base. Very, very slightly of course. Those 
differences describe the /geoid/, the "true" shape of the Earth. See for 
instance this:
https://www.quora.com/If-you-were-to-measure-gravity-on-the-surface-of-the-ocean-over-the-deepest-place-in-the-world-would-it-be-9-81-ms-s2-Or-would-water-have-less-gravitational-pull-than-a-mass-of-rock

or:
https://en.wikipedia.org/wiki/Gravity_of_Earth


-- 
Thomas

Post a reply to this message

...and I just remembered the term mascon:

https://en.wikipedia.org/wiki/Mass_concentration_%28astronomy%29

-- 
Thomas

Post a reply to this message

Sven Littkowski <jam### [at] yahoocom> wrote:
> What exactly is causing those anomalies in Earth's gravity that cause
> the ocean surface to be lower at some regions and higher at some other
> regions (or similar effects on the dust on the moon)?

Differences in material composition, with differences in density.

Post a reply to this message

Thanks to both of you, Thomas and Clipka. Yes, I assumed it is the
amount of matter, like mountains or valley which have the one or another
influence. But I wonder, if also the TYPE OF MATTER has influence, too.
Example: I wonder, if a iron sphere of 10,000 km diameter produces the
same gravity as a styrofoam sphere of 10,000 km diameter. I believe, not
only the amount of matter matters, but the type of matter matters, too.
Am I right?

Post a reply to this message

Le 15-12-16 17:59, Sven Littkowski a écrit :
> Thanks to both of you, Thomas and Clipka. Yes, I assumed it is the
> amount of matter, like mountains or valley which have the one or another
> influence. But I wonder, if also the TYPE OF MATTER has influence, too.
> Example: I wonder, if a iron sphere of 10,000 km diameter produces the
> same gravity as a styrofoam sphere of 10,000 km diameter. I believe, not
> only the amount of matter matters, but the type of matter matters, too.
> Am I right?
>

As the sphere of iron is probably about 5 times as dense as your 
styrofoam, even after it have collapsed from it's own mass a few Km 
down, the iron sphere will have a much greater gravity than the styrene 
one. It all depends on the average density of the planete, whitch 
dictate it's total mass, whitch, with the radius, determine the surface 
gravity.

A planet made entirely from water would be about 5 times larger than the 
Earth to have about the same surface gravity, and an escape velocity 
about 5 times higher.

Post a reply to this message

Thanks for the answer, Alan. I think, the more an element is located at
the end of the elements table (all known elements), the more gravity it
is producing. I asked those previous questions, because I am working
there on some idea, but can't really speak yet about it.

Great subject, great group of people here. Big thanks to everyone!

Post a reply to this message

Sven Littkowski <jam### [at] yahoocom> wrote:
> Thanks for the answer, Alan. I think, the more an element is located at
> the end of the elements table (all known elements), the more gravity it
> is producing.

That's not how a scientist would put it, but yes -- the periodic table of
elements is sorted by the number of protons per atom, which coincides with a
sorting by mass per atom, and there is a general trend that "heavier" elements
(those with a higher mass per atom) are also denser (i.e. have higher ratio of
mass per atom vs. volume occupied per atom).

This is just a trend though; for instance, copper, at position 29 in the table
has a density of 8.92 g/cm^3, whereas radium, at position 88 in the table, has a
density of just 5 g/cm^3.

Post a reply to this message

Thanks for this information.

I wonder, if we still will find more elements, especially the heavier
ones. Or if we learn, to create ultra-heavy elements by our own somewhen
in the future, thanks to our continuous learning about new cosmic
building blocks (like quarks, black matter, etc.).

Maybe, one day we can even construct exotic elements that have a
negative gravity.

I think, I should go a little bit deeper into this science. Interesting
enough.

Post a reply to this message

Le 15-12-17 17:10, Sven Littkowski a écrit :
> Thanks for this information.
>
> I wonder, if we still will find more elements, especially the heavier
> ones. Or if we learn, to create ultra-heavy elements by our own somewhen
> in the future, thanks to our continuous learning about new cosmic
> building blocks (like quarks, black matter, etc.).

Maybe that so called "dark matter" is realy just a huge quantity of free 
neutrons.
After all, "dark matter" is regarded as been non interacting with light, 
having a mass, and only interact with normal matter gravitationaly. The 
neutron nicely fit the bill.

>
> Maybe, one day we can even construct exotic elements that have a
> negative gravity.

That mean a negative MASS and ENERGY!
That's the stuff of fiction.

>
> I think, I should go a little bit deeper into this science. Interesting
> enough.
>

If you think about stable elements, no unless there is a catastrophic 
break through.
More elements? Yes. But, most will exist only as single atoms for less 
than a micro second, 0.000001 second, before they spontaneously 
desintegrate.

The heaviest element discovered to date is:
Ununoctium 	symbole: Uuo	 atomic number: 118 and it's most stable 
isotope have 294 nucleotides. It's half life is estimated to be less 
than a nano-second...
It /could/ be a noble gas following the radon, but is yet to be 
classified into any family.


Alain

Post a reply to this message

Yes, this stuff is exciting!

And even better, "Negative Gravity" has been located already in space,
at an asteroid nearby:
https://www.google.com/search?q=Asteroid+Negative+Gravity

:-)

Post a reply to this message

Well, "Negative Gravity" as term is tricky, it is not what I previously
thought it is. I was just reading over that article.

Post a reply to this message

On 18-12-2015 7:39, Sven Littkowski wrote:
> Yes, this stuff is exciting!
>
> And even better, "Negative Gravity" has been located already in space,
> at an asteroid nearby:
> https://www.google.com/search?q=Asteroid+Negative+Gravity
>
> :-)
>


I would call that "centripetal force" ;-)

-- 
Thomas

Post a reply to this message

On 12/18/2015 6:39 AM, Sven Littkowski wrote:
> Yes, this stuff is exciting!
>
> And even better, "Negative Gravity" has been located already in space,
> at an asteroid nearby:
> https://www.google.com/search?q=Asteroid+Negative+Gravity
>
> :-)
>

Groan!

-- 

Regards
     Stephen

Post a reply to this message

Am 18.12.2015 um 01:30 schrieb Alain:

> Maybe that so called "dark matter" is realy just a huge quantity of free
> neutrons.
> After all, "dark matter" is regarded as been non interacting with light,
> having a mass, and only interact with normal matter gravitationaly. The
> neutron nicely fit the bill.

Not really. According to the pretty well-tested Standard Model of
particle physics, free neutrons in deep space would readily undergo
beta(-) decay into hydrogen and electron neutrinos within a matter of a
quarter of an hour on average.

Post a reply to this message

Le 15-12-18 01:39, Sven Littkowski a écrit :
> Yes, this stuff is exciting!
>
> And even better, "Negative Gravity" has been located already in space,
> at an asteroid nearby:
> https://www.google.com/search?q=Asteroid+Negative+Gravity
>
> :-)
>

There is no such thing as negative gravity.

But... There are cases where it may /look/ as if there is:
A small space object is rotating fast enough that the tengential speed 
at it's surface is larger than it's escape velicity.
Only possible if the object is small enough that it's mecanical strength 
is higher than the centrifugal force.
In the case of 1950DA asteroid, it looks like the Van Der Waal 
interaction could be strong enough. Then again, it may actualy be one 
big rock held together by purely mechanical force but that look like 
it's more gravel like.

On a another scale, radiation pressure can overcome gravity.
That's a major factor in the solar wind.
At a cosmological scale, it can actualy push whole galaxies away from 
one another.

Post a reply to this message

Yes, I found out by myself, when reading it. That reporter used a very
misleading headline, my apologies for my error.

Post a reply to this message

On 18-12-2015 9:09, Thomas de Groot wrote:
> On 18-12-2015 7:39, Sven Littkowski wrote:
>> Yes, this stuff is exciting!
>>
>> And even better, "Negative Gravity" has been located already in space,
>> at an asteroid nearby:
>> https://www.google.com/search?q=Asteroid+Negative+Gravity
>>
>> :-)
>>
>
>
> I would call that "centripetal force" ;-)
>
Ouch! "centrifugal" of course :-)

-- 
Thomas

Post a reply to this message

On 12/19/2015 8:07 AM, Thomas de Groot wrote:
> On 18-12-2015 9:09, Thomas de Groot wrote:
>> On 18-12-2015 7:39, Sven Littkowski wrote:
>>> Yes, this stuff is exciting!
>>>
>>> And even better, "Negative Gravity" has been located already in space,
>>> at an asteroid nearby:
>>> https://www.google.com/search?q=Asteroid+Negative+Gravity
>>>
>>> :-)
>>>
>>
>>
>> I would call that "centripetal force" ;-)
>>
> Ouch! "centrifugal" of course :-)
>

No, you were right the first time. ;-)


-- 

Regards
     Stephen

Post a reply to this message

On 19-12-2015 9:41, Stephen wrote:
> On 12/19/2015 8:07 AM, Thomas de Groot wrote:
>> On 18-12-2015 9:09, Thomas de Groot wrote:
>>> On 18-12-2015 7:39, Sven Littkowski wrote:
>>>> Yes, this stuff is exciting!
>>>>
>>>> And even better, "Negative Gravity" has been located already in space,
>>>> at an asteroid nearby:
>>>> https://www.google.com/search?q=Asteroid+Negative+Gravity
>>>>
>>>> :-)
>>>>
>>>
>>>
>>> I would call that "centripetal force" ;-)
>>>
>> Ouch! "centrifugal" of course :-)
>>
>
> No, you were right the first time. ;-)
>
>

I am getting old... Happily I am not God. My creation would be a mess :-)

-- 
Thomas

Post a reply to this message

On 12/19/2015 8:50 AM, Thomas de Groot wrote:
> On 19-12-2015 9:41, Stephen wrote:
>> On 12/19/2015 8:07 AM, Thomas de Groot wrote:
>>> On 18-12-2015 9:09, Thomas de Groot wrote:
>>>> On 18-12-2015 7:39, Sven Littkowski wrote:
>>>>> Yes, this stuff is exciting!
>>>>>
>>>>> And even better, "Negative Gravity" has been located already in space,
>>>>> at an asteroid nearby:
>>>>> https://www.google.com/search?q=Asteroid+Negative+Gravity
>>>>>
>>>>> :-)
>>>>>
>>>>
>>>>
>>>> I would call that "centripetal force" ;-)
>>>>
>>> Ouch! "centrifugal" of course :-)
>>>
>>
>> No, you were right the first time. ;-)
>>
>>
>
> I am getting old... Happily I am not God. My creation would be a mess :-)
>

And this one isn't?


-- 

Regards
     Stephen

Post a reply to this message

On 19-12-2015 10:51, Stephen wrote:
> On 12/19/2015 8:50 AM, Thomas de Groot wrote:
>> On 19-12-2015 9:41, Stephen wrote:
>>> On 12/19/2015 8:07 AM, Thomas de Groot wrote:
>>>> On 18-12-2015 9:09, Thomas de Groot wrote:
>>>>> On 18-12-2015 7:39, Sven Littkowski wrote:
>>>>>> Yes, this stuff is exciting!
>>>>>>
>>>>>> And even better, "Negative Gravity" has been located already in
>>>>>> space,
>>>>>> at an asteroid nearby:
>>>>>> https://www.google.com/search?q=Asteroid+Negative+Gravity
>>>>>>
>>>>>> :-)
>>>>>>
>>>>>
>>>>>
>>>>> I would call that "centripetal force" ;-)
>>>>>
>>>> Ouch! "centrifugal" of course :-)
>>>>
>>>
>>> No, you were right the first time. ;-)
>>>
>>>
>>
>> I am getting old... Happily I am not God. My creation would be a mess :-)
>>
>
> And this one isn't?
>
>

The creator of duty has a lot to answer for...

-- 
Thomas

Post a reply to this message

On 12/19/2015 12:06 PM, Thomas de Groot wrote:
> On 19-12-2015 10:51, Stephen wrote:
>> On 12/19/2015 8:50 AM, Thomas de Groot wrote:
>>> On 19-12-2015 9:41, Stephen wrote:
>>>> On 12/19/2015 8:07 AM, Thomas de Groot wrote:
>>>>> On 18-12-2015 9:09, Thomas de Groot wrote:
>>>>>> On 18-12-2015 7:39, Sven Littkowski wrote:
>>>>>>> Yes, this stuff is exciting!
>>>>>>>
>>>>>>> And even better, "Negative Gravity" has been located already in
>>>>>>> space,
>>>>>>> at an asteroid nearby:
>>>>>>> https://www.google.com/search?q=Asteroid+Negative+Gravity
>>>>>>>
>>>>>>> :-)
>>>>>>>
>>>>>>
>>>>>>
>>>>>> I would call that "centripetal force" ;-)
>>>>>>
>>>>> Ouch! "centrifugal" of course :-)
>>>>>
>>>>
>>>> No, you were right the first time. ;-)
>>>>
>>>>
>>>
>>> I am getting old... Happily I am not God. My creation would be a mess
>>> :-)
>>>
>>
>> And this one isn't?
>>
>>
>
> The creator of duty has a lot to answer for...
>

That's another one on my list, then. :-)


-- 

Regards
     Stephen

Post a reply to this message

Am 19.12.2015 um 09:41 schrieb Stephen:
> On 12/19/2015 8:07 AM, Thomas de Groot wrote:
>> On 18-12-2015 9:09, Thomas de Groot wrote:
>>> On 18-12-2015 7:39, Sven Littkowski wrote:
>>>> Yes, this stuff is exciting!
>>>>
>>>> And even better, "Negative Gravity" has been located already in space,
>>>> at an asteroid nearby:
>>>> https://www.google.com/search?q=Asteroid+Negative+Gravity
>>>>
>>>> :-)
>>>>
>>>
>>>
>>> I would call that "centripetal force" ;-)
>>>
>> Ouch! "centrifugal" of course :-)
>>
> 
> No, you were right the first time. ;-)

Actually, that depends on what "that" is supposed to denote:

"that" = (negative) "gravity": (negative) "centripetal force".

"that" = "negative gravity": (positive) "centrifugal force".

Post a reply to this message

On 19-12-2015 13:32, clipka wrote:
> Am 19.12.2015 um 09:41 schrieb Stephen:
>> On 12/19/2015 8:07 AM, Thomas de Groot wrote:
>>> On 18-12-2015 9:09, Thomas de Groot wrote:
>>>> On 18-12-2015 7:39, Sven Littkowski wrote:
>>>>> Yes, this stuff is exciting!
>>>>>
>>>>> And even better, "Negative Gravity" has been located already in space,
>>>>> at an asteroid nearby:
>>>>> https://www.google.com/search?q=Asteroid+Negative+Gravity
>>>>>
>>>>> :-)
>>>>>
>>>>
>>>>
>>>> I would call that "centripetal force" ;-)
>>>>
>>> Ouch! "centrifugal" of course :-)
>>>
>>
>> No, you were right the first time. ;-)
>
> Actually, that depends on what "that" is supposed to denote:
>
> "that" = (negative) "gravity": (negative) "centripetal force".
>
> "that" = "negative gravity": (positive) "centrifugal force".
>

Well, in last resort, I meant the second one ;-)

-- 
Thomas

Post a reply to this message

Sven Littkowski <jam### [at] yahoocom> wrote:
> Yes, I found out by myself, when reading it. That reporter used a very
> misleading headline, my apologies for my error.

Beware of science headlines.  Headlines are designed to sell stories, and often
do not reflect the real story.

This is especially true in science, often made worse because most reporters
don't understand how science works.  How often have you read about a new killer
asteroid being discovered, only to read a few days later that the asteroid isn't
going to hit us after all?  The impression is left of scientists with egg on
their faces, when the truth is all that happened is that the scientists narrowed
the error bar after more data came in.  But that's not how the headlines read.

It's especially bad with climate science reporting, due to the political climate
surrounding this issue.  A temporary /slowdown/ in the /warming/ trend is
reported as the Earth is cooling off!

Never assume you know even the gist of a science report if you haven't read
beyond the headline.  And never assume that the science report accurately
reflects the actual science paper, unless you have read the actual science
paper!  (I know, it's tough.)

Post a reply to this message

Le 15-12-21 13:23, Cousin Ricky a écrit :
> Sven Littkowski <jam### [at] yahoocom> wrote:
>> Yes, I found out by myself, when reading it. That reporter used a very
>> misleading headline, my apologies for my error.
>
> Beware of science headlines.  Headlines are designed to sell stories, and often
> do not reflect the real story.
>
> This is especially true in science, often made worse because most reporters
> don't understand how science works.  How often have you read about a new killer
> asteroid being discovered, only to read a few days later that the asteroid isn't
> going to hit us after all?  The impression is left of scientists with egg on
> their faces, when the truth is all that happened is that the scientists narrowed
> the error bar after more data came in.  But that's not how the headlines read.
>
> It's especially bad with climate science reporting, due to the political climate
> surrounding this issue.  A temporary /slowdown/ in the /warming/ trend is
> reported as the Earth is cooling off!
>
> Never assume you know even the gist of a science report if you haven't read
> beyond the headline.  And never assume that the science report accurately
> reflects the actual science paper, unless you have read the actual science
> paper!  (I know, it's tough.)
>
>

So true.

Post a reply to this message