[Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer)

[Jim Snow]

Derek Elkins wrote:
>
> Ingo Wald's work on interactive coherent raytracing springs to mind.
> http://www.sci.utah.edu/~wald/Publications/
>
> "Interactive Rendering with Coherent Raytracing"
> http://graphics.cs.uni-sb.de/~wald/Publications/EG2001_IRCRT/InteractiveRenderingWithCoherentRayTracing.pdf
> is a decent, if dated, introduction.  He clearly has much more newer stuff as well.
>
>   
Those are good links.  It's good to see that the groups of people who 
know about Haskell and people who know about ray tracing do, in fact, 
overlap.

Background information for everyone else:  Wald's work is related to 
OpenRT, which is an OpenGL-like api for interactive ray tracing  
(despite the name, it is not, in fact, open source).  OpenRT makes for 
stiff competition.  Arauna (http://igad.nhtv.nl/~bikker/) is very 
impressive, as well.  On the other end of the spectrum, there's POV-Ray, 
which isn't known for its speed, but it is very flexible in the kinds of 
things it can render and can generate some fairly realistic images.  
Unlike most real-time ray tracers, which only render triangles, POV-Ray 
can render native representations of spheres, cones, toruses, 
heightfields, julia fractals, and a few dozen other kinds of 
primitives.  Pbrt (http://www.pbrt.org/) is another renderer, more 
modern than POV-Ray, that focuses more on output quality than speed.

Unfortunately, all the notable ray tracers that I'm aware of are written 
in C or C++ (often with a little hand-coded SSE), and as you might 
imagine I find this to be a sad state of affairs.  Not that those are 
bad languages for this kind of work, but they shouldn't be the only option.

I've ended up writing something more like POV-Ray than OpenRT, and 
that's fine with me.  I'd rather have something that's slower but more 
expressive than fast but inflexible.  (The former is also perhaps more 
easily attainable, particularly in Haskell.) 

This isn't to say that I'm not interested in making it fast as well.  
There are plenty of ways to make my raytracer faster: Kd-trees built 
using a surface area heuristic performed better than naively-built BIH 
when I implemented them in my ocaml raytracer (though they take longer 
to construct).  If I can figure out how quaternions work, I could 
probably use them instead of transformation matricies to store cones in 
order to cut down on memory overhead (4 floats versus 24, if I 
understand correctly).  Ray packets, as described in Wald's paper linked 
above, might help as well.

Simon Marlow wrote:
> There's definitely a bug here, regardless of whether this example 
> demonstrates it.  Use of par shouldn't introduce a space leak, and 
> currently it can.
>
> (fortunately I'm fixing it as we speak...)
>
> Cheers,
>     Simon 
Oh, good.

-jim