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!
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
