POV-Ray : Newsgroups : povray.general : Weirdnesses with function patterns : Re: Weirdnesses with function patterns Server Time
29 Jul 2024 00:35:45 EDT (-0400)
  Re: Weirdnesses with function patterns  
From: clipka
Date: 8 Dec 2013 15:02:12
Message: <52a4d044$1@news.povray.org>
Am 08.12.2013 19:17, schrieb David Given:

> Instead what happens is the return value of the function is clipped into
> the [0..1] range.

This is consistent with each and every other pattern, and entirely 
intentional.

> This could be intentional; however, if it is, then this behaviour isn't
> documented, and the actual implementation that makes it happen seems a
> little confused, which makes me suspect that's it's not intended.
>
> The code comes in two parts: this in function_pattern:
>
> 	return ((value > 1.0) ? fmod(value, 1.0) : value);
>
> ....which wraps *positive* values, and this in Evaluate_TPat, which wraps
> *negative* values.
>
> 	if(TPat->Frequency != 0.0)
> 		value = fmod(value * TPat->Frequency + TPat->Phase, 1.00001); // TODO
> FIXME - magic number! Should be 1.0+SOME_EPSILON (or maybe actually 1.0?)
>
> 	/* allow negative Frequency */
> 	if(value < 0.0)
> 		value -= floor(value);
>
> Because positive values are only wrapped in function_pattern, then this
> means that positive values returned by non-function patterns aren't
> wrapped at all!

All other patterns take care of the wrapping by themselves. The wrapping 
of negative values is only there (or so the comment implies) because the 
value could be transformed into the negative domain by multiplying with 
TPat->Frequency. (Like the % operator, fmod preserves the sign of the 
first operand.)

The only inconsistency here is that the function pattern does not handle 
negative values itself, and instead apparently relies on the 
Evaluate_TPat code to take care of that.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.