![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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-interlink net
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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] gmx de>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3A56E40F.9D11C7A1@gmx.de>, Christoph Hormann
<chr### [at] gmx de> 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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a57ca8c@news.povray.org>, "Rune" <run### [at] iname com>
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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a585d21$1@news.povray.org>, "Rune"
<run### [at] iname com> 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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |