Hi Margus,

It appears to me that this is not a bug, but rather is a visible effect
of the limitations on the precision of floating-point operations in
hardware.

The objects are being correctly parsed by POV-Ray, but during the
tracing computations there are problems with the magnitude of the values
the program must handle.  Each cone has a "Trans" (transformation)
matrix defined, which describes the placement of the object in the
coordinate space.  The "Trans" matrix and its inverse given below are
for the first misplaced segment of the "worm" shape in my rendering. 
(I've modified the scene somewhat, so don't be alarmed if you're crazy
enough to check them and find they don't match!!)

matrix
 0.99714285714286   0.00000000000000          0.00000000000000     
0.00000000000000
 0.00000000000000  -0.99714285714286          1.2211074785257e-016 
0.00000000000000
 0.00000000000000  -1.7095504699361e-013  -1396.0000000000         
0.00000000000000
-0.81466897165920   0.00000000000000       1399.9997622903         
1.0000000000000

inverse
 1.0028653295129    0.00000000000000          0.00000000000000     
0.00000000000000
 0.00000000000000  -1.0028653295129          -8.7722518182116e-020 
0.00000000000000
 0.00000000000000   1.2281152545497e-016     -0.00071633237822348  
0.00000000000000
 0.81700326670694  -1.7193610644346e-013      1.0028651592337      
1.0000000000000

There are 19 orders of magnitude between the smallest and largest values
in "matrix".  The x86 series floating point unit has a precision of
about 16-20 significant figures (I think), so most computations
(especially addition and subtraction) involving numbers of this
magnitude are going to suffer a severe loss of significant figures.

Given the way POV-Ray handles the cone primitive, there are two things
that worsen the problem:

- Having the axis of the cone coincide nearly (but not exactly) with the
Z-coordinate axis (I'm not sure why it's only the Z axis), and

- Having the sides of the cone very nearly (but not quite) parallel to
each other (ie. the two radii nearly equal).

Your 'worm' shape unfortunately has both of these characteristics.

Cylinders use a different method of computation and will not suffer from
the same problem.  Although they are not entirely immune to the effects
of floating-point precision, they are less prone to error under similar
circumstances.  Cones with equal radii are treated by POV-Ray the same
as cylinders and hence do not have this problem.

I can't find any way of proving that it's a floating point precision
problem, but it's got all the characteristics of one.


Cheers,

Darius Davis

Post a reply to this message