[grt-talk] Accuracy bug

[Nikodemus Siivola]

Ok, I've tracked down the cause of dots in the scene mentioned:

$ cvs diff -u trace.lisp
Index: trace.lisp
===================================================================
RCS file: /cvsroot/grt/grt-lisp/trace.lisp,v
retrieving revision 1.20
diff -u -r1.20 trace.lisp
--- trace.lisp  17 Apr 2003 17:56:37 -0000      1.20
+++ trace.lisp  24 Apr 2003 00:56:33 -0000
@@ -72,9 +72,9 @@
         (L (vector-div l-o len)))
     (values (make-ray :origin (vector-adjust origin
                                             (ray-hit-normal ray)
-                                            +grt-epsilon+)
+                                            (* 10 +grt-epsilon+))
                      :direction L)
-           (- len +grt-epsilon+)
+           len
            L)))

I have not checked this in however, since it doesn't the problem, only
the symptom: the problem is on the inaccuracies introduced by the
transformations. (I think, not dead certain yet.)

If I put the camera at '(0 600 0) and increase the sphere-size to 10 the
problem reappears. :( Since I really don't like the idea of increaing the
shadow-epsilon as the scale increases we have to look into other solutions:

 * Double floats (we should benchmark with them versus single floats
   anyway to see if there really is any difference). I think we could
   reserve single-floats for data with large storage requirements (meshes),
   and use doubles normally. I doubt this would solve this problem though.
   Ease it maybe, but not solve.

 * See if there is a workble, but "relatively big" shadow epsilon
   that is big enough to aoid the degradation on any scale *without*
   causing other problems.

 * Check if this problem appears with the old-style spheres as well.

 * Check the transformation logic. (Do we do any unnecessary
   transformations? Avoiding them would be a speed gain as well.)
   Do we do the intersection testing in a reasonable space?
   Are there other options?

Before this is solved I'd like also to take the opportunity to change
the scene-object model:

 * Call them primitives instead (avoid confusion with OO)

 * Build to prototypes side by side: one with classes and
   inheritance, the other with structs PRIMITIVE, SHAPE
   and TEXTURE. Then benchmark them. Use the better one.
   (Note, this is just slot-access, no defmethods involved).

Of course, it may turn out that fixing the rotate-bug will
ease this one as well. Remains to be seen.

Cheers,

  -- Nikodemus