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