Input point, polygon, or multipatch features. Input features can be procedurally symbolized feature layers. Field mapping (attribute-driven symbol properties) will be honored.

The CityEngine rule package (*.rpk) file containing CGA rule information and assets. The rule annotated with @StartRule in the CityEngine rule package (.rpk) file should be annotated @InPoint for a rule package intended for point features, @InPolygon for a rule package intended for polygon features, or @InMesh for a rule package intended for multipatch features. If the @StartRule is not annotated with @InPoint, @InPolygon, or @InMesh, the feature type will be assumed to be polygon.

The output feature class containing multipatch features with CGA rules applied. A field named OriginalOID is added to the output feature class(es) to contain the ObjectID of the input feature from which each output feature has been generated.

Controls whether the output feature class inherits the attribute fields of the input feature class.

• Checked—The attribute fields of the input feature class will be included in the output feature class. This is the default.
• Unchecked—No attribute fields originating from the input feature class will be added to the output feature class. This option will be used automatically if the Export Leaf Shapes parameter is checked.

Depending on how the rule package has been authored, it may contain logic that generates one or more reports as the models are created. These reports can hold a wide variety of information about the features. An example is a rule package that reports the number of windows generated for each building model. This parameter is ignored if the rule package does not contain logic to generate reports.

• Checked—New attribute fields are created on the output feature class to hold reported value for each feature as defined by the rule package report generation logic. A unique attribute is created for each reported value.
• Unchecked—Reports generated within the rule package are ignored, and no new attributes relating to these reports are generated. This is the default.

CityEngine rule packages construct content by generating component pieces and merging them together into a single 3D object. However, it is also possible to store these components, or leaf shapes, as separate features. This option can be especially important for running analytical operations against subelements of a 3D object, such as the windows of a building.

This parameter determines whether each input feature is one of the following:

• Converted into a single, merged, multipatch feature
• Becomes a set of many features that can be points, lines, or multipatches

For example, a rule may generate seamless building models from input polygon footprints, or alternatively, it could create separate features for each apartment face, including an outward-facing panel, a representative center point, and lines showing the borders. In this example, the apartment panels, center points, and outlines are all considered leaf shapes.

• Checked—Additional output feature classes are generated. This is the default. The attribute fields from the input feature class are not included in the output feature class. The output feature class contains a field named OriginalOID that references the ObjectID of the input feature from which the output was generated.
• Unchecked—Additional output feature classes are not generated, even if additional leaf shapes are defined in the logic of the rule. All of the geometry is contained within the output multipatch features.

When leaf shapes are generated, an output point feature class is created in the same location as the primary output multipatch feature class.

When leaf shapes are generated, an output polyline feature class is created in the same location as the primary output multipatch feature class.

When leaf shapes are generated, an output polygon feature class is created in the same location as the primary output multipatch feature class.