Re: [Caml-list] Announce: glome-0.2 (ocaml-based raytracer)

[Jim Snow <jsnow@cs.pdx.edu>]

New version (0.3) of glome is up: now with a new more elegant (and 
presumably asymptotically optimal but still abysmally slow) kdtree 
compiler, which unfortunately segfaults on large models.  (Thanks to the 
"marshalling limits" thread, I discovered that the size of the kdtree I 
can construct depends on the size of the stack.  I shall have to look 
into this further.)  It is also free of objects - I used Jon Harrop's 
suggestion to implement mutual recursion by passing the generic 
rayintersection function as an argument to any of the rayintersection 
functions that need to be recursive.  (It seems to me like an odd 
solution, but I think I can live with it.)  Mutation has been removed 
from much of the rayintersection code, (also at Jon's suggestion) which 
actually sped things up noticeably (about 15% or so).

Webpage is here: http://syn.cs.pdx.edu/~jsnow/glome/

Jon Harrop wrote:
>
> It didn't the last time I looked. Using "include" instead of "open" is often 
> faster, probably for that reason.
>
>   
I'll have to experiment with that and see what happens.
>> There are some hybrid renderers that do just that.  There are some
>> reasons not to do that, though; for instance, ray tracing scales better
>> on big models (see, for instance,
>> http://www.openrt.de/Gallery/OliverDeussen_Sunflowers/Images/sunflowers_2.j
>> pg).
>>     
>
> That simply isn't true. You can use trees with OpenGL and get the same 
> asymptotic efficiency whilst also being 100x faster in real terms.
>
> I've written a planet renderer that adaptively tesselates a 2^80-triangle 
> planet in real-time for OpenGL.
>
> I've written a 2D vector graphics engine that adaptively tesselates PostScript 
> paths into triangles so you can fly around 1Gb PDF images in real time.
>
> If what you said was true, that wouldn't have been possible.
>
>   
Perhaps I should be more specific about exactly what it is that is 
scaling.  With level-of-detail schemes (which could apply to ray-tracing 
as well as GL), you can render datasets of enormous complexity, provided 
you aren't trying to render it all at the same time.  Your planet demo 
looks very interesting, but it looks like your polygon counts at any 
particular moment aren't very high.  If you add some realistic 
vegetation, the high polgygon counts would slow things down quite a 
bit.  OpenGL scales linearly with the number of triangles it has to 
draw; ray-tracers scale logarithmically.  You can avoid some of the 
memory overhead of large scenes by using instancing, but GL still has to 
draw every single triangle.

Ray-tracing has its own costs; sorting an acceleration structure, for 
instance, can be very slow.  Also, they currently only surpass the 
performance of traditional polygon renderers on very complex scenes.  
For most current rendering problems, it makes more sense to use GL right 
now.  But as computers get faster, and real-time global illumination 
starts to become feasible, ray tracing is likely to look very 
appealing.  This is my opinion; you are free to disagree.

>
> Ray tracing is simply a bad way to render images, unless they 
> are closeups of reflective spheres.
>
>   
Opinions vary.  So do datasets and application requirements.

>
>> So, I switched over to objects.  This reduced 
>> memory use a little, I think, but didn't help much.  It did make things a
>> little slower, though.  There's some more detailed discussion over at
>> ompf.org: http://ompf.org/forum/viewtopic.php?t=336
>>     
>
> What is the memory use of my version like?
>   
About 1.5 gigs for the 800k triangle level 4 sphereflake, same as my 
version 0.2.  I think the memory consumption is elsewhere.  Most of the 
memory gets consumed as the kdtree is being built.
> Apart from the texture mapping bugs, check out these screenshots of my planet 
> demo. Now write me a ray tracer that can do that...
>
>   
I doubt that whatever level-of-detail algorithms you employ in any way 
preclude the use of raytracing, it would just be rather slow.  (The 
OpenRT people, for instance, are working on a drop-in OpenGL 
replacement, and the XFRT are working on an OpenRT replacement that is 
actually open.)  Now write me an OpenGL app that can render this 
correctly: http://graphics.ucsd.edu/~henrik/images/gbox.jpg :)

Nathaniel Gray wrote:
>
> I wonder if you really need the mutual recursion.  You can often avoid
> mutual recursion by using closures.  Instead of, say, a list of
> objects with an isect (intersect) method you can use a list of
> closures.  
That's more or less what my original implementation did.  I switched to 
objects because I wasn't sure if closures were allocating space 
efficiently.  Then I switched to my current implementation because 
calling object methods is slow (as evidenced by the results presented in 
the "Benchmarking different dispatch types" thread).  In the end, I 
don't think it made a big difference - I'm just not intersecting with 
very many primitives per ray.  Every little bit helps, though.