|
 |
I've been running into errors with one of my supersurface tests:
<code>
// Parametric variable form
#declare uMin = 0; // Minimum u value
#declare uMax = radians(180); // Maximum u value
#declare uNum = 90; // Number of points in u direction
#declare uWrap = 0; // u wraps around if != 0
#declare uSeed = 2252; // Random number seed for u parameter
#declare vMin = 0; // Minimum v value
#declare vMax = radians(356); // Maximum v value
#declare vNum = 90; // Number of points in v direction
#declare vWrap = 1; // v wraps around if != 0
#declare vSeed = 7335; // Random number seed for v parameter
#declare IsRnd = false; // True if random number used
#declare IsUV = true; // True if uv-mapping used
#declare Smooth = 1; // Smooth flag
#declare Detail = "Partial"
/* Detail values
Verbose = Line by line details
Partial = Operations only
Other = Filename only
*/
/* For all macro functions
i = Current value of u parameter
j = Current value of v parameter
p = Current value of u variance (0...1)
q = Current value of v variance (0...1)
*/
// Optional functions
#macro rd(a,b,m,n1,n2,n3,th)
#local ra = abs(cos(m*th*0.25)/a);
#local rb = abs(sin(m*th*0.25)/b);
pow(pow(ra,n2)+pow(rb,n3),-1/n1)
#end
#macro pof(n,ex,of) pow((n+of)*(n+of),ex*.5)-of #end
#declare a1=pi+2;
#declare b1=pi-2;
#declare m1=5.5;
#declare n11=1.50;
#declare n21=1.75;
#declare n31=1.25;
#declare a2=phi(2);
#declare b2=phi(3);
#declare m2=1;
#declare n12=0.30;
#declare n22=-.25;
#declare n32=-.35;
// point function
#macro pnt(i, j, p, q)
#local rdi = rd(a1,b1,m1,n11,n21,n31,i+1e-3); // altered
#local rdj = rd(a2,b2,m2,n12,n22,n32,j+1e-3);
#local si = sin(i);
#local ci = cos(i);
#local sj = sin(j);
#local cj = cos(j);
/*torus
#local xp = sj*(rdj+rdi*si);
#local yp = cj*(rdj+rdi*si);*/
//sphere
#local xp = rdj*cj*rdi*si;
#local yp = rdj*sj*rdi*si;
#local zp = rdi*ci;
#local dz = pof(zp, 1.3, 4.5);
<xp+.1*dz,zp,yp>
#end
</code>
Certain values of th, particularly 0, in the rd macro results in a NaN (Not
a Number) from dividing by 0 if n2 or n3 are negative. A quick, dirty
workaround was the code marked "altered" which ensured that th never hit 0,
pi/2, pi, etc.
I use the code above to generate large mesh2 objects. The errors were not
being caught until POV-Ray parsed the meshes, usually several minutes. I
want to catch these errors more quickly and flag them with #error
directives, causing quick failure the instant one of these calculations goes
awry.
So, what is the fastest and easiest way to detect NaN floats and vectors?
-----------------------------
David Wallace
TenArbor Consulting
"Just In Time Cash"
www.tenarbor.com
Post a reply to this message
|
|
|
|
David Wallace <dar### [at] earthlink net> wrote:
> So, what is the fastest and easiest way to detect NaN floats and vectors?
There isn't.
What happens eg. with a division by 0 is completely system-dependant,
and even whether you get a 'NaN' value or something else is
system-dependant. (In fact, the 'NaN' value itself is system-dependant
because not all architectures implement the IEEE floating point numbers.)
There's no portable way of testing "is this value a NaN?".
The only way you can prevent it from happening is to test the
operands of the division prior to performing the division.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
