Brett disagrees with my statement that
> > ... Concretely, you generate pixel by pixel, and you have to
> > operate upon an *updateable* frame buffer.
> I was planning on just writing the resultant image to a file.
> I'm not sure what I would gain by accessing an updateable frame
> buffer, as displaying the resultant image would be accomplished by
> some other program.
If you wish so...
Of course, you might produce a stream of pixels, and this is as
functional as any stream generation.
But I cannot stop thinking about a *serious* tracer with all
kind of standard optimizations, for example being able to
undersample the rendering and fill the holes by interpolation. This
doesn't need a full-fledged framebuffer either, but doing it while
generating a stream seems a bit clumsy.
And anyway, dumping this pixel stream into an output file will
be *much, much* more expensive than putting everything in an array.
===
I mentioned the shader language of Renderman-compatible packages.
Brett:
> The RT I am familiar with (Pov-Ray) also has its own specific language.
> This was also part of my motivation, as haskell seems like a very good
> replacement for it.
I don't think so. The POV language, as the Renderman RIB (and VRML,
etc.)
are *scene description languages*. Of course, Haskell is sufficiently
powerful to represent 3D objects, no problem. But this is very far
from the Ray Tracing engine. The external, linguistic descriptions of
objects and scenes are massaged quite a lot before becoming *fast*
representations, adapted to the RT algorithm. So Haskell "data" will
help the human user, but it should not be used as the object implemen-
tation language for the rendering. (IMHO)
On the other hand, the shaders are dynamical procedures, and here we
may play with the power of a higher-order FL as we really like it!
===
> I am unfamiliar with Clean. Is this a speed issue?
Yes. But Clean is a lazy, pure functional language which is very
similar to Haskell, so it is a matter of a few days to learn it.
It has some nice features, but as it is considered to be a conpetitor,
I should not elaborate upon this theme, because the Haskell
list gurus will electrocute me///
Jerzy Karczmarczuk
Caen, France
