Label | Explanation | Data Type |
Input Features
| The input point, polygon, or multipatch features. Input features can be procedurally symbolized feature layers. Field mapping (attribute-driven symbol properties) will be honored. | Feature Layer |
Rule Package
| The CityEngine rule package file (*.rpk) containing CGA rule information and assets. The rule annotated with @StartRule in the .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 @StartRule is not annotated with @InPoint, @InPolygon, or @InMesh, the feature type will be assumed to be polygon. | File |
Output Features
| The output feature class containing multipatch features with CGA rules applied. An OriginalOID field is added to the output feature classes to contain the ObjectID of the input feature from which each output feature has been generated. | Feature Class |
Include Existing Fields
(Optional) | Specifies whether the output feature class will include the attribute fields of the input feature class.
| Boolean |
Include Reports
(Optional) | Specifies whether the output will include additional reporting fields as specified by the procedural rule package. 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 contain a 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. | Boolean |
Export Leaf Shapes
(Optional) | Specifies whether each input feature will be convert to a single, merged multipatch feature or become a set of many features that can be points, lines, or multipatches. CityEngine rule packages construct content by generating component pieces and merging them into a single 3D object. However, these components, or leaf shapes, can also be stored as separate features. This option can be especially important when running analytical operations using subelements of a 3D object, such as the windows of a building. For example, a rule may generate seamless building models from input polygon footprints, or alternatively, it may 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.
| Boolean |
Derived Output
Label | Explanation | Data Type |
Output Point Features | When leaf shapes are generated, an output point feature class is created in the same location as the primary output multipatch feature class. | Feature Class |
Output Line Features | When leaf shapes are generated, an output polyline feature class is created in the same location as the primary output multipatch feature class. | Feature Class |
Output Multipoint Features | When leaf shapes are generated, an output polygon feature class is created in the same location as the primary output multipatch feature class. | Feature Class |