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

Post a reply to this message

Forgot to add the warp which seems to be the actual culprit:

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

Post a reply to this message

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