Manta Interactive Ray Tracer Development Mailing List

Text archives Help


Re: [MANTA] computeBounds


Chronological Thread 
  • From: "Steven G. Parker" <sparker@cs.utah.edu>
  • To: Thiago Ize <thiago@cs.utah.edu>
  • Cc: "'manta@sci.utah.edu'" <manta@sci.utah.edu>
  • Subject: Re: [MANTA] computeBounds
  • Date: Wed, 20 Jun 2007 15:34:03 -0600
You are absolutely correct that this has not been completely thought through. However, the intention is that the pp context would have the information needed. Passing a rendercontext would be reasonable I suppose.

Steve


On Jun 20, 2007, at 3:17 PM, Thiago Ize wrote:

I see the value of passing into computeBounds a range of times. However, in my quick look I didn't see anything in PreprocessContext that contains a range of times. Secondly, what happens when I want to call computeBounds on moving triangles later on when we are out of the preprocess stage (my understanding is preprocess occurs only when manta starts)? Should we instead explicitly pass to computeBounds the time increment? Or maybe pass it a RenderContext or some other type of context that will legitimately exist every frame?

Thiago

Steven G. Parker wrote:
The preprocesscontext is needed if you have moving primitives (that know how to move themselves). It will contain the time and/ or ranges of time.

Steve


On Jun 20, 2007, at 1:48 PM, James Bigler wrote:

Thiago Ize wrote:
Abe Stephens wrote:
Also, calling computeBounds on a group that contains lots of things (imagine a 10M tri statue) is a major bottleneck on a multi core system. Could we parallelize computeBounds? Can we make Group::computeBounds return an already precomputed bbox and do the actual bounding box calculation elsewhere?

DynBVH does this, it calls extendByBox on the input bounding box and passes in the bounds of the root node... The bounds are computed during a call to rebuild.

Abe

Sorry, I didn't explain exactly what is going on. During an animation, Group will interpolate from the old frame to the new frame. While doing so it looks at all the primitives, so computing the bounding box while that occurs would introduce a minor overhead (anywhere else and it is considerably more expensive). Then when DynBVH or any other acceleration structure takes that newly built group, it should be able to call computeBounds on it and the Group will realize it just computed that and return a precomputed bounding box. Doing this in the acceleration structure is bad because a group might be used in more than one acceleration structure. So what I want to do is precompute the bbox in the Group::interpolate function and then use that. This does of course introduce issues where something might modify an object contained by Group without Group knowing about it. It's for these ugly reasons that I was wondering what others recommended.

I think it is quite reasonable to add a bounding box to Group.

The purpose of adding a PreprocessContext to the compute bounds was to facilitate passing in new things that we may not know about. If we haven't used it by now, then we probably won't need it.

Another option is to add a method to Object that takes no PreprocessorContext, but creates a dummy one on the stack and passes that the current computeBounds. It would behave just like the ones you have now, but more convenient.

James






Archive powered by MHonArc 2.6.16.

Top of page