Lesson 3 has introduced you to hands-on 3D modeling using an efficient approach for various modeling purposes. Instances of when you need hands-on modeling are: (a) you are interested in a substantial amount of detail in your models, (b) your models are non-existent anymore and cannot be, for example, scanned, or (c) you’d like to make use of a substantial asset warehouse that provides you with professionally designed items such as fridges or couches. As you can easily imagine, this approach will be prohibitive if you are interested in modeling entire cities or any large number of buildings, if you would like to test changes quickly (e.g., increzasing the number of floors), or if you need flexible access to your models, for example, through the internet.
In contrast to modeling by hand (also referred to as static modeling), the general concept of procedural modeling has been discussed in Module 2. Rather than modeling individual buildings, procedural computing (as a basis for procedural modeling) is the process of creating models algorithmically instead of manually. This chapter will provide a more detailed introduction to procedural modeling as it is the basis for modeling cities and other geographic scale information in GIS environments. However, we decided not to teach a specific software as a generating platform in this course. We are already introducing you to a number of software options and ESRI CityEngine, although a powerful tool, requires a bit more time than we have in one or two lessons. We will provide you with resources and a demo (in later lessons) that show some of the functionality but do not expect you to learn CE for this course. Yet, we would like you to understand procedural modeling. Later in Module 5, you will explore how procedural rule packages (that we created for you) can be applied in ArcGIS Pro (this is also in line with the long term strategy of ESRI). What this means is that you will be able to modify rules created by a procedural modeling software but you do not have to learn the specifics of the software (City Engine). As Arc GIS Pro is a rather new software product the functionality to change procedural rules is still limited but improving from version to version. The software has already been updated twice since we started designing this course.
By the end of this lesson, you should be able to:
To Read |
|
---|---|
To Do |
|
If you have any questions, please post them to our "General and Technical Questions" discussion (not e-mail). I will check that discussion forum daily to respond. While you are there, feel free to post your own responses if you, too, are able to help out a classmate.
As discussed in Module 2, procedural modeling is about constructing detailed textured 3D models by formulating rules instead of manually modeling them (CityEngine [2]). These rules are constructed based on a specific type of shape grammar (Stiny & Gips 1971). Stiny and Gips invented shape grammars and defined shape grammars as a method of two and three-dimensional shape generation. A shape grammar is a set of shape transformation rules to generate a language or set of design (Knight, 1989; Duarte & Beirao, 2010). They are spatial rather than symbolic and also non-deterministic. It means that the designer is not constrained by a limited choice of rules (Knight, 1989).
Shape Grammar is a way of defining algorithms. It makes design, generally speaking, more understandable. In order to read and use shape grammars, we need to have a short review of the basic terms below (Stingy, 1980):
A shape rule specifies how the existing part of a shape can be transformed. It consists of two labeled shapes on each side of the arrow (α-->β). Each labeled shape is made up of a finite set of shapes which are points, lines, planes, or volumes. For instance, in the figure below a simple shape grammar consisting of two rules is defined. The first rule specifies that a triangle with a dot can be modified by adding an inscribed triangle and removing the dot from the original triangle. The second rule states that one can also simply remove the dot from a triangle with a dot. Given the initial shape of a triangle with a dot, a shape can be derived by applying these two shape rules in a different order, namely, rule a -> rule a -> rule b in this case.
To create an urban plan or design, the complexity and characteristics of that environment can be interpreted as shape grammars to increase flexibility in suggesting the number of solutions and scenarios. Duarte & Beirao (2010) indicate that old urban plans are not compatible with contemporary urban societies and that there is a need for flexible designs. They propose that there are two ways to use shape grammars in urban environments: (1) as an analytical tool to find the structure of an existing design, or (2) as a synthetic tool to create a new language for design. Both methods automate the process of design generation.
Although a shape grammar can be generated by hand, for more complex rules and choices, a generation engine is needed to create and display geometries and decide which shape rule to apply. ESRI CityEngine is a generation engine for creating shape grammars, applying rules, and generating shapes. CityEngine’s programming language to define shape rules is called CGA (computer-generated architecture) shape grammar. The next section briefly explains the CGA shape grammar and how it can be applied to create virtual 3D models of cities.
Creating a model based on rules is less labor-intensive. However, the preparation of rules is time-consuming. The strength of this modeling approach is that once the rules are created, generating and creating models takes a small amount of time. The following diagram shows the total cost of procedural modeling vs handcrafted modeling.
To give you a deeper understanding of Shape Grammars, we would like you to read Shape Grammars in Education and Practice: History and Prospects [1] by Terry Knight. Knight, T. W. (1989).
In this section, we focus on an introduction to ESRI CityEngine as an instance of procedural (grammar-based) modeling software. Although this software won’t be used in this course, the result of its procedural modeling will be applied in lessons 5 to 7 that will introduce you to ArcGIS Pro. CityEngine is standalone desktop software. ‘The computer is given a code-based ‘procedure’ which represents a series of commands - in this context geometric modeling commands - which then will be executed. Instead of the "classical" intervention of the user, who manually interacts with the model and models 3d geometries, the task is described "abstractly", in a rule file’ (CityEngine [2]). The set of generic procedural rules can be used or modified when creating virtual cities. Moreover, new procedural rules can be defined, modified, or rewritten to create more detailed and specific designs.
Please watch the video below to learn more about the user interface and navigation in CityEngine.
CityEngine is suitable for transforming 2D GIS data to 3D cities. GIS data such as points, lines and polygons can be used to create 3D models. The current version of CityEngine connects to ArcGIS through data exchange. However, it is not tightly integrated into the ArcGIS system yet. The created 3D models can be exported to other software for analysis or editing such as ArcGIS, Maya, 3ds Max, Google Earth, the Web (see Lesson 7) or Unity (as we’ll explore in Lessons 8 and 9) (CityEngine Frequently Asked Questions [4]). The following figure shows different data formats of input and output to and from CityEngine. CityEngine does not support automatic creation of 3D city models. The platforms that support automatic creation of 3D models in urban environments, use oblique imagery or LiDAR data to reconstruct volumes and building shapes based on point clouds and aerial imagery. However, the main strength of CityEngine is data creation, the use of other datasets such as geodatabases and export capabilities. A single procedural rule can be used to generate many 3D models. GIS data feature attributes can be used to add more accuracy to the model. Instances of such attributes are building height, number of floors, roof type, and roof materials.
As mentioned, CityEngine uses a programming language called CGA shape grammar. Rules written with CGA are grouped into rule files that can be assigned to initial shapes in CityEngine. For instance, 2D building footprint polygons can be assigned a rule file containing the rules for interactively creating building models from the 2D polygons as illustrated in the figure below. One of the rules defined in the rule file needs to be declared as the starting rule, meaning that the generation of the building model will start with that rule.
The initial shapes to start the iterative refinement process can be created either in CE or imported from another source. More precisely, there are three ways of creating shapes in CityEngine (see image below): (1) manually creating shapes, (2) deriving shapes from a graph (e.g., street segments and lots from road network), (3) importing shapes (e.g., 2D building footprints from a shapefile).
All CGA rules have the format Predecessor --> Successor
Where “Predecessor” always is the symbolic name of the shape that should be replaced by the “Successor” part on the right side of the arrow. The “Successor” part consists of a number of shape operations that determine how the new shape is derived from the input shape and symbolic names for the output shape(s) of the rule (which can then be further refined by providing rules where these shape symbols appear on the left side of the arrow). To give an example, the following two rules create a block separated into 4 floors from a 2D polygon:
Lot --> extrude(10) Envelope Envelope --> split(y) { ~2.5: Floor }*
The first rule states that the initial 2D shape (“Lot”) should be replaced by 3D shapes called “Envelope” that are produced by extruding the initial 2D polygon by 10 units. The second rule says that each “Envelope” shape created by the first rule should be split along the vertical y-axis into “Floor” shapes of height 2.5, so four floors altogether. We could extend this simple example by adding rules for splitting each floor into the front, back, and side facades, applying different textures to these, inserting windows and doors, and so on. Application of a rule file to the initial shapes results in a shape tree of shapes created in the process. The leaves of the tree are the shapes that will actually make up the final model, while all inner nodes are intermediate shapes that have been replaced by applying one of the rules. The shape tree for the simple example would start with the “Lot” that is replaced by an “Envelope” shape, which in turn is replaced by the four “Floor” shapes making up the leaves (see figure below).
CGA defines a large number of shape operations (see CGA Shape Grammar Reference [6]). Shape operations can have parameters such as the extrude and split operations in the previous example. Rules can also be parameterized to provide additional flexibility (see Parameterized Rule [7]). Moreover, rules can be conditional (see Conditional Rule [8] or Stochastic Rule [9]), and rule files can contain attribute declarations (see [10]Attributes [11]), function definitions (see Functions [12]), and style definitions (see Styles [13]). If you want to learn more about writing CGA rules, tutorials 6 to 9 at Introduction to the CityEngine Tutorials [14] would be a good starting point.
To create building geometries through CGA rules, the following general workflow can be used:
Lot --> extrude (4) Building Or: attr height = 30 Lot -->extrude(height) Building
In order to modify the resulting 3D models, different possibilities exist: (1) edit the rules by scripting, (2) overwrite the rule parameters of a rule set on a per-building basis, and (3) if stochastic rules are used (rules with random parameters), the random seed of all or single buildings can be altered. The last method is used in creating virtual cities that should have certain characteristics. These types of randomization are not a representation of reality.
The following figure shows how a rule can be overwritten (2nd method mentioned above). This window provides values to the parameters of a rule. To overwrite the rule, there are some options: (a) to use the rule-defined value, (b) manually add a user-defined value, (c) object attribute, (d) shape attribute, or (e) layer attribute. Layer attribute is to choose attributes based on shapefiles or geodatabases attribute table. For instance, if you have height value as a field in the building footprints’ attribute table, you can use it to automatically generate extrusions. Other instances of fields that can be used for buildings are roof types, roof materials, façade materials, etc.
Airborne LiDAR data provides information on variable elevations. This elevation information is useful in both creating the DEM (digital elevation model) and estimating buildings’ height. The airborne LiDAR data collected for Penn State campus is in 25 cm intervals. You can see the Campus LiDAR point clouds of buildings and vegetation in the Figure below. All noises and irrelevant categories are removed for presentation purpose.
LiDAR returns information for two types of elevation models: (1) DSM or digital surface model (Figure below) which is a first return surface including anything above the ground such as buildings and canopy. (2) Topography: the ground or bare earth which is referred to as DEM (digital elevation model).
In CityEngine, for creating a 3D model of Penn State campus, the first step is to insert a DEM. Having a DEM defines the coordinate system and the ground elevation base for locating building footprints and streets. To estimate campus building heights, a digital surface model is created. Based on the normalized DSM layer, the minimum and maximum heights of every point are extracted. Extracting the roof shape and finding the mean of elevation of points within each roof section, the mean of elevation for every part of buildings is calculated (Figure below). All this preparation is done in ArcGIS Desktop to prepare the base shapefile to be imported to CityEngine.
Every single object of the building footprints imported to CityEngine will be considered as one shape or Lot. By clicking on any part of the building footprints, a shape will be selected and you can see the shape number in the inspector menu in the following figure. Each shape has many attributes for each section of buildings such as the mean of height and roof types.
The figure below shows the extrusion rule assigned to the shapes based on the height values in the attribute table.
In the following figure, you can see rule parameters in the building settings that can be overwritten base on layer attributes.
In the CityEngine CGA grammar rules, basic roof shapes such as flat, hip, gable, pyramid, and shed are defined. Examples of basic rules for different roof shapes are as shown in the figure below:
However, roof structures of campus buildings are complex. For more realistic and sophisticated roof types, new specific rules should be written for each complex building and this inverts the aim of procedural modeling which is facilitating the modeling process instead of hand modeling each building. Instead of writing complex rules or assigning one roof type for each building footprint, a combination of roof types is used for each building. In other words, each section of a building with a different height value has a roof type assigned to it. This has been possible by the use of LiDAR information. Each building is divided into different roof sections based on different heights and types. For instance, the following figure has a complex roof type. The middle parts are flat with various heights. The edges are shed and need a different rule to be applied.
A ‘roof type’ attribute has been created for the building footprints shapefile based on Google Earth images. To select different shapes with similar roof types in CityEngine, a simple python scripting is written. The python editor is executed inside CityEngine and is convenient for writing scripts and executing. The figure below is the window for creating a python module and the next figure shows a sample python code for selecting roof types of the same value.
The script then can be run by pressing F9 or selecting Run Script from the Python menu. Then for selected shapes, the rule parameter of roof type is modified. You can see selected shapes and roof type options in the figure below.
CityEngine rule file of ‘Building_From_Footprint.cga’ has three options for generating façade textures: (1) realistic, (2) Schematic, and (3) solid color. In the Figure below, you can see the three options for façade representation. You are going to explore these options in ArcGIS Pro. ESRI has a library of façade textures for different building types which we have used to texturize campus model. However, for a more realistic view of campus, images from building facades can be captured and used in this model.
In the images above, you can see that trees have been generated for the campus model. These trees are based on a tree dataset in GIS which has been linked to tree models using “3D Vegetation with LumenRT Models”.This rule [15]covers a lot of common trees found in North America. the models can be previewed in this Link [16].
The first step in creating tree models is to Match LumenRT model names with your tree names. This rule file uses the common name of tree species as the identifier of each model. Therefore, it is very important to keep your tree name in accordance with the name in the rule file. You can achieve this by adding a field in ArcGIS and filled it with the corresponding LumenRT names using Python or create an excel file where you match LumenRT tree name with your own dataset, and then link this file with your original dataset in ArcGIS. The second step is to import the tree dataset to CityEngine and align shapes to the terrain.
Selecting the tree shapes, you can assign the rule file and generate the rule.
After generating the rule, you may find that the tree models generated are not right. In this step, you need to assign the attributes from the dataset to rule parameters. To do this, simply click on the Attribute Connection Editor near the Name, select layer attribute, and find the field you add to your tree dataset.
To use the created models, you have two options: (1) export it to other formats, and (2) share it. The model can be exported to different formats such as Autodesk FBX, Collada, KML, and OBJ. For sharing the model, one option is to share the whole scene in the CityEngine Web Viewer. Another option is to share the rules as a rule package that can be used locally on your machine. Having the rule package (RPK), you can share it with others using ArcGIS Pro or ArcGIS Online. In Lesson 5, you will learn how to apply a rule package exported from CityEngine as a symbol layer to your database.
This assignment has three tasks associated with it. The first task will prepare you to complete the other two successfully.
Explore all three models and software websites provided below. Working through the questions will help you prepare for Tasks 2 and 3. By now these models should be familiar to you, but you may want to take some notes to help you organize your thoughts and keep everything straight.
Procedural model created at ChoroPhronesis [3] Lab using ESRI CityEngine [18] and CGA Shape Grammar rules. This model is shared with you using CE WebScene. You can turn layers on and off, zoom, rotate and explore the part of campus modeled.
Note: This interface may take a while to load. Please be patient. To see the full size interface with additional options click the Model 1 link [17].
Reality modeling created at Icon Lab using ContextCapture [20] software from Bentley. This model is photorealistic and shared with you as a YouTube video.
If you want to see a larger version of the video, click the Model 2 link [19].
Historical campus models (1922) created at ChoroPhronesis [3] Lab using Sketchup. These models are combined in ESRI CityEngine [18] with trees and base map generated using procedural rules. This model is shared with you as a flythrough YouTube video.
If you want to see a larger version of the video, click the Model 3 link [21]. [22]
After reviewing all three models and taking notes, start a discussion on what you believe the advantages and disadvantages are for each of the three approaches. Make sure that you comment on each other's posts to help each other better understand the nuances and details of each one. Remember that participation is part of your final grade, so commenting on multiple peers posts is highly recommended. Please also make sure to use information from the reading assignment on Shape Grammars.
Post your response to the Lesson 4 Discussion (models) discussion.
Once you have posted your response and read through your peers' comments, synthesize your thoughts with the comments and write a one-page paper max about the three different approaches.
Once you are happy with your paper, upload it to the Lesson 4 Assignment: Reflection Paper.
Criteria | Full Credit | Half Credit | No Credit | Possible Points |
---|---|---|---|---|
Clearly names and describes advantages and disadvantages, including time, learning curve, accessibility, applicability, flexibility, etc. | 10 pts | 5 pts | 0 pts | 10 pts |
Names areas of application that are best suited to each of the approaches | 3 pts | 1.5 pts | 0 pts | 3 pts |
The document is grammatically correct, typo-free, and cited where necessary | 2 pts | 1 pts | 0 pts | 2 pts |
Total Points: 15 |
We would like to acknowledge that we have by now given you a quite intense tour through various modeling approaches. It is, however, important to have at least an overview of what is currently available as the project you may be working on in the future (past this course) may require you to design a custom made solution. In addition to various workflows including structure from motion mapping and hand-on modeling that we explored previously, this lesson focused more deeply on procedural modeling and its origins in theories of shape grammar. Procedural modeling is a wonderful tool to both explore the organization of built environments in theory but also, more recently, as a powerful tool to make modeling more efficient. ESRI has realized this potential and bought City Engine which was founded at the ETH Zurich (their technical university). Keeping the different approaches in mind it important as we move on in the course.
You have reached the end of Lesson 4! Double-check the to-do list on the Lesson 4 Overview page to make sure you have completed all of the activities listed there before you begin Lesson 5.
Duarte, J.P.; Beirão, J.N. Towards a methodology for flexible urban design: designing with urban patterns and shape grammars, in Environment and Planning B: planning and design. Vol. 38 (5) 2012, pp. 879-902.
Knight, T. W. (1989). Shape Grammars in Education and Practice: History and Prospects, Internet Paper: http://www.mit.edu/~tknight/IJDC [23].
Stiny, G., & Gips, J. (1971, August). Shape Grammars and the Generative Specification of Painting and Sculpture. In IFIP Congress (2) (Vol. 2, No. 3).
Stiny, G. (1980). Introduction to shape and shape grammars. Environment and Planning B, 7(3), 343-351.
Links
[1] http://www.mit.edu/~tknight/IJDC/
[2] https://www.esri.com/en-us/arcgis/products/arcgis-cityengine/overview
[3] http://sites.psu.edu/chorophronesis/
[4] https://doc.arcgis.com/en/cityengine/2019.1/get-started/cityengine-faq.htm
[5] https://doc.arcgis.com/en/cityengine/latest/help/cityengine-help-intro.htm
[6] https://doc.arcgis.com/en/cityengine/latest/help/help-cga-modeling-overview.htm
[7] https://doc.arcgis.com/en/cityengine/2020.0/help/help-rules-parameters.htm
[8] https://doc.arcgis.com/en/cityengine/2020.0/help/help-conditional-rule.htm
[9] https://doc.arcgis.com/en/cityengine/2020.0/help/help-stochastic-rule.htm
[10] http://cehelp.esri.com/help/index.jsp?topic=/com.procedural.cityengine.help/html/manual/cga/writing_rules/cga_wr_attributes.html
[11] https://doc.arcgis.com/en/cityengine/2020.0/help/help-rules-attributes.htm
[12] https://doc.arcgis.com/en/cityengine/2020.0/help/help-rules-functions.htm
[13] https://doc.arcgis.com/en/cityengine/2020.0/help/help-rules-styles.htm
[14] https://doc.arcgis.com/en/cityengine/2020.0/tutorials/introduction-to-the-cityengine-tutorials.htm
[15] http://: https://www.arcgis.com/home/item.html?id=0fd3bbe496c14844968011332f9f39b7
[16] http://www.arcgis.com/apps/CEWebViewer/viewer.html?3dWebScene=6015f7d48dff4b3084de76bcf22c5bca
[17] http://psugeog.maps.arcgis.com/apps/CEWebViewer/viewer.html?3dWebScene=e08bb0c65fb74f849e3c95d2e7184474
[18] http://www.esri.com/software/cityengine
[19] https://www.youtube.com/watch?v=8cFc0In_Dkw&index=6&list=PLacF1o4TNbFlNYeE8WAJbQ6IUQOxF7_Ez
[20] https://www.bentley.com/en/products/brands/contextcapture
[21] https://youtu.be/zYQvTJCpUFk
[22] https://youtu.be/zYQvTJCpUFk?rel=0
[23] http://www.mit.edu/~tknight/IJDC