"Chris Huff" wrote:
> Interesting how one fairly simple looking feature (the
> function pattern) can replace so many others...

Thanks for the function.

> If one feature can replace several others, I say go for
> that one feature.

That's my general opinion too. Only to a certain degree though.

I don't think build-in solid patterns are completely redundant just because
the function pattern can create any solid pattern. I think simple patterns
that will most probably be used very often should be built in, while
complicated specialised patterns can be made with the function pattern.

The reason I think it would be reasonable to include the gradient2 pattern
(or whatever you would call it) in POV-Ray itself is that it's so simple and
useful. IMHO that pattern is much more useful than many of the patterns that
are currently included in the official distribution of POV-Ray, and I've
needed it many more times than most of the other patterns...

We were talking about the slope pattern in p.u.p. There happened to be
another situation where I thought about the limitations of the gradient
pattern. If the gradient2 pattern were made I'd say a combination of
gradient2 <VECTOR> and a simple slope <VECTOR> would be as powerful as the
longer slope version discussed there. The only reason I "vote" for the long
slope syntax is that a flexible gradient pattern like gradient2 doesn't
exist.

In your opinion what are the criteria when deciding if a new pattern is
worthy of addition?

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

> Yes, although it's probably faster if they are hardcoded.  

Yes, but with such a simple function you probably would have to run a 
benchmark to see the difference.

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

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

> I don't think build-in solid patterns are completely redundant just 
> because the function pattern can create any solid pattern. I think 
> simple patterns that will most probably be used very often should be 
> built in, while complicated specialised patterns can be made with the 
> function pattern.

I agree...but the "gradient2" pattern seems like an over-specialized 
pattern to me.


> The reason I think it would be reasonable to include the gradient2 
> pattern (or whatever you would call it) in POV-Ray itself is that 
> it's so simple and useful. IMHO that pattern is much more useful than 
> many of the patterns that are currently included in the official 
> distribution of POV-Ray, and I've needed it many more times than most 
> of the other patterns...

I still don't quite understand why...but I've been thinking of some 
extensions to the pattern syntax that would allow the ordinary gradient 
to be used this way. Basically allowing pattern values outside the [0, 
1] range and specifying how they are clipped and scaled to fit in the 
proper range...it would be more flexible because you could specify where 
and how many bands you want instead of using yet another pattern. 
Probably an extension to the waveforms feature...


> In your opinion what are the criteria when deciding if a new pattern is
> worthy of addition?

Well, it would have to be impossible or difficult to do with existing 
features(for example, even the simplest slope pattern can't be done with 
function patterns), and it would have to be useful. The "gradient2" 
pattern is very easy to do with existing features, and I don't see it as 
being used very often, so I think it would fit much better in an include 
file. Also, as mentioned above, I've been thinking about a possible 
feature for *all* patterns that could replace it and be more flexible.

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

Mick Hazelgrove <mic### [at] mhazelgrovefsnetcouk> wrote:
: But Runes suggestion would be easily available to many users who do not have
: your mathmatical skills. Or do not frequent these newsgroups.

  Why code something in the POV-Ray source code when it's easily done with
a macro?
  Including a macro with these kind of specialized patterns in the standard
distribution of POV-Ray would be a lot better choice.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

"Chris Huff" wrote:
> I've been thinking of some extensions to the pattern syntax
> that would allow the ordinary gradient to be used this way.
> Basically allowing pattern values outside the [0, 1] range
> and specifying how they are clipped and scaled to fit in the
> proper range...it would be more flexible because you could
> specify where and how many bands you want instead of using
> yet another pattern. Probably an extension to the waveforms
> feature...

Sounds like a very good idea. I have some questions.
I don't know the POV source but judging from the way some patterns seem to
work I suspect that many patterns in fact does exceed the [0,1] range but
there's some global function that applies the mod function to all patterns
before they are returned. Is this assumption correct?

And you are thinking of alternatives to this global "mod enforcement"?

It sounds like a good idea. But exactly why does all patterns need to be in
the [0,1] range anyway? Why can't we allow any values in patterns? To access
those unlimited values you would simply allow all values in color_maps too
etc. I have never understood the reason for this limitation.

But back to the original topic. Say you made a "wave-type" that clipped
patterns at 0 and 1 instead of "mod"-ifying them. That solves a third of my
problem with the gradient pattern.

Another third of the problem is that only the x, y, and z vector can be used
plus combination such as <1,0,1> or <1,1,1>. Other vectors don't work. For
example <2.5,0,0> is converted to <1,0,0> and <0.1,0,3> is converted to
<1,0,1>. Fixing this odd behaviour would not break old scenes, but only add
new functionality to the gradient pattern. Could you do that too?

The last third of my problem is that the gradient pattern is mirrored in the
xy plane, the xz plane and the yz plane (abs functions?). I think it should
rather be mirrored in the plane perpendicular to the pattern vector (which
would give the same result when the vector is x, y or z). One of the
"wave-types" you are talking about could take care of that. It would (among
other things) take the abs of the function. This "wave-type" should then be
the default to preserve backward-compatibility.

