Re: topology files

[Michael Craig <mic@graphics.csail.mit.edu>]

my thoughts are below.. let me know what you think


On Thu, 25 Sep 2003, Seth Teller wrote:

>
> Patrick J Nichols II wrote:
> > Some replies:
> >
> > - portals do have a well defined source and dest. HOWEVER, portal's
> > don't have a notion of directionality. Do you think this is a serious
> > problem with the model?
> >
>
> making portals directional (i.e., making the representation a
> digraph, rather than a graph) is a good idea for at least two
> reasons.  first, it makes it easier to build the space/portal
> graph lazily, on demand -- since you can instantiate space A,
> and portal from space A to a space "to-be-determined," without
> committing to instantiating the opposing portal.
>
> second, portals are not always symmetric, that is, portal
> A->B may have different properties than portal B->A.  the
> simplest example of this is a door that requires cardkey
> access to traverse.  the route-planner needs to consider
> that traversing (say) the A->B direction requires an ID.
> but since the B->A direction goes from a secure to an
> insecure space, traversing the portal in this direction
> does not require an ID.
>
> rather than tagging the spaces on either side of the portal,
> and trying to make inferences about the portal from the tags,
> my view is that we should simply attach to the portal every-
> thing we know about it, as a function of the direction in
> which it is encountered/traversed.

that makes sense-- i can make the portals bidirectional.


>
> > - some times portals have an explicit type in the data (stairs vs.
> > elevator shafts vs. windows), and it probably makes sense to save those
> > types rather than inferring them from bell's code. ergo, we save them in
> > their text representation. additionally, i'm not really sure how to go
> > about inferring portal types in certain scenarios -- i.e. its really
> > unclear how to tell an elevator shaft from a staircase, and they are
> > very different times.
>
> i'm sorry, this is still not clear to me.  stairs and shafts are
> spaces.  windows are portals (for visibility, or for emergency exit
> purposes).  why are you conflating them?  also, when you says it's
> hard to tell a shaft from a staircase -- do you mean it's hard for
> the walls program to distinguish these space types?  michael, is this
> correct?  my impression was that it was not hard.


we were thinking of stairs and shafts as portals between levels.
technically stairs lie inside spaces and do not define the spaces
themselves. a staircase would thus connect two spaces which lie on
different floors. with elevator shafts it's a little more ambiguous,
looking at the floor plans. an elevator occurs as a box crossed with an X,
and this box lies inside a fully valid space. now, the shaft really
consists of the whole space itself, and the box is just the indication of
this.

to me it makes sense to think of stairs and shafts as portals (using a
different definition as for visibility purposes) that connect the spaces
they lie in (or consist of, for shafts). otherwise there needs to be some
other way of defining connectedness across floors. the portal definition,
in this sense, only refers to connecting two spaces.

shafts and stairs are well-distinguished on the floor plans-- i think the
issue patrick was thinking of is that, for his code, it is useful to
assign types for the portals. even putting stairs and shafts aside-- it is
useful to distinguish door portals from window portals, so that for
example we would only present a path using window portals in emergency
situations. after my processing in walls, it will be difficult for patrick
to distinguish portal types in any other way than for me to tell him what
they are explicitly.




michael