Re: [Ray-devel] VM Redesign, GC, Coroutines (please read)

[<ajc...@en...>]

> In order for multi-threading to work we may neither store the mailbox 
> number in the accelerator nor in the scene graph. Both should be used 
> read-only by the rendering threads. 
> 
> It seems to me that the natural way which remains is to store a list of 
> intersected primitives in the ray. The downside is that this sort of thing 
> depends a bit on the accelerator used (BVH does not need mail 
> box numbers, I guess...)
> 

Yes, a list would work but It will scale poorly if the ray needs to test a lot
of primitives (need to test everything in the list on each intersection). 
That's why I mentioned we might want to do it with a hash table.

> (Anyways, the above about mailbox numbers was probably not the whole 
> story because we may want to get all intersections with an object, so some 
> sort of inside/outside information must as well be used, I guess.)
> 

If we want to get all intersections, then the primitive intersection routine
should do that for us.  There should not be a need to call intersection routines
more than once for a ray.  I use a list of Intersection objects in my ray tracer
for tests that need to get all the intersections for a ray (ie. I have two
virtual methods on all objects: nearestIntersection and allIntersections.  We
might even want an anyIntersection method for simple visibility tests).

> One other thing which is not described in the paper is how the "first- 
> come-first-served" works. If box A wants to have a ray traced and 
> sends a message to all the other boxes, how can box C and D know 
> that B accepted it without introducing a race? I see only 2 solutions: 
> 1. Use one server S which keeps track of all rays. A sends the ray to S 
>   which sends it to B. 
> 2. A directly sends the ray to B without telling anybody else. 
> Unfortunately, 1 introduces a bottleneck: the server S. Fortunately, I 
> already have an idea how one could do 2. (later)
> 

This is something that has confused me as well.  The only clue they give is in
section 3.3.  They mention that rays can be balanced by allowing hosts to take
rays from an input queue on first-come-first-served basis, but the rest of the
discussion does not mention any global queue to do this.  I'm guessing they do
something like (2) with local queues on each host, by sending load information
messages between the sets.  If there is not enough space in the local queue to
process a ray, the host will consult the loading table and send the ray
appropriately.  Just speculation...

Andrew


----------------------------------------
This mail sent through www.mywaterloo.ca