In some cases it is natural to follow a top-down design process when modelling a 3D object. For example, it makes sense to locate the walls of a building before windows and not not the other way around. This is why one of the more effective uses of shape grammars in modelling is to apply shape rules in a recursive manner (to the shapes produced by the previous round of application), yielding a progressively more detailed object. In this context, additional versatility, such as that afforded by the classic formulation of shape grammars [2], is unneeded.

This manner of shape grammar usage along with the formal definition of shape rule application [2] provide a strong conceptual link between the concrete geometry of the resulting object and how it is modified by the shape rules. However, the need to control the derivation of the shape grammar (which, in general, can yield a lot of variation in its product) motivates augmenting the grammars with control symbols and abstracting them to focus on their combinatoric properties. For instance, in their building modelling system Wonka et al. use the combination of split and control grammars only to derive the syntactic and spatial framework of the building; the geometric interpretation step is separate [1].

The following is an overview of the place grammar, a lightweight shape grammar whose formulation of shapes and rules is concrete in terms of the produced geometric objects. As the unifying principle, the place grammar operates on the 2D shell of a 3D object by placing the derived geometry on it. (A viable alternative is to use unit volumes that make up the 3D object.) The derivation of the place grammar obeys shape and rule labels, which are symbolic, and special shape attributes, related to the transformations that are applied to shapes when they are placed.

A building created with a place grammar.

Labels

a set of objects, which can be attached to both shapes and rules; each label has a value (a string) and can have properties like priority, weight, and a uniqueness constraint.

Label Set Constraints

constraints that apply to all labels attached to a shape; for example, path-based rule selection.

Shape Blueprint

a type of shape which is not tied to a coordinate system located on the shell of the derived object.

Built Shape

a type of shape with a local coordinate system and WCS dimensions; the modelled object's shell is made up of shapes of this type.

Shape Rule

consists of a single label, constraints on the input built shape (such as width, height, and aspect), special processing directives (for applying the rule multiple times in horizontal or vertical direction), and a list of output shape blueprints.

Shape Subrule

a set of output shape blueprints manipulated as a group by a shape rule; for example, they can be reflected across a horizontal LCS axis.

Depth Hint

a special attribute placed on a shape blueprint; provides for a way for built shapes on different levels of the derivation to coordinate their depth (the amount they are extruded in the direction of the normal); the operation is performed during built shape construction.

Center-and-Scale Hint

a special attribute placed on a shape blueprint; effectively allows two built shapes on different levels of the derivation to be the same size in the x and y directions; requires a transformation of the LCS and is performed by the shape rule during its application.

Rule Application

a rule is applied to a built shape when constraints on the built shape's dimensions are met and the rule and the built shape share a label; the shape rule uses the information in the built shape to transform and place each one of its output shape blueprints, which then become built shapes.

Rule Selection

normal rule selection for a built shape proceeds by selecting one of its labels (respecting priority and weight), and then selecting a rule that also has that label; alternatively, a cached rule selection can be used (path-based rule selection), and it is possible for a rule to be used precisely once on a derivation level.

Termination

a rule will not be selected for a built shape if it doesn't pass the constraints of any rule, it has a terminal label set constraint, it's label set is empty, or there is no rule matching any label in the shape's label set; when no built shapes can be derived, the grammar derivation terminates globally.

Despite the apparent multitude of features, a place grammar is very straightforward to use due to the unifying theme of placing a blueprint shape in respect to an LCS of a previously placed built shape. In the majority of cases, the inter-level attribute communication is not needed, which means that the grammar's specification consists mostly of the vertex coordinates of the shape blueprints. The label control system is particularly easy to use, since rules are only allowed a single label and any changes in the labels are a direct by-product of exchanging one shape for another during the derivation. In contrast, the system described by Wonka et al. incorporated a stand-alone CFG control grammar with a sophisticated computationally expensive matching heuristic [1] (not something one could trace by hand).

Place grammars can in principle be used to construct any 3D object (as a shell) - even the interior of a building. Indeed, the rule application of a place grammar only concerns itself with an LCS established by a previous built shape, which means that the derivation is not in any way limited by the current topology of the object and can easily change it.

A slightly different derivation, rendered with filled polygons.

Texturing could be considered a limitation of place grammars. While the components placed by each grammar rule could be trivially textured directly in the rule with explicit lists of texture coordinates (alongside the vertex coordinates in shape blueprints), that approach is tedious. A better way would be to texture parts of a whole level of derivation using coordinates generated based on the WCS position of the resulting built shapes. This is not straightforward.

There are some difficulties associated with the fact that all shapes are derived in parallel with little communication (only special attributes like hints or cached rule application, etc.) between the separate rule applications. While shapes occurring within the same rule can be modified as one conceptual unit to fix any problem with their relative arrangement, those produced by different rules generally can not. This is an obstacle for operations such as:

• removing T-intersections
• beveling edges

Place grammars lend themselves easily to a top-down component-based modelling approach, since the shape blueprints making up each rule are located in the same LCS (at <0, 0, 0>). This suggests an excellent way to interface a CAD package (with convenient geometry-shaping tools) with a place grammar: the CAD package could be used to create complicated geometry and the place grammar could transform and place it.

A place grammar for a building can also create its own floor plan (footprint) easily, a task which is usually treated separately. In a place grammar, the integration of this task is also attractive from a conceptual point of view: a place grammar has explicit access to the WCS coordinates of the currently derived object, which can allow it to easily perform occlusion queries (for example in the depth direction - away from the object).