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