Gilles Tran wrote:
> 
> One thing that could be useful though, is to make the slope-dependent pattern
> work with turbulence.
> 

It already works, partially. Turbulence affects the altitude component of the
pattern, but not the slope component. If you have "slope y" (no altitude
component) turbulence does nothing.
But it should be possible to make turbulence affect the slope component also;
turbulating the normal vector before passing it to the pattern function should
give the desired result. How difficult this is to implement - I know not.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt

Post a reply to this message

Nathan Kopp wrote in message <3a5525bc@news.povray.org>...
>Got a question for you all:
>
>Does anybody use the advanced features of MegaPov's slope-dependent
pattern?


I have used the { slope <slope>, <altitude> } and found it to be pretty
useful.  I have not had a chance to play around with the third form.
However, from what I have seen in the documentation, it did not seem too
confusing.  In my opinion (humble as it is) I think it would be worth
retaining these features.

Quadhall
tre### [at] ww-interlinknet

Post a reply to this message

> Does anybody use the advanced features of MegaPov's slope-dependent
pattern?
> Anything that can be done with the advanced features can be replicated
using
> a combination of the simple slope pattern, gradient, and color_maps, using
> pigment_pattern to combine everything.

Here's what I meant:

If I understand how the advanced features work, the "expanded" version using
simple slope, gradient, average, and pigment_pattern would look something
like this:

pigment_pattern{
  average
  color_map{
    [<alt_weight> gradient <alt_vect>
       color_map{[<lo_alt> rgb 0][<hi_alt> rgb 1]]
    [<slope_weight> slope <slope_vect>
       color_map{[<lo_slope> rgb 0][<hi_slope> rgb 1]]
  }
}

I admit this is much longer and more difficult to type.  But if you saw that
in a POV scene file, it would be easy to guess what was going on.  Version 2
of "slope" would look just like that, except lo_alt and lo_slope would both
be zero, and hi_alt and hi_slope would be 1.0.

Note that this would also probably render slightly slower.

-Nathan

Post a reply to this message

Chris Huff wrote:
> 
> Ah, I see...well, declare the large scale function, and use something
> like:
> #declare P = 0.01;// sampling distance
> #declare Fn = function {...}
> 
> #declare MaxSlopeFn =
> function {
>     max(max(
>         (abs(Fn(x+P, y, z)-Fn(x-P, y, z))),
>          abs(Fn(x, y+P, z)-Fn(x, y-P, z)))),
>          abs(Fn(x, y, z+P)-Fn(x, y, z-P)))
>     )/(2*P)
> }
> 

That's an interesting idea, although it would be somewhat slow when used
with pigment functions (1 call to function -> 6 calls)

Thinking about your mentioning of displace warps, i developed another way
for the 2d case, see p.b.i and p.t.s-f. for the implementation.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3A56E40F.9D11C7A1@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> That's an interesting idea, although it would be somewhat slow when used
> with pigment functions (1 call to function -> 6 calls)

Also, the max slope may not be the best thing to use...you might want to 
average the three parts, or treat them as components of a vector and 
calculate it's length, or...
As for the speed, yes, it would be slow...but since you mentioned using 
it on functions with large-scale features, it probably would be bearable 
in many cases.
And if you restrict yourself to 2D, you cut it down to 4 calls...and you 
can probably do something with 4 calls in 3D and only 3 calls in 2D, but 
I'm not sure if POV functions can do that...you might have to implement 
it in C, as a patch.


> Thinking about your mentioning of displace warps, i developed another way
> for the 2d case, see p.b.i and p.t.s-f. for the implementation.

Now that is interesting...I had to look at the source to figure out how 
you did it.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Seems a much better way of doing things. Slope-dependent patterns tend to be
quite slow to render anyway a little slower won't bother me.

Mick

Post a reply to this message

