I am experimenting with isosurfaces to make rock landscapes, using as a 
basis my arcane Geomorph macro of several years ago.

I am fairly satisfied with the rocks, but I have difficulties with the 
texture. I use a slope/altitude texture where I would like the grass to 
show on the /upper/ sides of rock ridges and not on the /underside/ as 
it does now. I tried different settings but to no avail. This is the 
code I use for the shown image:

texture {
   slope {
     <0.0, 0.3, 0.0> , 0.0 , 0.5
     altitude <0, 1-0.3, 0.0> , LowerBound , UpperBound
   }
   texture_map {
     [0.60 Grass]
     [0.65 Soil]
     [0.80 Rocks]
   }
}

Any idea how I could achieve what I want? The difficulty imo resides 
with the use of isosurfaces which have overhangs. A height_field would 
be easier in this case.

Thomas

Post a reply to this message

Attachments:
Download 'elements of geology5_03c.png' (432 KB)

Preview of image 'elements of geology5_03c.png'

Le 03/07/2013 13:17, Thomas de Groot nous fit lire :
> I am experimenting with isosurfaces to make rock landscapes, using as a
> basis my arcane Geomorph macro of several years ago.
> 
> I am fairly satisfied with the rocks, but I have difficulties with the
> texture. I use a slope/altitude texture where I would like the grass to
> show on the /upper/ sides of rock ridges and not on the /underside/ as
> it does now. I tried different settings but to no avail. This is the
> code I use for the shown image:
> 
> texture {
>   slope {
>     <0.0, 0.3, 0.0> , 0.0 , 0.5
>     altitude <0, 1-0.3, 0.0> , LowerBound , UpperBound
>   }
>   texture_map {
>     [0.60 Grass]
>     [0.65 Soil]
>     [0.80 Rocks]
>   }
> }
> 
> Any idea how I could achieve what I want? The difficulty imo resides
> with the use of isosurfaces which have overhangs. A height_field would
> be easier in this case.
> 

Reading:

http://www.povray.org/documentation/view/3.6.1/393/

<0,0.3,0> is the direction of reference, so rather something like +y

