Alexander Enzmann wrote:
> 
> Mark Wagner wrote:
> >
> > Mark VandeWettering wrote in message <379### [at] pixarcom>...
> > >The Toro work at Stanford is a significant example of how to make this
> > >kind of system work.   And it supports displacement maps too!
> >
> > Have you seen the latest developments with the SuperPatch in p.b.i?
> 
> You are missing his point.  The raymarching technique used in the
> "SuperPatch" would need many more evaluations of the noise function than
> a basic tesselation.  Solid noise functions cost a lot to evaluate.
> Thus, for doing that sort of surface triangles can be a big win
> (especially in these days of lots of RAM and simple mapping of files to
> VM).

That is indeed, almost precisely the point.  Basically, most methods for
intersecting rays with parametric surfaces boil down to tesselation. 
Oftentimes you are avoiding computing regions of the tesselation which
are far from the ray, but in the end, you end up with a particular u-v
region, and you test for intersection with a triangle or quad, and
return that as the intersection.  That might sound like a good idea, but
in fact, if your patch is going to be tested by rays lots of times, you
might be better off evaluating the tesselation entirely once, and saving
it.  You then need not apply the relatively complex refinement
operations of (say) Bezier clipping or interval arithmetic, but can
merely walk the hierarchy of triangles in as fast a manner as you can
manage (Brian Smits has an interesting article in JGT about how to do
this).  

Even if your ray is tested against rays only a couple of times, you
might be better off computing tesselations, because tesselations are
dead simple to compute.

> There is also a pretty long tradition of making specific primitive types
> for raytracing.  For the asteroid example, Mark could have implemented a
> spherical heightfield prim (like in Polyray) that has been built
> expressly for tracing.  With that approach you have the memory savings
> of only storing the displacement map (plus some additional acceleration
> information), and much better performance than a raymarcher.  Of course,
> it would have taken time to write the prim...

Indeed.  It would be much simpler to just go ahead and tesselate the
model and feed it to a raytracer which was optimized for ray triangle
intersection.  A bit harder would be to do such tessellation lazily and
adaptively, you'd like to not tesselate portions of the model which
aren't visible.  Better still, but again more complicated, would be to
cache regions of the tesselations to help keep memory consumption down.

In general, I guess I am arguing against the creation of special
primitive types within a raytracer, at least at the level of ray
intersectors.  It is a different architecture which differs from what is
generally presented as a conventional raytracer design, but conventional
raytracing engines normally don't scale very well.  This alternative
design is in many ways an attempt to adapt some features of the Reyes
architecture to a raytracing engine.  It is my belief that it presents a
more flexible and scalable architecture for image synthesis than the
more traditional approach.

Hope this has been food for thought...
	
	Mark

> Xander

-- 
Mark T. VandeWettering 			Telescope Information (and more) 
Email: <mar### [at] pixarcom> 		http://www.idle.com/~markv/
No Code International Member #1173

Post a reply to this message