"Nathan Kopp" wrote:
> pigment_pattern{
>   average
>   color_map{
>     [<alt_weight> gradient <alt_vect>
>        color_map{[<lo_alt> rgb 0][<hi_alt> rgb 1]]
>     [<slope_weight> slope <slope_vect>
>        color_map{[<lo_slope> rgb 0][<hi_slope> rgb 1]]
>   }
> }

This would work very well except that there's one big problem.
A vital feature of lo_alt and hi_alt is that they are not restricted to the
0 to 1 range. If you have a mountain that goes from -5*y to 5*y you set
lo_alt and hi_alt to -5 and 5 respectively. This is not possible with your
method. You would have to scale and translate the gradient instead and even
that wouldn't quite give the same pattern since the gradient pattern
increases in value in both the positive and negative direction. I guess the
gradient pattern uses some abs functions. Also, it would only work with
alt_vect being x, y, or z. Have you ever tried using gradient with other
vectors? It gives undesired results again because of the abs functions.

I think version 2 and 3 should be preserved. I won't go into details with
version 2, but concentrate on version 3 which seems to be the one many find
confusing. I personally think version 3 is highly useful. Actually, after
having learned it I'd suggest that everybody *always* use version 3 instead
of version 2, since it makes it much easier to get controllable results.

I do think the slope pattern should be changed though.

Most important suggestion:

Currently slope pattern values repeats with the mod function when values are
outside the 0 to 1 range. This is doubly useful for anything and it often
makes it difficult or just unnecessary tiresome to get desired results. I
suggest that the values are clipped. The clipping should occur *before* the
weighted addition of slope and altitude.
The slope value should be clipped so values below lo_slope becomes 0 and
values above hi_slope becomes 1. (lo_slope and hi_slope defaults to 0 and 1
respectively when not specified.)
The altitude value should be clipped so values below lo_alt becomes 0 and
values above hi_alt becomes 1.
The weighted addition happens *after* those clippings. That is more
intuitive to the user than if the final value is clipped.

Another suggestion is to change syntax from

<slope>, <altitude>, <lo_slope,hi_slope>, <lo_alt,hi_alt>

to

<slope>, <lo_slope,hi_slope>, <altitude>, <lo_alt,hi_alt>

This makes it possible to use lo_slope and hi_slope also when altitude is
not used at all.
Sure, it also means that you cannot use altitude without using the lo_ and
hi_ vectors too, but as I said it should only make it easier to understand
for the user.

I personally think the lo_ and hi_ vectors are easier to understand when you
think of <slope> and <lo_slope,hi_slope> as one unity and <altitude> and
<lo_alt,hi_alt> as another unity. First understand the two individual
unities and then care about the interaction (weighted addition) afterwards.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a57ca8c@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> <slope>, <lo_slope,hi_slope>, <altitude>, <lo_alt,hi_alt>
> 
> This makes it possible to use lo_slope and hi_slope also when altitude is
> not used at all.
> Sure, it also means that you cannot use altitude without using the 
> lo_ and hi_ vectors too, but as I said it should only make it easier 
> to understand for the user.

I'd use a more verbose but more flexible syntax:
slope {SLOPE_VECTOR, LOW_SLOPE, HIGH_SLOPE
    altitude ALTITUDE_VECTOR, LOW_ALT, HIGH_ALT
    type planar|point
}
The LOW...HIGH values would be optional for both slope and altitude. 
Note that the LOW...HIGH values are separate float values, not 2D 
vectors...I think vectors should be saved for points and colors, not 
ranges.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

i vote we keep it all.

Nathan Kopp wrote:
> 
> Got a question for you all:
> 
> Does anybody use the advanced features of MegaPov's slope-dependent pattern?
> Anything that can be done with the advanced features can be replicated using
> a combination of the simple slope pattern, gradient, and color_maps, using
> pigment_pattern to combine everything.  Personally, I think the advanced
> features are quite confusing and difficult to use.
> 
> Therefore, I'm thinking about removing them from future versions of MegaPov
> (and probably POV 3.5, also) and keeping only the simple form of slope (
> "slope <vector>" ), but I didn't want to do that if enough people thought
> they were very useful.
> 
> -Nathan

Post a reply to this message

"Chris Huff" wrote:
> I'd use a more verbose but more flexible syntax:
> slope {SLOPE_VECTOR, LOW_SLOPE, HIGH_SLOPE
>     altitude ALTITUDE_VECTOR, LOW_ALT, HIGH_ALT
>     type planar|point
> }
> The LOW...HIGH values would be optional for both slope and altitude.
> Note that the LOW...HIGH values are separate float values, not 2D
> vectors...I think vectors should be saved for points and colors, not
> ranges.

I completely agree. That is a good syntax. I think everything else than
SLOPE_VECTOR should be optional, but I'm sure that's what you meant too.
(You don't specify LOW_SLOPE without specifying HIGH_SLOPE too though, and
similar with LOW_ALT and HIGH_ALT.) The point type is something I've often
wanted myself. Interesting effects could be achieved setting the point to
the location of a light_source or the camera.

BTW, what do you think of the clipping suggestions I had?

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message