BMG Fall Strategy I

[Patrick Nichols <pnichols@graphics.csail.mit.edu>]

Seth (et al) --

We (Luka, Mike, Patrick) just had a rather long BMG strategy discussion 
for the term ahead, and have made a few tentative decisions, namely that:

1. Walls will soon output the data format that Bell's location server 
reads in. This means that Bell's thesis will be plugged into 
the pipeline, potentially reading in Stata, when we have the 
data. Furthermore:

- Spaces will be named using the BUILDING#FLOOR#ROOM hierarchy
- Portals will be named using the BUIDING#FLOOR#ROOM#ID hierarchy
- All space and portal names will be unique
- All coordinates will be in world space, NOT building space

2. We'll handle multifloor routes by adopting the convention that elevator 
shafts are spaces (one space per shaft per floor), connected the shaft 
slice above and below only. This means that to go from floor 2 to floor 4, 
the route will go through the floor 3 elevator shaft section.

3. We'll handle multibuilding routes (provisionally) by having some 
portals connect to the "outside world". A route from NE43 to 37 will look 
like NE43->OUTSIDE_WORLD->37.  We need to talk to Vitaly about more 
intelligent ways of including his basemap work in this effort.

4. In an effort to make the actual route-visualization layer more 
lightweight, we'll move a lot of the computatation for finding routes from 
the client (i.e. a java applet on a web page, or a sign) to Bell's thesis 
server.  In particular, the interatively shortened routes between pairs of 
spaces will be precomputed on initialization, and the location server API 
redesigned.

That is, more or less, our strategy for the term ahead. More on this 
later.

-Patrick

-- 
* * *

Patrick James Nichols II
Graduate Student, MIT Computer Graphics Group
http://graphics.csail.mit.edu/~pnichols