"The Americans are all here on time.  That's surprising."  -- Pete

Topic: finding first ray/object intersections fast.

Ray from O, v.  Want to find p=o+tv.

Want a sublinear search alg. in the ray tracer.

t=inf.
for(i=0;i<N;i++)
  find ti
  if ti<tn t=ti && ti>epsilon

Optimization #0:
  bounding sphere - reduces time constant, not time complexity (still have to
  check every object)
  Sphere is (p-c)^2-R^2=0.  p is point on ray = o+tv.  (o+tv-c)^2-R^2=0.
    So have quadratic: a=v^2, b=2v(o-c), c=(o-c)^2-R^2.  so if b^2-4ac is
    positive, we hit it.  If you normalize viewing rays, v^2 is always
    one.  This is a tradeoff.  Can do lots of optimizations if they're
    normalized, but have to normalize.

Optimization #1:
  access-aligned paralellopiped (box) bounding box around each object.
  Is there a similarly trivial hit check for a box?  Yes.  Intersect with
  all six planes.  As long as the regions where the ray is between ymin/max,
  xmin/xmax, we're between slabs.  If these regions overlap, we intersect.
  If the intersection of the two intervals is non-null, the intersection is
  the t region that you're inside the box.  Test is: is maxx<miny or v.v.?
  (this was the 2D example).

  Right now: code the tighest ray/box intersection you can.  Discuss it on the
             mailing list and reach group consensus and code.

Optimizations: sublinear searching

Must either implement uniform grids or bounding volume hierarchies.

Uniform grids
-------------
  Find bounding box of whole model.  Toss out the infinite primitives; but
  'em in a separate data structure.
  Divide that into a certain number, nx, of cutting planes in x.  Same in y.
  You get a grid.
  Send a ray through it, linearly order the cells the ray passes through.
  Search all objects (partially) in each cell in that order.  If you hit
  something but you hit it outside the cell, you don't stop; a hit in the
  next cell may be closer.  When you hit an object within the cell you're
  looking in, you're done.

  You walk the cells with Bresenham integer line sort of argument.  If you
  know all the t values where it intersects call boundaries.  Is there a 
  pattern to the distances between the points?  Alg. is not quite Bresenham,
  'cause you don't want the nearest pixel to the line; we always want to
  go N or E.

  Intersection with only y axes: constant slope.  t distances between only
  the y planes are constant.  Walking plane-plane is trivial.  Same thing in
  x.  Key is that if you separate them they're both very well-structured.
  Call the spacings (delta)tx and (delta)ty.  This assumes the rays have
  unit vectors.  [Does it?]

  So you walk along the ray: you either change in x or you change in y:
    nexttx=t+(delta)tx, nextty=t+(delta)ty.
    if(nextty<nexttx) change y addr else change x addr
  Note you only need compute one of those += things each time.

  class grid {
    int nx,ny,nz;
    point3 minx,maxx;
    surf* data         // = new surf*[nx*ny*nz]
  };

  Detecting termination isn't necessarily easy.  [ put a sentinal layer
  around the whole thing, with a magic data value (1) and test for it. ]

  nx*ny*nz = kN.  k is the time tradeoff for #cells vs. avg. cell density.
  Need to pick a good k.  Want pretty cubical cells, too.

  Follow out this:

    nxnynz=kN
    (delta)x ~= (delta)y ~= (delta)z
    (delta)x = lx/nx ~= ly/ny ~= lz/nz
    nx ~= lxny/ly
    nxny ~= lxny^2/ly

  Can make grid nestable so the tradeoff can be tailored to local object
  density.

Bounding Volume Hierarchy
-------------------------

  Suppose we have 4 objects.  Each object has its own bounding volume
  generated (axis-aligned boxes).  Then bound subcollections together,
  hierarchically.

  Can represent the whole thing as a "search structure" -- you get a
  hierarchical set of bounding volumes.  When you pass rays thru, you don't
  necessarily stop the first time you interesect -- some other object
  somewhere else in the tree may be in front.

  In grid you terminate early -- here it's not necessarily front-back.

  Breaking things up into boxes it tuff - could minimize box sizes.
  Also, want a roughly balanced tree -- split the data in half each time:
  sort in x, divide in two.  Sort in x, then y, then z, then repeat.  Or,
  could try to figure out which of x,y,z is "best" at any instant.  It's
  not partitioning space like BSP, it's partitioning objects.

  If you split in half each time, you get a COMPLETE tree (maxh-minh<=1).  If
  N is a power of 2 you get a PERFECT tree.  This is important, 'cause you can
  store it as a heap and traverse w/arithmetic, not pointer traversal.
  Do this!

Which of the two is faster is an open question.  BVH is cleaner; deals better
with highly disparate data sets, handles infinite primitives.  Getting grids
fast may be harder than getting a BVH fast.

Folk wisdom: All things that try to be clever slow your code down.