On Jul 17, 2013, at 2:00 PM, Joseph F Harrison wrote:

> Bounding boxes are an elegant and efficient way to handle this problem in general. Mark uses the JTS class Envelope in GeoMASON. We could easily whip up one for MASON. If would make the hitObject calculations faster too.

Well, of course bounding boxes are how you'd define location.  They're *not* how you'd do storage and that's the trick.

The general idea here is that Continuous2D is supposed to draw efficiently.  At present we're just scanning through the entire bag of objects and drawing the appropriate ones.  But the better way to do that would be to range-query the Continuous2D, assuming its discretization was reasonable, and only draw those objects.  I used to have code to do that but yanked it out, IIRC, because for the numbers of agents almost everyone used, the constant cost was too high.

Anyway, Continuous2D/3D is designed for objects represented as points.  We could expand it to explicitly have bounding boxes for volumetric objects but I would want to make sure that was handled correctly -- once you set stuff like that in code, it's set in stone.  One interesting issue was how you'd store the rect information.  I presume we'd either add width and height to Double2D (ugh) or subclass Double2D (ugh) to make a new Double2D with width and height.  In the latter case the Continuous2D would have to do an instanceof lookup each object to determine what class it was (ugh).

Then there's the interesting issue of determining range lookups for volumetric objects, assuming we were doing this for more tasks than just drawing properly on the screen.  That would not the most fun of tasks I think, perhaps requiring a different data structure.

So anyway, it's something worth looking into but nontrivial overall.  As an aside, I just double-checked NetworkPortrayal2D and in fact it draws all objects regardless right now; I had dumped our code which checked to see if the line would intersect with the window area.

Sean