Beware, going to -y evaluates to Low (here 0), and
going +y evaluates to High (here 0.5) (and horizontal x or z evaluates
to middle value (here 0.25) (but it's not linear, arcsinus is used, or
rather it's linear for the angle but not the projection)

Altitude add a gradient. here parallel to +y too.

At LowerBound, the value is 0, and 1 at UpperBound.

The value of slope and the value of altitude get merged using the
relative length of each vector (otherwise irrelevant). And it is *not* a
linear interpolation (but the final value is wrapped to be modulo 1.0),
it's just a basic weighted addition. (the slope value is [0,1), but the
altitude value can be out of range if LowerBound & UpperBound are too small)

So, let's assume +y is the normal where you want some grass to show.
slope { abs(L1)*y, 1, 0 // keep full range, inverted
// (y->0, vertical->0.5, overhang (surplomb)->1.0)
       altitude abs(L2)*y, LowerBound, UpperBound (
      }
 texture_map{
  [0.25 Grass] // flat & small slope are full of grass
  [0.45 Soil] // a slope without any grass
  [0.5 Rocks] // a vertical surface is rock, and so is overhanging
  }

you can then adjust the weight of L1 & L2. (nevertheless, L2 will
generate grass everywhere at LowerBound despite the normal, so better
have LowerBound far out of scope (or you might want to compress the
texture_map to 0.125/0.225/0.25 or further, to reduce the influence of
altitude LowerBound.

Assuming a ground at 0 and Upperbound at 100m, LowerBound might be
interesting at -100 or -200... (in function of the texture_map's
compression), with L2 about 0.01 or less; L1 can probably be 0.99 or a
bit less

(if Lowerbound & Upperbound are from the iso, maybe the Lowerbound value
in altitude should be replaced with Lowerbound - (Upperbound -
Lowerbound)*Factor )

Post a reply to this message

Thanks. Some comments before experimenting with what you suggest.

On 3-7-2013 15:47, Le_Forgeron wrote:
> Reading:
>
> http://www.povray.org/documentation/view/3.6.1/393/
>
> <0,0.3,0> is the direction of reference, so rather something like +y

Yes, and you can weight slope against altitude by fractionating the 
direction of slope and altitude. Hence <0,0.3,0> and <0,0.7,0> 
respectively in my code.
>
> Beware, going to -y evaluates to Low (here 0), and
> going +y evaluates to High (here 0.5) (and horizontal x or z evaluates
> to middle value (here 0.25) (but it's not linear, arcsinus is used, or
> rather it's linear for the angle but not the projection)

Yes. Note that the documentation says the use 0.0, 0.5 for Lo_slope and 
Hi_slope permits the texture_map to be used from 0 to 1.

>
> Altitude add a gradient. here parallel to +y too.
>
> At LowerBound, the value is 0, and 1 at UpperBound.

LowerBound and UpperBound in my code are the vertical limits of the 
bounding box of the isosurface.

>
> The value of slope and the value of altitude get merged using the
> relative length of each vector (otherwise irrelevant). And it is *not* a
> linear interpolation (but the final value is wrapped to be modulo 1.0),
> it's just a basic weighted addition. (the slope value is [0,1), but the
> altitude value can be out of range if LowerBound & UpperBound are too small)
>
> So, let's assume +y is the normal where you want some grass to show.
> slope { abs(L1)*y, 1, 0 // keep full range, inverted
> // (y->0, vertical->0.5, overhang (surplomb)->1.0)
>         altitude abs(L2)*y, LowerBound, UpperBound (
>        }
>   texture_map{
>    [0.25 Grass] // flat & small slope are full of grass
>    [0.45 Soil] // a slope without any grass
>    [0.5 Rocks] // a vertical surface is rock, and so is overhanging
>    }
>
I have to test this. Are you sure that this is correct for Lo_slope=0 
and Hi_slope is 0.5? I shall test it also for values 0 and 1.

> you can then adjust the weight of L1 & L2. (nevertheless, L2 will
> generate grass everywhere at LowerBound despite the normal, so better
> have LowerBound far out of scope (or you might want to compress the
> texture_map to 0.125/0.225/0.25 or further, to reduce the influence of
> altitude LowerBound.
>
> Assuming a ground at 0 and Upperbound at 100m, LowerBound might be
> interesting at -100 or -200... (in function of the texture_map's
> compression), with L2 about 0.01 or less; L1 can probably be 0.99 or a
> bit less
>
> (if Lowerbound & Upperbound are from the iso, maybe the Lowerbound value
> in altitude should be replaced with Lowerbound - (Upperbound -
> Lowerbound)*Factor )

This is an interesting idea. I have to test that too...

Thomas

Post a reply to this message

> The difficulty imo resides
> with the use of isosurfaces which have overhangs. A height_field would
> be easier in this case.

Do you specifically want overhangs or not? If not then you can rewrite 
your isosurface function instead of f(x,y,z) put something like 
y-f(x,0,z) which will guarantee no overhangs (more like a height field). 
You'll need to change the function details though to get a similar shape 
as before.

Post a reply to this message

Le 03/07/2013 16:19, Thomas de Groot nous fit lire :
> 
> Yes. Note that the documentation says the use 0.0, 0.5 for Lo_slope and
> Hi_slope permits the texture_map to be used from 0 to 1.

the default 'slope { <vector> }' is already in [0;1)

when used with 'slope { <vector>, Low, High }', I'm afraid it's bugged,
or I did not understood the text correctly.

1. parser transforms Low & High in Low, Range
2. pattern transforms value to (value-Low)/Range
(original value is the angle in 0--1 : 0 is the opposite of the vector's
direction, 1 is the same direction as the vector)

0 become -Low/Range
1 become (1-Low)/Range

and then the usual modulo 1.0 is applied (unless altitude is present).

So, ... 0.0 , 0.5 would transform 0 in 0, and 1 in 2. The 0, 0.5 give
full range for *heighfield* (only) because there is no overhangs on
heightfield. (but there is for isosurface, so better stay away from Low,
High)

I was hoping to have grass at the low part of map, but maybe you should
reconsider and it might be easier to have grass near 1, and rock at 0.

(and with altitude weighted as 1/4 (and slope at 3/4), the grass/soil
might start at 0.6... but once again, I feel that Lower & Upper might be
bugged, or not ? :

1. parser transforms Lower & Upper in Lower, Range
2. pattern transforms value to (value - Lower)/Range
(original value is the oriented length of the projection of the point
coordinate on the *normalised* vector of altitude (from origin)(yep,
length of altitude is irrelevant, excepted for weight with slope)

Post a reply to this message

On 3-7-2013 17:41, scott wrote:
>> The difficulty imo resides
>> with the use of isosurfaces which have overhangs. A height_field would
>> be easier in this case.
>
> Do you specifically want overhangs or not? If not then you can rewrite
> your isosurface function instead of f(x,y,z) put something like
> y-f(x,0,z) which will guarantee no overhangs (more like a height field).
> You'll need to change the function details though to get a similar shape
> as before.
>

Overhangs are necessary features of the rocks, hence the use of 
isosurfaces. Otherwise yes, the 0 instead of y is a useful feature indeed.

Thomas

Post a reply to this message

OK. This goes a bit too far for my simple understanding ;-)

As far as I can tell, the pattern seems not to be bugged, but that is 
for specialists to confirm. I have always used it to full satisfaction 
and complete agreement with the the documentation. However, isosurfaces 
being a bit more complex than height_fields, the tuning of the 
parameters is a bit more complex too.

I finally arrived at a correct render by using a negative direction of 
slope. I don't know why in earlier tests I did not get it right, 
probably I did other things wrong. I have still to test it further but 
as soon as I have a correct image I shall post it together with the 
pattern code used.

Thanks for the discussion! It always helps to clear the mess.

Thomas

On 4-7-2013 0:35, Le_Forgeron wrote:
> Le 03/07/2013 16:19, Thomas de Groot nous fit lire :
>>
>> Yes. Note that the documentation says the use 0.0, 0.5 for Lo_slope and
>> Hi_slope permits the texture_map to be used from 0 to 1.
>
> the default 'slope { <vector> }' is already in [0;1)
>
> when used with 'slope { <vector>, Low, High }', I'm afraid it's bugged,
> or I did not understood the text correctly.
>
> 1. parser transforms Low & High in Low, Range
> 2. pattern transforms value to (value-Low)/Range
> (original value is the angle in 0--1 : 0 is the opposite of the vector's
> direction, 1 is the same direction as the vector)
>
> 0 become -Low/Range
> 1 become (1-Low)/Range
>
> and then the usual modulo 1.0 is applied (unless altitude is present).
>
> So, ... 0.0 , 0.5 would transform 0 in 0, and 1 in 2. The 0, 0.5 give
> full range for *heighfield* (only) because there is no overhangs on
> heightfield. (but there is for isosurface, so better stay away from Low,
> High)
>
> I was hoping to have grass at the low part of map, but maybe you should
> reconsider and it might be easier to have grass near 1, and rock at 0.
>
> (and with altitude weighted as 1/4 (and slope at 3/4), the grass/soil
> might start at 0.6... but once again, I feel that Lower & Upper might be
> bugged, or not ? :
>
> 1. parser transforms Lower & Upper in Lower, Range
> 2. pattern transforms value to (value - Lower)/Range
> (original value is the oriented length of the projection of the point
> coordinate on the *normalised* vector of altitude (from origin)(yep,
> length of altitude is irrelevant, excepted for weight with slope)
>
>

Post a reply to this message

I promised an image, here it is.

Used the following pattern code:

texture {
   slope {
     <0.0, -0.3, 0.0> , 0.0 , 0.5
     altitude <0, 0.7, 0.0> , LowerBound-5 , UpperBound
   }
   texture_map {
     [0.60 Grass]
     [0.65 Soil or weathering if you want]
     [0.80 Rock]
   }
}

Note that - as suggested by Le_Forgeron - I lowered Lo_alt a bit more 
than the lower boundary of the bounding_box of the isosurface. Playing 
with that setting gives indeed more interesting possibilities.

Thomas

Post a reply to this message

Attachments:
Download 'elements of geology5_04.png' (454 KB)

Preview of image 'elements of geology5_04.png'