Andrew Coppin wrote:
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? ;-)
That's odd; I had a personal addiction to POV-Ray for a few years, and
just now have started using Haskell.
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!]
The Scene Description Language (SDL) is the best and worst thing about
POV-Ray. It's very intuitive and user-friendly, so a person can
reasonably write a complex scene in pure code without using an external
GUI editor. Unfortunately, the SDL is so complex it's well-nigh
impossible to support in other third-party applications. It's also
slow. I don't know if this is still the case, but the standard way of
doing an animation was to reference a "clock" variable in your scene
source code that went from 0 to 1; for instance, a command to make a
swing swing back and forth might looks like this:
"rotate 15*sin((clock/2)*seconds*(2*pi)-((2/3)*pi))*x"
"seconds" here is a variable set to the number of seconds in the
animation, and "x" is the X axis unit vector <1,0,0>. The (2/3)*pi
thing is to make it swing out of phase with the other swings.
(this rather obfuscatory example taken from an actual ancient povray
source file, you can see a rendering here:
http://syn.cs.pdx.edu/~jsnow/playground.png)
The scene then has to be re-parsed for every frame. For complex scenes,
the scene parsing could take longer than the actual render.
There are many other PC programs that do ray tracing, but POV-Ray is the
only one I've had any experience with.
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...)
I haven't really run into any issues where Haskell didn't let me do what
I want, except for the performance counters thing mentioned way back at
the beginning of this thread (and which I've more or less given up on
for now, since the acceleration structure seems to be working okay and I
have other things to work on).
I would certainly welcome any patches to Glome if you want to contribute
in some way rather than write something from scratch.
A good acceleration structure definitely makes everything go a lot
faster. It's the difference between rendering a scene in a few seconds
or ten minutes.
BIH is what I'm using. It's relatively new. Here's a paper about it:
http://ainc.de/Research/BIH.pdf
The actual constructor is based loosely on this pseudocode:
http://ompf.org/forum/viewtopic.php?p=1411#p1411
Evan Laforge wrote:
Not knowing anything about raytracing, one of the things I found
interesting about the paper was that he claimed that the speedups were
from using coherent ray packets, and that the shader model was
orthogonal, and enough much is spent raycasting that the shader code
to make much difference. The implication was that you could graft a
packet style raycasting engine onto even povray and give it a nice
speed boost... though you might have to lose the nifty "real" shapes
to tessellated approximations.
Is this accurate? True but reality is more complicated?
You don't need to drop support for the whole multitude of primitives,
though the ones that are packet-friendly will render faster. Many
modern ray tracers spend most of their time traversing the acceleration
structure rather than doing intersection tests with actual geometry, so
all you really need to do to get most of the benefit of packet tracing
is to make the acceleration structure support packets. (For the actual
geometry, you can fall back on mono-rays.) I tried 2x2 packets out last
night and got about a 10-15% speed improvement on the level-3 SPD
sphereflake. (Shadow and reflection rays are still mono rays; if I
converted them over, the improvement would presumably be more
significant.) The simplifying assumption you make when you're
traversing the acceleration structure with packets is that if one ray in
the packet hits a bounding volume, you assume that they all do. That
adds a little overhead if the rays are coherent (all starting near a
common origin and pointing in almost the same direction), or a lot of
overhead if they aren't coherent. If used appropriately, the
performance gains outweigh the overhead by a considerable margin.
Jon Harrop wrote:
On Thursday 24 April 2008 20:29:50 Andrew Coppin wrote:
> 2. It's the only program I've seen that can render *real* curves, not
> fake trickery with triangle meshes.
What you called "fake trickery with triangle meshes" is the core of all modern
computer graphics. Focussing on ray tracing instead of that is rather missing
the point, IMHO.
I agree that triangles are very important, and I support them in Glome.
Cones and spheres and boxes and the like can be made into some fairly
elaborate scenes, but you can't really make, say, a realistic human
figure out of those sorts of primitives. Also, real data sets like
terrain or 3d-scanned geometry are easy to represent as triangles. On
the other hand, sometimes all you want is a box or a shiny sphere and
it's silly (not to mention a waste of memory) to represent either as a
bunch of triangle. So it's appropriate to support both approaches, so
you can do whatever makes the most sense for the application.
Ray tracing and triangles isn't an either-or thing. Some ray tracers
only support triangles. There is a speed penalty for supporting other
kinds of primitives, because then the ray tracer has to branch to figure
out which ray-intersection test to run on each primitive, but I think
the flexibility is worth the cost.
-jim
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
