Rob,

> All, the task has been posted!   Wow!  It sounds really neat (and
> difficult)

I just read over it and for really solving the problem in Squeak you have to
'objectify' it. FWIW, here's my take on it: First of all, the parser needs
to create Squeak compiled methods rather than a symbolic representation (for
speed). Then, you'll need a bunch of objects that define the different
objects used in GML (such as cone, sphere, intersection, union etc) which
allow you to specialize the intersection tests appropriately. Then, each
object creation should define a unique subclass of these base classes so
that the shading functions can be compiled directly into the objects.

> Andreas, please say you'll help!  ;-)

Hmmmm. I'm not quite sure. I have just come back from a trip into the middle
of nowhere (actually the middle of New Hampshire but for me that's pretty
much the same ;-) and wasn't planning on spending my weekend in a rush
(deadlines and so). Also, I'm not really interested in any of the functional
stuff - the only thing that would be interesting to me is the actual
rendering (and how to make it fast). So ... what I can do is to look a bit
into the fun part (rendering). If you're interested (and not too badly
suprised if it doesn't quite work out), here's what I can do:
* Give you the lighting model (Squeak's 3D engine contains basically the
same lighting model)
* Give you the intersection tests (it's all in the CG bible)
* Have a look at optimizing the render() function with a few, really simple
tricks (this is likely to involve that you don't insist on rendering the
image top-down, left-right but do have a way of writing into arbitrary
positions in the output file)

[Eventually - if I'm really crazy - I might even look into precomputing
texture maps]

Oh, and one important question - can we use Squeak's 3D engine or is this
considered cheating?! If so, we might actually be *very* fast... ;-))

  - Andreas