[ Term Structure | Algebra | Geometry | Logic | Drawing ]
[ Language Bindings | C++ | Java | Lisp | ML ]

Geometry Terms

The terms used to represent geometric structures are divided into four groups, roughly corresponding to increasing levels of complexity.

Points

GeoPoint coordhi₁ coordlo₁ ... coordhi_n coordlo_n [Geometric Node]

Represents a point in some space (usually a Euclidean space). The coordinates of the point are floating point numbers represented by pairs of 32-bit integers.

GeoPointSymb coord₁ ... coord_n [Geometric Node]

When the coordinates of a point need to be more general than just floating point numbers, then nodes with this label can be used.

Simplicial Complex

A simplex is a set of d + 1 points whose convex hull has dimension d. The points of the simplex can be embedded in space whose dimension is larger than d. A simplicial complexes are composed of a number of simplices. The intrinsic dimension of a simplicial complex is the dimension of each simplex in the complex. The embedding dimension of the simplicial complex is dimension of the space of the points in the simplices of the simplicial complex.

Simplices cannot exist on their own, but must be contained within a simplicial complex, even if the simplicial complex contains only a single simplex.

GeoSimpComplex intrinsicDim embeddedDim simplexList [Geometric Node]
Represents a simplicial complex. The first sub-term is a nonnegative 32-bit integer representing the intrinsic dimension of the simplicial complex. The dimension of a simplex is one less than its number of vertices. The second argument is also a 32-bit integer and represents the embedding dimension of the simplicial complex is embedded. The embedding dimension of the simplicial complex, which must be greater than or equal to its intrinsic dimension.

Finally, simplexList is a term that represents the set of simplices contained in the simplicial complex. It is of the form

(GeoSimplexList simplex0 …simplexm)

where simplex₀ …simplex_m are each terms of the form

(GeoSimplex vert0 …vertd)

Here vert₀ …vert_d are the vertices of a simplex; these are integers between 0 and n, which refer to the points in the vertex list. The number of vertices, d + 1, must be one greater than the intrinsic dimension of the simplicial complex. Notice that terms with labels GeoVertexList, GeoSimplexList, and GeoSimplex are only intended to be used as sub-terms of a simplicial complex term.

Thus, simplices in a simplicial complex store indices into a vertex list rather than the vertices themselves. This is important for two reasons. First, since vertices in a simplicial complex are generally incident to many simplices, this device of referring to vertices by an index saves storage. More important, for many applications of simplicial complexes (such as finite element analysis), a vertex that occurs in multiple simplices must still have a unique identifier.

Note that a simplicial complex should satisfy many correctness properties. Some are purely syntactic properties such as agreement of all relevant dimensions. Others are more sophisticated, such as the correctness requirement that all the simplices have disjoint relative interiors. These correctness properties are not enforced by the MathBus.

Boundary Representations - Breps

"B-rep'" is an abbreviation for "boundary representation" and is the primary format used for defining geometric objects. Before introducing b-rep format, we first describe a variant of MBBind, namely, MBMultiBind:

MBMultiBind name₁ val₁ name₂ val₂ … name_p val_p term [Geometric Node]

This term has the effect of binding a sequence of names to corresponding values for use in the final term. The binding order is unspecified, and therefore name_i cannot be used in va_lj.

A b-rep object is a layered description of a geometric object. The first layer contains zero-dimensional faces (vertices), the second layer one-dimensional faces, and so on. A face is described as follows:

GeoBrepFace boundList intBoundList dim attr₁ val₁ … attr_p val_p [Geometric Node]

The boundList is a sub-term consisting of the boundaries of each face of the Brep. It has the form

(GeoBoundaryList face1 face2 … faceq)

Each of face₁ …face_p is a term of type GeoBrepFace. These boundaries are faces of one lower dimension. (Vertices of the b-rep have no boundaries.) In almost all cases, the faces appearing in a boundary list are not explicitly defined there, but are instead symbolic names of faces that were earlier bound using MBBind (or MBGlobalAssign). This is because a boundary face of a brep almost always occurs as a bounding face of two or more faces of higher dimension. The order of the boundary faces in the boundary list is not significant. The sub-term intBoundList is similar:

GeoInternalBoundaryList face₁ face₂ … face_r [Geometric Node]

Internal boundaries do not bound the face but indicate cracks or low-dimensional fissures in the face. Internal boundaries of a face can have any dimension lower than the face itself. Again, these sub-faces will usually be symbolic names rather than explicit terms of type GeoBrepFace. In this case also, order is not significant.

