Re: BMG Fall Strategy I

[Seth Teller <teller@csail.mit.edu>]

bmg'ers -- comments below.

Patrick Nichols wrote:
> 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

walls should output a "winged-edge" model, i.e., it should
define single named vertices for each shared vertex position,
then use the named vertex multiple (typically three) times
wherever adjacent faces meet.  note that this implies that
shared edges will be explicitly stated in the unigrafix file.

why is this a requirement?  for one thing, it produces a more
"structured" output, which is usually a good thing.  second, it
will be useful to vitaly when he starts to produce more sophisticated
procedural models, with different materials at shared edges and
vertices.  (see legakis' 2001 siggraph paper on this topic;
vitaly has the reference.)

regarding coordinate systems:  i'm not convinced that world-space
coords are the right choice.  i would suggest instead that you
output a "scoped" coordinate transform for each floor file, taking
building coords to world coords.  the vertices defining the walls
etc. would then be expressed in building coords.

why do this?  several reasons.  first, building coords are axis-
aligned, which will simplify any spatial partitioning or visibility
processing needed.  second, again, it preserves structure in the
file; we can always "flatten" the file to world coordinates if we
need to (but we wouldn't be able to go back again if all we had
was the flat file).  third, staying in building coords defers the
introduction of uncertainty (in the building -> world xform) as
long as possible, and encapsulates that uncertainty in a single
UG xform statement, rather than "infecting" all the vertices with
it.

i also want to make a general philosophical point about coordinate
systems.  one big problem with most file formats is that, while
they allow coordinate *transforms* to be specified, they don't
allow coordinate *systems* to be named, except typically through
some ad hoc method.  unigrafix is guilty of this too.  so one can
get into a situation where one has a file of thousands of vertices
of xyz positions, but no idea in which space they are defined!

we should fix this, by adopting a naming and scoping convention for
all of our data.  i'll leave the details to the BMG team.  but the
abstraction should be that a human or program reader of any BMG
unigrafix file should easily be able to determine the coordinate
system in which any geometry is expressed.  i suppose for now there
are only two:  building-relative (one per building) and campus-relative
(one, total).  but in future we may wish to, or need to, introduce
additional named systems.

> 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.

this sounds exactly right.

> 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.

yes.  perhaps a portal to the outside world cannot be legally
defined *until* the originating building has been situated in
campus coordinates, and the "destination end" of the portal has
defined coordinates.

> 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.

this sounds like more of an implementation issue than an architectural
issue, right?

does the word "interatively" above mean "iteratively" or "interactively"?
if the former, why is the route computatation iterative?  if the latter,
why is it interactive?  please clarify.

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

terrific.  thanks for the update.

seth