SharkD schrieb:
> #local Temp_fnc1 = function {pigment {spherical}}
> #local Temp_fnc3 = function
> {
>     Temp_fnc1(x, log(y + 1) / log(2),z).gray
> }
> 
> The image actually *renders* most of the way. But about 3/4 done it 
> quits with the error, "Parse Error: Floating-point exception detected in 
> function 'Temp_fnc3'. Your function either attempted a division by zero, 
> used a function outside its domain or called an internal function with 
> invalid parameters."
> 
> Aren't parse errors supposed to occur *before* the image begins 
> rendering?

This is nothing that could be caught during parsing. After all, how is 
POV-Ray supposed to know whether or not the function will be called with 
parameters value that will cause one of the sub-expressions to operate 
on invalid operands?

For instance, if your function is

     function { 1 / (x+1) }

then how should POV-Ray know whether you will make sure it isn't called 
for any x smaller than -1?

 > How do I fix it?

The problem is most likely the subexpression

     log(y + 1)

which is undefined for any y <= -1. So make sure the pattern's native 
range of y <= -1 is always outside whatever object it is applied to.

Or clip the parameter to a safe range, e.g.:

     #local Temp_fnc3 = function
     {
         Temp_fnc1(x, log(max(0.0001,y+1)) / log(2),z).gray
     }

which forces the parameter for log() to be no smaller than 0.0001.

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> Aren't parse errors supposed to occur *before* the image begins 
> rendering?

  It should be labeled "rendering error" rather than "parse error".
Only a cosmetic problem, but perhaps worth a bug report.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> SharkD <mik### [at] gmailcom> wrote:
>> Aren't parse errors supposed to occur *before* the image begins 
>> rendering?
> 
>   It should be labeled "rendering error" rather than "parse error".
> Only a cosmetic problem, but perhaps worth a bug report.
> 

How about "post-rendering parse error"?

-Mike

Post a reply to this message

clipka wrote:
> This is nothing that could be caught during parsing. After all, how is 
> POV-Ray supposed to know whether or not the function will be called with 
> parameters value that will cause one of the sub-expressions to operate 
> on invalid operands?
> 
> For instance, if your function is
> 
>     function { 1 / (x+1) }
> 
> then how should POV-Ray know whether you will make sure it isn't called 
> for any x smaller than -1?
> 
>  > How do I fix it?
> 
> The problem is most likely the subexpression
> 
>     log(y + 1)
> 
> which is undefined for any y <= -1. So make sure the pattern's native 
> range of y <= -1 is always outside whatever object it is applied to.
> 
> Or clip the parameter to a safe range, e.g.:
> 
>     #local Temp_fnc3 = function
>     {
>         Temp_fnc1(x, log(max(0.0001,y+1)) / log(2),z).gray
>     }
> 
> which forces the parameter for log() to be no smaller than 0.0001.

As I pointed out in my second post, the error only occurs after I apply 
the turbulence warp.

-Mike

Post a reply to this message

SharkD wrote:
> I'm using the following pigment:
> 
> #local Temp_fnc1 = function {pigment {spherical}}
> #local Temp_fnc3 = function
> {
>     Temp_fnc1(x, log(y + 1) / log(2),z).gray
> }
> 
> 
> The image actually *renders* most of the way. But about 3/4 done it 
> quits with the error, "Parse Error: Floating-point exception detected in 
> function 'Temp_fnc3'. Your function either attempted a division by zero, 
> used a function outside its domain or called an internal function with 
> invalid parameters."
> 
> Aren't parse errors supposed to occur *before* the image begins 
> rendering? How do I fix it?
> 
> -Mike

Oops! I made a mistake when copying the function. Here's the actual code:

#local Temp_fnc1 = function
{
	1 - min(1, sqrt(x*x + y*y + z*z))
}
#local Temp_fnc3 = function
{
	max(0,min(1,Temp_fnc1(x, log(y + 1) / log(2),z)))
}

And the warp:

warp
{
	turbulence	<1/4,1/64,1/4,>
	octaves		4
	lambda		2
	omega		1/2
}

Post a reply to this message

SharkD schrieb:
>>   It should be labeled "rendering error" rather than "parse error".
>> Only a cosmetic problem, but perhaps worth a bug report.
>>
> 
> How about "post-rendering parse error"?

Would not make any sense at all, as rendering does not start until 
parsing has completed.

Post a reply to this message

SharkD schrieb:
> As I pointed out in my second post, the error only occurs after I apply 
> the turbulence warp.

Probably because the object normally doesn't touch the "dangerous" 
range, but the warp pertubs the coordinates in such a way that the 
pattern's original y<=-1 range ends up "exposed".

Post a reply to this message

clipka wrote:
> SharkD schrieb:
>> As I pointed out in my second post, the error only occurs after I 
>> apply the turbulence warp.
> 
> Probably because the object normally doesn't touch the "dangerous" 
> range, but the warp pertubs the coordinates in such a way that the 
> pattern's original y<=-1 range ends up "exposed".

Is it possible to do use an IF statement to substitute a different 
function where y<=-1?

-Mike

Post a reply to this message

SharkD wrote:
> clipka wrote:
>> SharkD schrieb:
>>> As I pointed out in my second post, the error only occurs after I 
>>> apply the turbulence warp.
>>
>> Probably because the object normally doesn't touch the "dangerous" 
>> range, but the warp pertubs the coordinates in such a way that the 
>> pattern's original y<=-1 range ends up "exposed".
> 
> Is it possible to do use an IF statement to substitute a different 
> function where y<=-1?
> 
> -Mike

Changing the second function to this seems to fix it:

#local Temp_fnc3 = function
{
   max(0,min(1,Temp_fnc1(x,log(max(y + 1,0.000000000001))/log(2),z)))
}

Post a reply to this message

SharkD wrote:
> SharkD wrote:
>> I'm using the following pigment:
>>
>> #local Temp_fnc1 = function {pigment {spherical}}
>> #local Temp_fnc3 = function
>> {
>>     Temp_fnc1(x, log(y + 1) / log(2),z).gray
>> }
>>
>>
>> The image actually *renders* most of the way. But about 3/4 done it 
>> quits with the error, "Parse Error: Floating-point exception detected 
>> in function 'Temp_fnc3'. Your function either attempted a division by 
>> zero, used a function outside its domain or called an internal 
>> function with invalid parameters."
>>
>> Aren't parse errors supposed to occur *before* the image begins 
>> rendering? How do I fix it?
>>
>> -Mike
> 
> Oops! I made a mistake when copying the function. Here's the actual code:
> 
> #local Temp_fnc1 = function
> {
>     1 - min(1, sqrt(x*x + y*y + z*z))
> }
> #local Temp_fnc3 = function
> {
>     max(0,min(1,Temp_fnc1(x, log(y + 1) / log(2),z)))
> }
> 
> And the warp:
> 
> warp
> {
>     turbulence    <1/4,1/64,1/4,>
>     octaves        4
>     lambda        2
>     omega        1/2
> }

The above function transforms the sphere such that it is expanded 
logarithmically along the y axis. What I would like to do next is to 
expand it based on its distance from the origin instead. Any ideas?

-Mike

Post a reply to this message