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

[Andrew Coppin]

Jim Snow wrote: 
> 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.

Wow. The POV-Ray guys are talking about Haskell [or rather, my personal 
addiction to it] and the Haskell guys are talking about POV-Ray... on 
the same day... How unlikely is that? ;-)

I've been using POV-Ray for a long time. I like it for several reasons:

1. It's the only program I've ever seen [on a PC] that does ray tracing. 
[I'm sure there must be others...]
2. It's the only program I've seen that can render *real* curves, not 
fake trickery with triangle meshes.
3. It can render *arbitrary* mathematical surfaces. Want to render a 3D 
slice of the 4D cubic Mandelbrot set? No problem!
4. It has a novel "scene description language", which does far more than 
describe scenes. It's Turing-complete, and you can build physics engines 
with it. [It's painfully slow though!]

Basically, as a maths addict, POV-Ray appeals to me. However, there are 
problems... The scene description language is basically a macro 
expansion language, and is chronically poor in data types and control 
structures. (The worst thing about Haskell is that IT MAKES YOU HATE 
NORMAL LANGUAGES!) Preserving complex scene state from frame to frame in 
an animation is notoriously tedious to code. Certain features are 
accessed in unintuitive ways to avoid breaking backwards compatibility. 
Overall, you tend to spend a lot of time saying which effects to 
simulate. [Not all of them matter for a given scene, so some can be left 
out - thus saving on speed!] I dislike such "clutter". For no objective 
reason.

The POV-Ray team is currently working on the first multi-threaded 
version. [After years of saying it would never happen.] It's taking a 
while. (That's partly because the developers take product quality very 
seriously.) It should be interesting when it's done, but it's still 
taking a while.

Personally, I'd quite like to write my own ray tracer to address some of 
these limitations. But every time I try, I end up hitting design issues 
[Haskell works very differently to Java] or performance issues [which I 
don't even know how to begin debugging]. Not to mention that POV-Ray 
uses sophisticated techniques like volume bounding that I know nothing 
about. (There's nothing like using an inherantly superior algorithm to 
make your code orders of magnitude faster...)

> 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.

Indeed - yay for Simon!