Sub-term dim is an integer specifying the intrinsic dimension of the face. Finally, the sequence of terms attr₁ val₁ …attr_p val_p are attribute-value pairs. The attributes are string identifiers, and the values are sub-terms. Some attribute names have built in values. For instance, the attribute "contains" is used for specifying a point in the relative interior of the face; its value is a term of type GeoPoint. (In the case of a 0-face, this attribute specifies the coordinates of the vertex.) The attribute "equation" is used to specify the equations of the surface of which the face is a subset. In this case, the value is a term of type EquationEqual. Most applications will not be able to handle a general system of equations, and thus an application is allowed to place further restrictions on the legal types of equations. Another predefined attribute is "parametric", in which case the corresponding value is a term of type Lambda, and this attribute specifies a parametric surface on which the face lies. If a face of dimension 1 or greater has neither a parametric nor equation attribute, then the surface containing it must be deduced from other faces. The rule used is as follows. If several faces of higher dimension contain this face as a sub-face, and they have equations or parametric representations, then the surface of the face itself is computed as an algebraic intersection. On the other hand, if no face of higher dimension has explicit equations or parametrics, then the face is assumed to lie in the affine hull of the vertices it contains. Thus, a brep in which no face has a parametric or equation attribute is a polyhedral object.

Finally, a b-rep itself has the form

GeoBrep embeddedDim face₁ face₂ … face_m [Geometric Node]

where embeddedDim is the embedded dimension of each of the faces and face₁ …face_m are the "top-level" faces of the b-rep, which must all be embedded in the same dimension but may have different intrinsic dimensions. Most often, the GeoBrep term will occur only at the end of a chain of bind statements that first define lower dimensional faces. For example, here is a b-rep specification of the triangle in two dimensions with vertices at (0,0), (1,0), (1,1). For the sake of brevity, we have omitted the internal boundary term from the faces since this example has no internal boundaries.

(MBBind	
    [v0] (GeoBrepFace (GeoBoundaryList) 0 'contains' (GeoPoint 0.0 0.0))
    [v1] (GeoBrepFace (GeoBoundaryList) 0 'contains' (GeoPoint 0.0 1.0))
    [v2] (GeoBrepFace (GeoBoundaryList) 0 'contains' (GeoPoint 1.0 1.0)) 
 (MBBind 
      [e0] (GeoBrepFace (GeoBoundaryList [v0] [v1]) 1) 
      [e1] (GeoBrepFace (GeoBoundaryList [v1] [v2]) 1)
      [e2] (GeoBrepFace (GeoBoundaryList [v0] [v2]) 1) 
    (MBBind [tri] (GeoBrepFace (GeoBoundaryList [e0] [e1] [e2]) 2) (GeoBrep 2 [tri]))))

Question for Rich: I could use MBMultiBind for simplicial complexes as well (i.e., refer to vertices through symbolic names rather than integer indices). Do you think that is preferable? Alternatively, I could use an integer numbering to refer to previous faces in this example.

Triangulated Brep's

A triangulated b-rep is the combination of three elements: a b-rep, a simplicial complex, and a mapping from simplicial complex vertex indices to faces of the b-rep (presumably through their bound names). A triangulated Brep can be used as input to a finite element solver or boundary element solver. Its format is:

GeoBrepTriangulated bRep simplicialComplex mapping [Geometric Node]

As usual, this term will probably occur inside a nesting of binding operations. The b-rep and simplicial complex are of the types specified in the two previous subsections, and the mapping has the form

GeoBTMapping face₀ face₁ …face_p [Geometric Node]

where face_i is the lowest dimensional face (presumably referred to via a bound name) of the Brep containing the i^th vertex of the simplicial complex.

CSG model

Cells

GeoCell subcell₁ subcell₂ … subcell_k [Geometric Node]

Represents a cell whose facets are the sub-cells provided as sub-terms of this node. Each sub-cell must be of the same dimension. Zero dimensional cells are represented as GeoPoint's.

GeoSimplex point₁ ... point_k [Geometric Node]

The dimension of the region defined by the points of a simplex is assumed to be one less than the number of dimensions. Thus the points of a simplex with three sub-terms are not co-linear. The points of a simplex with four sub-terms cannot be co-planar. These conditions are not enforced by the MathBus term structure.

GeoBox point₁ point₂ [Geometric Node]

Defines a polyhedron with sides parallel to the coordinate axes. The two points are diagonally opposite vertices of the box.

Complexes

GeoComplex simplex₁ ... simplex_k [Geometric Node]

Practical meshes could have an enormous number of sub-terms. So it might be wise to organize this structure a little differently. However, since a node can has as many as 2³² sub-terms this will probably do for now.

Models

CSG Models fit naturally into this kind of term notation. We would need a set of primitive models (half-spaces and some subset of all polyhedra, for instance), then more complicated models are built from the primitives using Union, Intersection, Set-Subtraction, etc.

B-rep Models can be done using a CellComplex, for instance, to hold the patches. We need a way to associate a parametric function with each patch (use Attributes?). And we need some way to distinguish inside from outside.

How deeply do we need to understand a Model? Is it enough to know that certain operations exist and that this model is handled by this modeler? That way, we never need to worry about the internal structure of the model-operations on the model are simply passed on to the modeler.