Ok... there seems to be a bug in POV's sphere scaling code.  If you have a
sphere and you scale it uniformly, it will simply multiply the radius by your
scale factor instead of using a transformation matrix.  This is a speed
improvement under some circumstances, but it seems to lead to a bug when
the radius is veryu small.  Also, starting with a small radius leads to the
same problem.  the sphere gets smaller than it should.  Below is code that
shows two spheres lined up on the x axis.  The sphere on the right is
scaled by 0.005, while the sphere on the left is scaled by
<.005,.005,.00501> This forces the sphere on the right to use the
transformation instead of a very small radius, so it renders properly.

This is getting sent to Chris Young and to povray.programming.

-Nathan Kopp

---------------------------------------------------

// This scene was originally generated by Moray.

background { color <0.000,0.000,0.000> }

camera {  //  Camera StdCam
  location  <      0.000,     -25.000,       0.000>
  direction <        0.0,         0.0,   1097.8478> // Aperture is 0.07 degrees
  sky       <    0.00000,     0.00000,     1.00000> // Use right handed-system
(rotated by 0.00 degrees)!
  up        <        0.0,         0.0,         1.0> // Where Z is up
  right     <    1.33333,         0.0,         0.0> // Aspect ratio
  look_at   <      0.000,       0.000,       0.000>
}


light_source {   // Light1
  <0.000, -20.000, 20.000>
  color rgb <1.000, 1.000, 1.000>
}

#declare Texture1 = 
   texture { pigment {  color rgb <0.0, 1.0, 0.0>  } }

sphere { // Sphere001
  <0,0,0>,1
  texture { Texture1 }
  scale 0.005
  translate  0.005*x
}

sphere { // Sphere2
  <0,0,0>,1
  texture { Texture1 }
  scale <0.005, 0.005, 0.00501>
  translate  -0.005*x
}

Post a reply to this message

In article <36045E84.18242E1E@ltu.edu> , Nathan Kopp <nk8### [at] ltuedu>  wrote:
>Ok... there seems to be a bug in POV's sphere scaling code.  If you have a
>sphere and you scale it uniformly, it will simply multiply the radius by your
>scale factor instead of using a transformation matrix.  This is a speed
>improvement under some circumstances, but it seems to lead to a bug when
>the radius is veryu small.  Also, starting with a small radius leads to the
>same problem.  the sphere gets smaller than it should.  Below is code that
>shows two spheres lined up on the x axis.  The sphere on the right is
>scaled by 0.005, while the sphere on the left is scaled by
><.005,.005,.00501> This forces the sphere on the right to use the
>transformation instead of a very small radius, so it renders properly.
>
>This is getting sent to Chris Young and to povray.programming.
>
>-Nathan Kopp

This is interesting! On my Mac it renders OK!!! Obviously this is a precision problem
because it I decrease the size by a factor of ten, I get (finally) the same problem.


Thorsten


PS: Now it is proven! The Macintosh is better for rendering than a PC!!! :-)

____________________________________________________
Thorsten Froehlich, Duisburg, Germany

Post a reply to this message

On Sat, 19 Sep 1998 21:46:45 -0400, Nathan Kopp <nk8### [at] ltuedu>
wrote:

>Ok... there seems to be a bug in POV's sphere scaling code.  If you have a
>sphere and you scale it uniformly, it will simply multiply the radius by your
>scale factor instead of using a transformation matrix.  This is a speed
>improvement under some circumstances, but it seems to lead to a bug when
>the radius is veryu small.  

Here's the culprit, from the windows config.h file:

#define EPSILON 1.0e-5

I changed this to 

#define EPSILON 1.0e-12

and, for good measure, added

#define SNGL double
#define COLC double

and the problem went away.

Post a reply to this message

Sorry, I forgot to mention that this was with POV-Ray for WINDOWS.  One thing
that I'm interested in, too, is how much of a speedup the multiply-the-radius
optimization provides.  Although I guess that when it comes to ray-tracing,
any little speedup helps!

-Nathan

Ronald L. Parker wrote:
> 
> Here's the culprit, from the windows config.h file:
> 
> #define EPSILON 1.0e-5
> 
> I changed this to
> 
> #define EPSILON 1.0e-12
> 
> and, for good measure, added
> 
> #define SNGL double
> #define COLC double
> 
> and the problem went away.

Post a reply to this message

On Sun, 20 Sep 1998 14:52:45 -0400, Nathan Kopp <nk8### [at] ltuedu>
wrote:

