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

> Does anybody use the advanced features of MegaPov's slope-dependent
pattern?

To be quite frank with you, I haven't really gotten into them because they
are very confusing to me, and I've not had good results with them in my
work. I would really like it if I could use "slope <vector> <vector>", and
have it work as advertised, but I have not had much success with this.

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

Go right ahead... but like I said, the second form would be nice if it
worked for me. I had some strange problems with it I'm not sure I can
replicate, but they were there nonetheless.

Post a reply to this message

Hi Nathan

I've tried using the more advanced features and have had mixed success. If
the ideas behind them could be developed they could be very useful. I must
admit I've been deterred from using them by their difficulty. I won't miss
them if they go.

Mick

Post a reply to this message

Nathan Kopp wrote:

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

Same thing here. I also have trouble understanding the advanced features and
wouldn't miss them.
One thing that could be useful though, is to make the slope-dependent pattern
work with turbulence.

G.

--

**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery

Post a reply to this message

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

No, please keep them!

As the megapov docu says (and it's quite good to understand in that
section) there are three different types, the first two quite easy to
understand, i use both quite often.  The 'snowman' picture i posted some
time ago to p.b.i. uses 'slope z, z' for the terrain and 'slope z+y' for
the tree.  

The third type is a bit more difficult, i also used it in the past, but
it's not so intuitive to use.  But it also seems to be more difficult to
be replicated with more complicated pigments as you suggested.  

I already thought about writing a slope pattern tutorial in the past.  If
you decide to keep it, i could give it a try, otherwise there is not much
need :-)

Something different: i often like to have a slope pattern not for objects
but for patterns themselves or pigments, like:

pigment {
  slope y {
    [pattern]
  }
  color_map { ... }
}

This would be quite useful for isosurface functions for example.  I have
no idea right now if that's easy to implement, just an idea.

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

"Nathan Kopp" <Nat### [at] Koppcom> wrote in message
news:3a5525bc@news.povray.org...
> Got a question for you all:
>

Well, I've never used type 3, but I will cry if you remove type 2.

Post a reply to this message

I have been playing with the slope dependent texturing quite a bit lately -
I have found that it is really useful (at least for my stuff anyway...).
Put my vote for keeping types 1 and 2.  I haven't gotten the hang of 3
(yet).

--  the autowitch

Post a reply to this message

In article <3A558D6B.61C493BF@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> Something different: i often like to have a slope pattern not for objects
> but for patterns themselves or pigments, like:
...snip...
> This would be quite useful for isosurface functions for example.  I have
> no idea right now if that's easy to implement, just an idea.

Are you thinking of something for the gradient of a pattern? A pattern 
that would return higher values in areas that change rapidly, but 
approach 0 in "flat" areas? The displace warp can do something similar, 
the code could probably be modified to do this pattern(maybe a more 
general pattern that calculates the "amount of warping" for any warp). 
Actually, you could probably do it with an isosurface function...I don't 
know how useful it would be in isosurfaces, though.

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

Chris Huff wrote:
> 
> Are you thinking of something for the gradient of a pattern? A pattern
> that would return higher values in areas that change rapidly, but
> approach 0 in "flat" areas? 

That's exactly what i meant.

> The displace warp can do something similar,
> the code could probably be modified to do this pattern(maybe a more
> general pattern that calculates the "amount of warping" for any warp).

I think that would suffice, since a warp does not only specify the amount
but also the direction, this could be even more universal.

> Actually, you could probably do it with an isosurface function...I don't
> know how useful it would be in isosurfaces, though.
> 

Not sure whow you mean that, the purpose i was thinking of was for example
controlling the fine structure of an isosurface landscape depending on the
slope of it's large scale shape.

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 <3A565458.62638751@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> I think that would suffice, since a warp does not only specify the amount
> but also the direction, this could be even more universal.

Well, the warping vector can't be used directly, since patterns are 
float values only...I was thinking of using the length of the warp 
vector.


> Not sure whow you mean that, the purpose i was thinking of was for example
> controlling the fine structure of an isosurface landscape depending on the
> slope of it's large scale shape.

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)
}

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

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

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

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

Exactly...you can leave off the whole altitude portion, or just the 
LOW/HIGH portions of either altitude or slope. Maybe even make the slope 
vector itself optional, many people would otherwise just be using "slope 
{y}" all the time, it would be nice if they could just say "slope".


> (You don't specify LOW_SLOPE without specifying HIGH_SLOPE too though, and
> similar with LOW_ALT and HIGH_ALT.)

Actually, you would have to make a special effort to enforce that, and I 
see no reason to do so...it would be easier to make them all optional.


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

Or for things like putting soot on the sides of a cage surrounding a 
flame, paint on objects surrounding a very messy accident, etc.


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

About the way it repeats when outside the [0, 1] range? Sounds good to 
me, but there may be a better solution. Maybe a combination of the 
simple slope pattern, a way to specify the clipping/scaling for 
individual patterns, and combining patterns together with function 
patterns(or with the pigment_pattern).

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