What do you think of my suggestions?
Have I misunderstood what it's all about?

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

>   Including a macro with these kind of specialized patterns in the
standard
> distribution of POV-Ray would be a lot better choice.

Agreed. So, who is going to compile all of these patterns, and put them into
the official distribution?

Post a reply to this message

Tony[B] <ben### [at] catholicorg> wrote:
: Agreed. So, who is going to compile all of these patterns, and put them into
: the official distribution?

  I think that the pov-team and the TAG are doing the main work on this.
People are very welcome to suggest their own macros.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Rune wrote:

> The pattern is a bit like gradient and a bit like planar, but more powerful
> IMHO. The syntax would be like gradient, only with another keyword of
> course.
> 
> gradient2 <VECTOR>
> 
> ...or something like that. gradient2 y would from y=0 to y=1 return 0 to 1.
> But unlike regular gradient y it would stay at 1 at y>1 instead of
> repeating. At y<0 it would return 0, and that's where it's different from
> both gradient and planar. It increases in only the positive <VECTOR>
> direction, not both in the positive and negative direction.

It has already been done... but not in the official 3.1g
Please have a look about SHEET (or BAND ?) in some unofficial version.
It is exactly what it does.

The code of the functions was posted on the server.

Post a reply to this message

In article <3A599631.FFE03888@atosorigin.com>, Jerome Grimbert 
<jer### [at] atosorigincom> wrote:

> It has already been done... but not in the official 3.1g
> Please have a look about SHEET (or BAND ?) in some unofficial version.
> It is exactly what it does.

There are two patterns..."sheet" and "banded". The "sheet" pattern uses:

  value = EPoint[X]*TPat->Vals.Gradient[X]
        + EPoint[Y]*TPat->Vals.Gradient[Y]
        + EPoint[Z]*TPat->Vals.Gradient[Z];

  return(value>1.0 ? 1.0 : (value<0.0? 0.0:value));

which looks like what he wants. The "banded" pattern is the same as 
gradient, except it doesn't mirror around the origin, and the bands are 
always the same length.

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

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

> Sounds like a very good idea. I have some questions.
> I don't know the POV source but judging from the way some patterns 
> seem to work I suspect that many patterns in fact does exceed the 
> [0,1] range but there's some global function that applies the mod 
> function to all patterns before they are returned. Is this assumption 
> correct?

Yes. There is a point in Evaluate_TPat() immediately before the 
waveforms that does this, using the fmod() function:
  if (TPat->Frequency !=0.0)
  {
    value = fmod(value * TPat->Frequency + TPat->Phase, 1.00001);
  }


> And you are thinking of alternatives to this global "mod enforcement"?

Yes. Specifically, a "waveform_list {}" feature. The current ramp wave 
would simply be the default, and you could override it with whatever 
waveform you want. You could even apply multiple waveforms, one after 
the other...sort of like post_process filters for pattern waveforms.
This would require some changes to current patterns in order to be 
really useful...gradient would become a gradient from -infinity to 
+infinity, for example...but nothing should be noticeable from the 
user(except a possible speedup because of the lack of redundantly 
wrapping to the [0, 1] range).


> It sounds like a good idea. But exactly why does all patterns need to 
> be in the [0,1] range anyway? Why can't we allow any values in 
> patterns? To access those unlimited values you would simply allow all 
> values in color_maps too etc. I have never understood the reason for 
> this limitation.

It is just to make creating color_maps easier...and certain things are 
only possible when you know the maximum and minimum values of a range. 
It wasn't something they just threw in for no reason...imagine if every 
time you changed a pattern, you had to completely renumber the 
color_map...you would probably end up using a 0-1 color map and a 
separate multiplier value to fit it to each pattern.


> But back to the original topic. Say you made a "wave-type" that 
> clipped patterns at 0 and 1 instead of "mod"-ifying them. That solves 
> a third of my problem with the gradient pattern.

That is close to what I am thinking of, except I would overhaul the 
entire waveform code and allow you to specify min and max values for 
that waveform filter.


> Another third of the problem is that only the x, y, and z vector can 
> be used plus combination such as <1,0,1> or <1,1,1>. Other vectors 
> don't work. For example <2.5,0,0> is converted to <1,0,0> and 
> <0.1,0,3> is converted to <1,0,1>. Fixing this odd behaviour would 
> not break old scenes, but only add new functionality to the gradient 
> pattern. Could you do that too?

Hmm, I'd never noticed that limitation before...
It should be as simple as replacing these lines in gradient():
      temp = fabs(EPoint[i]);

      value += fmod(temp,1.0);
With this one line:
      value += fmod(fabs(TPat->Vals.Gradient[i]*EPoint[i]), 1.0);

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