>Sorry, I forgot to mention that this was with POV-Ray for WINDOWS.  One thing
>that I'm interested in, too, is how much of a speedup the multiply-the-radius
>optimization provides.  Although I guess that when it comes to ray-tracing,
>any little speedup helps!

Erm... my fix was for pov-ray for windows, too.  Look in the windows
directory for a file called config.h.  Change epsilon and add those
other two #defines.  Recompile.  Your spheres now render the same
size.  But who knows why epsilon was so big or what else this change
might break in heightfields etc.

Compared to using an ellipsoid intersection routine, I suppose the
speedup is probably pretty good.

Post a reply to this message

On Sun, 20 Sep 1998 18:59:56 GMT, par### [at] mailfwicom (Ronald L.
Parker) wrote:

>On Sun, 20 Sep 1998 14:52:45 -0400, Nathan Kopp <nk8### [at] ltuedu>
>wrote:
>
>>Sorry, I forgot to mention that this was with POV-Ray for WINDOWS.  One thing
>>that I'm interested in, too, is how much of a speedup the multiply-the-radius
>>optimization provides.  Although I guess that when it comes to ray-tracing,
>>any little speedup helps!
>
>Erm... my fix was for pov-ray for windows, too.  Look in the windows
>directory for a file called config.h.  Change epsilon and add those
>other two #defines.  Recompile.  Your spheres now render the same
>size.  But who knows why epsilon was so big or what else this change
>might break in heightfields etc.

Oops... changing COLC to a double breaks Moray's preview.  Better
leave that one alone.

Post a reply to this message

Ronald L. Parker wrote:
> 
> Here's the culprit, from the windows config.h file:
> 
> #define EPSILON 1.0e-5
> 
> I changed this to
> 
> #define EPSILON 1.0e-12


Funny : I was just looking over the UNIX code earlier today and
was pretty sure on that system EPSILON was 10^-10 .  It didn't exhibit
the scaling bug, which I had no problem producing on my Windows versions.

But there is another issue, which is how the calculation is done.
A segment of spheres.c follows:

> int Intersect_Sphere(Ray, Center, Radius2, Depth1, Depth2)
> RAY *Ray;
> VECTOR Center;
> DBL Radius2;
> DBL *Depth1, *Depth2;
> {
>   DBL OCSquared, t_Closest_Approach, Half_Chord, t_Half_Chord_Squared;
>   VECTOR Origin_To_Center;
> 
>   Increase_Counter(stats[Ray_Sphere_Tests]);
> 
>   VSub(Origin_To_Center, Center, Ray->Initial);
> 
>   VDot(OCSquared, Origin_To_Center, Origin_To_Center);
> 
>   VDot(t_Closest_Approach, Origin_To_Center, Ray->Direction);
> 
>   if ((OCSquared >= Radius2) && (t_Closest_Approach < EPSILON))
>   {
>     return(FALSE);
>   }
> 
>   t_Half_Chord_Squared = Radius2 - OCSquared + Sqr(t_Closest_Approach);
> 
>   if (t_Half_Chord_Squared > EPSILON)
>   {
>     Half_Chord = sqrt(t_Half_Chord_Squared);
> 
>     *Depth1 = t_Closest_Approach - Half_Chord;
>     *Depth2 = t_Closest_Approach + Half_Chord;
> 
>     Increase_Counter(stats[Ray_Sphere_Tests_Succeeded]);
> 
>     return(TRUE);
>   }
> 
>   return(FALSE);
> }
> 

Note the test : t_Half_Chord_Squared, of order distance^2, 
is compared to epsilon.  I would expect a test of the following
form might be less prone to scaling artifacts :

>   if (t_Half_Chord_Squared > EPSILON * Radius2)

or, equivalently (and faster) :

>   t_Half_Chord_Squared_N = 1 - (CSquared + Sqr(t_Closest_Approach)) / Radius2;
...
>   if (t_Half_Chord_Squared_N > EPSILON)
...
>   Half_Chord = sqrt(Radius2 * t_Half_Chord_Squared_N)

There are many other ways in which one could try and preserve scale
invariance of these tests.

Dan

-- 
http://www.flash.net/~djconnel/

Post a reply to this message

> Erm... my fix was for pov-ray for windows, too.  Look in the windows
> directory for a file called config.h.  Change epsilon and add those

Yes... I just wanted to make sure everyone else knew that I noticed it in
Windows and that other platforms may not have the same problem... but it
looks like everyone figured that out anyway.  :-)

I have a feeling that changing SNGL to a double might also cause problems
with GUI extensions, but I'm not totally sure.

-Nathan Kopp

Post a reply to this message