From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id A98A3BC0A for ; Thu, 18 Jan 2007 11:29:55 +0100 (CET) Received: from ehlo.cat.pdx.edu (ehlo.cat.pdx.edu [131.252.208.106]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0IATqhQ007200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 18 Jan 2007 11:29:55 +0100 Received: from [192.168.0.3] (c-24-20-143-105.hsd1.or.comcast.net [24.20.143.105]) (authenticated bits=0) by ehlo.cat.pdx.edu (8.13.5/8.13.5/Debian-3ubuntu1.1) with ESMTP id l0IATieK021591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 02:29:45 -0800 Message-ID: <45AF4C0C.9030903@cs.pdx.edu> Date: Thu, 18 Jan 2007 02:29:32 -0800 From: Jim Snow User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Announce: glome-0.2 (ocaml-based raytracer) References: <45A6E34A.6040007@cs.pdx.edu> <200701151206.34251.jon@ffconsultancy.com> <45ABFB4D.3000605@cs.pdx.edu> <200701152259.10598.jon@ffconsultancy.com> In-Reply-To: <200701152259.10598.jon@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (ehlo.cat.pdx.edu [131.252.208.106]); Thu, 18 Jan 2007 02:29:45 -0800 (PST) X-Virus-Scanned: ClamAV version 0.90RC1.1, clamav-milter version devel-131006 on ehlo.cat.pdx.edu X-Virus-Status: Clean X-Miltered: at discorde with ID 45AF4C20.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; compiler:01 segfaults:01 marshalling:01 stack:01 recursion:01 recursive:01 mutation:01 noticeably:01 renderer:01 triangles:01 triangles:01 acceleration:01 henrik:01 recursion:01 allocating:01 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.