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.
This tutorial will give you a quick overview of CityEngine's navigation tools and user interface. And for this project, we'll use the International City we created in the previous tutorial. If you're just joining the series, you can create this project through the City Wizard. To access the City Wizard, go to the File menu and click New. This will open a new dialog box and you can choose City Wizard in the CityEngine folder and then click Next. Give a name to your city. I'm gonna call this one International City. And for our purposes, we can just accept the defaults and scroll through the wizard. Once you're done, click finish. And for me, I've already created this city, so I'll click cancel. Now your city might take a little while to generate but pretty soon you'll have something that looks similar to what you can see here.
Now for this lesson, let's set up a scenario. So just imagine that you're an urban designer and you've been charged with creating a new residential development. To help you complete this task we'll build your understanding of the user interface and develop your skills using the navigation tools in CityEngine.
First, let's look at the main windows in CityEngine. The first is the scene editor. In our scene, we have the environment layers that control the scene's light and the scene's panorama. One of the functions of the scene light layer is that I can come in here and change the solar intensity values. I can decrease intensity to maybe 0.5 and we can see the light change in the scene. I'm going to set it back to 1 just to make the scene a little brighter.
Next, we have map layers and these contain images that make up the base map and the context for your scene. We also have something called the obstacle map layer and this constrains where the city will be generated. So if I go ahead and turn off the heightmap layer, and turn on the obstacle layer, you can see those areas in black represent areas of vegetation and water in the landscape. And CityEngine recognizes that it can't go ahead and build buildings in these areas. So this is a useful way for you to help constrain where your city will actually be generated.
Finally, we have graph layers. What we can see here is a street layer and it's made up of networks. And these are like our edges and nodes and blocks, and these are used for generating shapes and models dynamically using CGA rules.
Next, let's look at the Navigator window. The Navigator is used for project and scene management and consists of the folders you can see here. The first is the assets folder. The assets can be in different formats. For example, obj, and these are used by CGA rules to texture the models you see in the scene. Next is a data folder. I use this folder to store GIS data in a file geodatabase format. You can store things like colada files or other additional datasets here too. The images folder stores additional imagery like viewport snapshots, for example. The maps folder contains the images used by the map layers. So for example, we have the texture image that's creating the base map for this scene. And we also store the obstacle image here that we saw earlier. The models folder is where you can store 3D models exported from the CityEngine scene. The rules folder contains the CGA shape grammar rule files. And these rule files call on the assets that we saw earlier to create the textures for the 3D models. And next is the scenes folder. So the scenes folder is where we store all the scenes that we build in CityEngine. And finally, we have the scripts folder where you can store things like Python scripts.
If you ever need to add any additional data to any of these folders you can easily do that by dragging and dropping from your native file browser. You have the option here to configure the drag-and-drop setting, so I can link to files so if they're updated on my folder system they'll update directly in my navigator or my workspace as well. Or I can choose to copy the datasets into the workspace. Besides project management, this window lets us open a scene by right-clicking and we can also access the CGA rule editor window by double-clicking on one of the CGA rules in the rules folder. Once the CGA rule editor is open, we have the option to view and edit the rules either in a text view, which we can see here, or a visual view. And we'll cover CGA rule editing in more detail later. And I'll just switch it back to the textual view.
Now let's take a look at the inspector window. The inspector shows all the attributes and the parameters of the assigned CGA rules. To view rule parameters, first select some buildings by holding the left mouse button down and dragging from left to right. You see a blue rectangle on the screen and when you release it, you can see some buildings highlighted in blue. And then in the inspector window on the right, you can see under the street parameters, the different values available to change. So we have things like street width and sidewalk width and I can update these based on my design intent or maybe feedback from a client. And finally, we have the log window. And this window is useful for troubleshooting errors or if you're getting any strange behaviors. And it gives you good feedback ranging from informational messages to severe errors like out of memory for example.
Okay, now we have an overview of some of the windows in the user interface. Let's take a look at one of the main windows, which is a 3D viewport. And this is where we visualize and interact with the 3d scene and it's where I'll sketch out the new development. First, let's choose an area suited for new development. From looking at the scene, I think somewhere down by the waterfront would be good. To zoom to this area, hold the left mouse button down and drag from left to right to select some of the streets. Then click on the frame selection tool from the toolbar in the top right of the viewport. This quickly zooms me into the area. Another way to quickly navigate to this area is to create a bookmark. The bookmark menu is located in the top right of the viewport window and it has a small star icon. Click on this and then from the drop-down menu choose to create a new bookmark. I'll call this one project area and click OK.
So now that I've saved the extent of my project area, I can quickly zoom out. So if I press the A key, it will zoom me out to the extent of my whole project. And to zoom back again, I'll go up to the bookmark menu and choose project area. Depending on what you're doing in your project, you might like to have another viewport window open to give you a more complete view of your project or of your scene. So for my purpose. I think I would like to have the perspective scene as well as a plan view or a top-down view. To do this, I can open a new viewport window from under the window menu, and I can click and drag the viewport and drop it below my original viewport window. If I click on the camera views, you can see that this is in a top-down view. Now I chose this view for my specific purpose, but there are also a number of default views that you can use and they're designed for other tasks. So the first one is called the default view, handily enough, and this one is really good for an overview of your scene and for management tasks like import and export. The next one we'll take a look at is called the minimal layout. Now this one has a perspective view and some editors open, which makes it pretty good for presentations. The next two views are similar to the default views, but we get two views. So we have a perspective at the top here and a plan view at the bottom. And you can also have this in a vertical layout. And then finally to make rule editing more efficient, we have a couple of views here. Let's take a look at the standard rule editing view. This layout has one perspective view and leaves more area for the CGA editor, so it's especially suited for editing rules.
Okay, now I'm just going to return to the default layout because that's going to suit my purpose of sketching out the new development. Now before we get started with some of the navigation in the scene, I want to show you some of the view settings that you can adjust, so you can see the models better. So under the view settings menu, here I'm going to uncheck Wireframe on Shaded Textures. And now we can get a better view of what our models are going to look like. Now let's save this perspective view. So under the window menu, choose Layout and then Save Perspective As. Then all you have to do is give this a name. For me, I'll call this project view and choose okay. So now I have this perspective saved if I ever want to use it in a future project. Now I have a viewport layer, let's look at how to navigate. So I can use the navigation tools, tumble, track, or dolly. Or it's even easier to use the shortcut keys. So here we have alt and the left mouse button and to pan, alt and the middle mouse button and then to zoom in and out, I'm using the alt key and the right mouse button. A recommended navigation workflow is to select the features or the area that you want to work in and choose a frame selection tool. Once you're zoomed in closer, you can explore the selection using the tumble, track, and dolly shortcut keys. Also, if you ever want to deselect a selected feature, you can just hold down the ctrl, shift and A keys.
Now let's look at how we can interact with the models in the viewport using selections. Selecting features is also an essential skill for applying rules. So one way we can select features is using a rectangle. So here from left to right if I drag, I select all the features that fall inside the rectangle. But if I go from right to left, I get all the features that touch the borders of the rectangle, as well as fall inside. Another thing I can use is from the selection menu. So I can choose to subtract from the selected features, and we see the result there. I can also do things like invert the selected features, and we can see the results in the window here. And then to deselect the selection, you can do control, shift and A.
Now let's see how we can use selections to apply rules for their new development. In this step, we'll use some of the object edit & transform tools to create the new development. First I'll zoom back to the study area using the bookmark. And the tools that we're looking for are located here above the viewport. I'll select the polygon street creation tool and quickly sketch out some streets and blocks for the new development. I'm going to select some of these blocks, so I'll do the drag a rectangle selection technique. And if I right-click, I can choose select, and from the context menu, I'm going to choose select objects of the same group. Then under our block parameters in the inspector window, I'm going to change the type to recursive subdivision, and adjust some of the lot areas. Once I'm happy with the design, I'll go back in and select the blocks again, and right-click and choose select objects of the same group. And then I'm going to drag and drop this international city rule directly on to my selected features. And straightaway you can see we've generated a new urban development. So in the inspector window, you can see under the International City group we have some parameters available to change. So under type, we have different building types, high-rise, office, residential. I'm going to leave this as apartment.
And sometimes when you're working with a complex scene like this one, if you want to make an edit, it's useful to be able to select the building you want to interact with and then isolate it. So to do that, select a building with your selection tool and then press I on the keyboard to isolate the selection. And then you're able to come in and edit the specific building you're interested in. So here I'm changing the tree type to a random forest mix, and I'm changing the building type to an office building. So once you're happy with your edits, you can press I, and your models will come back. Now if we press the A key, we can zoom out to see the entire scene. I'll zoom in a little bit here. When you're finished with the visualization and you want to see perhaps more of your model, you can press the spacebar and this will maximize your screen real estate by hiding some of the other windows. Now we'll change some of the display settings so we can see the models a little bit better. So here I'm going to add some shadows. I think I'll also add the ambient occlusion as well. And then we'll turn off the grid that you can see there so we can better see the models. These kinds of view settings are really good if you want to take some high-quality screenshots of your CityEngine scene.
Okay, so now you know your way around CityEngine. You'll use your navigation skills and project management knowledge in the next tutorial, which shows you how to create your first CityEngine project.
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