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