[Haskell-cafe] Announce: glome-hs-0.51 (Haskell raytracer, now with type classes)

[Jim Snow]

A new version of my raytracer has been posted:

http://syn.cs.pdx.edu/~jsnow/glome/
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/glome-hs-0.51

(This should really be named 0.5.1, but I didn't think of that until 
after I uploaded it to hackage.)

There's not much new functionality, but it now uses type classes for the 
supported primitives, and has been optimized a bit more.  Much of the 
tutorial I hastily wrote for 0.4.x 
(http://www.haskell.org/haskellwiki/Glome_tutorial) is now quite out of 
date.

Most of the primitives have been moved to their own module, with the 
exception of SolidItem (an existential type used to make composite 
primitives), [SolidItem] (allowing me to treat lists of Solids like 
single solids), Void (a non-object, equivalent to []::[SolidItem]), and 
Instance (used for transformations).  It might be possible to move those 
to their own modules as well, but it would require mutual recursion 
between modules, and that's probably more trouble than it's worth.  (I 
made an attempt at that, but I quickly gave up.)

I also gave up on trying to use a global mutable variable to count the 
number of bounding hierarchy nodes a particular ray hits; instead, I 
added rayint_debug, which behaves just like rayint (the standard 
ray-object intersection routine), except that it returns an integer 
(that I can use to count whatever I like) along with the ray 
intersection.  Using a global counter in this instance would have been 
much simpler, but I don't think I understand "seq" well enough to be 
able to force the increment to actually happen.

http://syn.cs.pdx.edu/~jsnow/glome/Screenshot-glome-hs-bih.png

The resulting renders can be very useful to determine where Glome is 
spending most of its time, and to verify that the the bounding interval 
hierarchy is really doing the right thing.

I also added packet tracing, which makes it possible to trace four rays 
at a time, using a specialized ray intersection method "packetint".  
(This is a common technique to amortize the acceleration structure's 
memory lookup cost over multiple rays.)  It seemed to be a big win when 
I first implemented it before converting over to type classes, but now 
it seems to be faster without it, so I probably made a mistake somewhere.

A cosmetic change is that Glome now renders into a drawlist instead of 
directly to the screen, so the whole image doesn't get laboriously 
re-traced whenever there's window damage.  Unfortunately, that means you 
can't watch as it draws anymore, which was a useful way of knowing which 
parts of the image were slow to render.

I've started looking more seriously into optimization (suggestions 
welcome).  Don Stewart's blog post 
(http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16#fast) was quite 
useful, but it seems like there's a lot of arcane knowledge required to 
understand what's really happening in "core" code.  Is there any better 
reference than Andrew Tolmach's paper "An External Representation for 
the GHC Core Language (2001)" 
http://citeseer.ist.psu.edu/tolmach01external.html?

-jim