from design-model.lisp

;;; The Design Model

;;; The design model can be thought of as a simple CAD model.  A design model object contains
;;; an edge model, a list of territory models, and a list of design elements.  Possible
;;; design elements:  WALL, PARTITION, COLUMN, FIREPLACE, STAIR.  It also contains a
;;; circulation model, (conceptually) derived from the design elements. (As an approximation,
;;; it is actually derived from a territory model that contains disjoint territories which
;;; tile the design's floorplan.)

;;; Need a way to designate approach points, e.g. from the street.  Add Marker objects 
;;; to design model for now.

;;; Each design element contains information about material, tectonics (whatever dsk means by
;;; this), and geometry.  The geometry is currently represented as a plan view (aka
;;; footprint) consisting of a list of edges, and a height.  (Height is currently not used.)

;;; The design model is used to derive an edge model, which is a geometric abstraction of the
;;; design model and is used in computing such values as visual-openness.  Conceptually,
;;; there are three edge models possible:  one which contains edges collected from design
;;; element footprints, one in which certain footprints have been abstracted to a smaller
;;; number of edges (e.g. a single edge for a wall), and one in which open boundary segments
;;; (aka void edges) have been deduced and added.  The open boundary segments simplify
;;; certain computations, e.g.  modification of design elements to increase/decrease visual
;;; openness more naturally focuses initially on open boundary segments rather than on the
;;; design elements inducing those boundary segments.  For now, store only one edge model,
;;; which includes both abstractions and void edges.  Each edge stores its derivation
;;; information so that the process of modifying a design model can reverse the derivation.

;;; For now assume that an image is associated with a design model, and that each territory
;;; model shares that image.  This assumption restricts all territory models to having the
;;; same scale, since scale is associated with an image.  Should this restriction need to be
;;; removed, image information will need to also be stored in territory models, with default
;;; information stored with the design model.

from territory-model.lisp

;;; The Territory Model

;;; The territory model is a (2D) geometric abstraction of a design model and contains
;;; territories which are induced by design elements in the design model. A territory is
;;; represented as a collections of edges, which form the boundary of the territory.  The
;;; edges are derived from design elements and are stored in an edge model. Each design model
;;; (currently) has only one edge model, but may have several territory models.  One
;;; territory model that is useful for certain computations (e.g. circulation) contains
;;; disjoint territories that tile the floorplan of a design model.  Other territory models
;;; might contain overlapping territories.  For now, just store the disjoint territory model.
;;; Certain overlapping territories, such as those used in computing continuity, are
;;; currently derived dynamically rather than being stored (see max-rectangle code).


from use-model.lisp

;;; Use Model:  maps activity-labels to territories.  Use model is just a list of use-spaces;
;;; it's associated with a particular territory model.

from circulation-model.lisp

;;; The Circulation Model

;;; Circulation model is graph of openings between territories: nodes represent openings,
;;; links represent single-edge path between nodes (midpoints of openings) and are tagged
;;; with distance.  Using single-edge paths between openings assumes convex spaces.  (If
;;; concave, path edges cross opaque edges; need to use visibility graph to position edges.
;;; Later.)

;;; PATH: lists of circulation-nodes and circulation-links, each list assumed to be in
;;; reverse order.  Toplevel path-finding functions are #'path-from-x-to-y and
;;; #'paths-from-x-to-y, where x and y currently can be territories, design-elements, edges, 
;;; symbols.  (See #'find-circulation-node for ok types.)  Path-finding functions work by
;;; finding circulation nodes that correspond to x and y, then finding a path or paths between
;;; the nodes.  Paths are stored on the circulation node for destination (i.e. y). 


from save-model-to-file.lisp

;;; Saving and loading files

;;; Toplevel save functions are #'save-design-model and #'save-territory-model.  (Need to
;;; update for new representation, e.g. that includes use-models.)  Save function writes
;;; call to #'setup-dmodel or #'setup-tmodel into file, so loading file instantiates
;;; models.  Setup functions now load related models as well; e.g. setup-dmodel loads
;;; edge model and territory models, setup-umodel loads use model, design model, edge
;;; model, territory models.  Circulation models are created when load edge and territory
;;; models. Currently no way to save edge-model or use-model (examples were edited by hand). 


from save-and-find-model.lisp

;;; Runtime management of models

;;; After loading models, access them with #'get-model (or #'get-design-models,
;;; #'get-territory-models, #'get-use-models), or #'find-model.