Re: [grt-talk] Some suggestions.

[Nikodemus Siivola]

On Wed, 30 Apr 2003, Anton N. Mescheryakov wrote:

> 1) People, I'm puzzled by way you implement vector math. Records, er?
> Correct me if I'm wrong but records are implemented as lists or vectors,
> mostly unspecialized.

Not in CMUCL at least.

> If you don't care about optimization (good point,
> BTW. As Knuth said "premature optimization is a root of all errors" or
> so), why do you 'declare so much? The same thing is with colors. BTW, is
> the RGBA scheduled? Why do you bother with destructuring while you can
> simply use off-the-shelf sequence grinding stuff like 'map, 'reduce and
> so on?
> 2) The way the GRT is written isn't especialy lispish. In some parts it
> definitely resembles mundane languages like C, Fortrash (sic) and so on.

RGBA: Yes, it's planned, but not scheduled. Alpha channel is property of
compuper-color, not real color. Objects can have filtering or non-filtering
transparency already, but we need to figure out how to allow the creation
of _images_ with alpha channel without introducing it to our scenes -- or
if this is possible at all. If not, than the color-handling needs a
slightly cleaner separation so that we can provide for multiple
color-spaces.

This brings me to one unstated design philosophy of mine. There are a lot
of things in rendering that are the "done thing". 99% of them are so
for a very good reason, but I'd like them to be incorporated into GRT with
an understanding of _why_, not because it's the "done thing".

Take for example phong higlights. Higlights are reflections of
light-sources, nothing else. The normal approach is to make phong a
property of object surface. For 0.2 I'm planning a "smart" phong that will
be an inferred property for non-visible light sources, based on their
virtual size and the reflectivity of the object surface.  Light-sources
that have a "looks-like" attribute will not get phang, but will insteas be
just reflected. This may turn out to be non-workable and silly, but at
least we'll know. And if it works, we're in for an article in the
Raytracing News... ,)=

As for the rest, there are several things at work here:

* Things like grt-vector-bind are leftovers from my first incursions into
CL, slowly disappearing from the CVS HEAD. (Btw, for hacking on GRT I
definitely recommend the CVS version as opposed to 0.1). Fixes are always
welcome.

* The line between premature optimizations and paing attention to
efficiency is a fine one, but I believe that you ave to pay attention to
numerical efficiency when writing a raytracer.

There are a number of unnecassary declarations in 0.1, but finding the
optimal set to get type inference working sufficently well across
implementations is non-trivial. In CVS HEAD a number of DECLARE's have
become (DECLAIM (FTYPE ...))'s, which for CMUCL at least is more useful.
In general, however, declarations make a difference of an order or
magniture or more in the speed: this is quite relevant. I prefer to
render a test-scene in 10 seconds as opposed to 100 seconds...

In case of vector-math my tests indicated that structs were fastest by a
significant degree over anything else. It might be that with proper
declarations '(array single-float (3)) is as fast, especially with sequence
functions. Patches are welcome.

* I'm no certain what you mean by non-lispish. If it's something not
covered above, please tell. On the other hand, I do have to admit that
the CSG code (or the beginning thereof) makes me all warm and fuzzsy
inside:

(defun csg-intersection-intersect-all (obj-a obj-b)
  (lambda (ray)
    (flet ((inside-p (obj) (lambda (d) (inside-p obj (ray-point ray d)))))
      (merge '(vector grt-float)
             (remove-if-not (inside-p obj-b) (intersect-all obj-a ray))
             (remove-if-not (inside-p obj-a) (intersect-all obj-b ray))
             #'<))))

> 3) *scene* is evil. Let's do 'with-scene, please? Something like
> allegro-serve 'html macro:

The scene-creation interface is a tough one. Originally it wen't something
like this:

(let ((scene (make-scene :backgound-color +black+)))
   (scene-add scene (sphere 1.0 +O+))
   ...)

The explicit provision of the scene to insert things into turned out to be
a major pain. *scene* and the scene -function are a slightly less painfull
(but admittedly ugly) alternative.

I like the with-scene, though. This needs thinking about, and I'm somewhat
hesitant to turn the basic scene-creation method into a giant macro.
There is also the question of less than trivial scenes (say anything with
over 1000 lines of code): the interface has to be nice for them as well.

All this makes me think that we need a couple of alternative interfaces for
scene creation. Or a single very smart one. ,)

Cheers,

  -- Nikodemus