Procedural Colosseum

Procedural rules are normally associated with creating detailed 3D models for a large set of data.

CGA (Computer Generated Architecture) rules are also effective in terms of reducing the time it takes to create a detailed landmark (such as the Colosseum) manually. This post shows a simple process and the code that was used to create a quick landmark.


A simple arch and ledge object (.dae) was created in Sketch Up, which was used on the outer level.

Arch collada object from SketchUp

The Colosseum footprint digitized manually as a shapefile from the ArcGIS Imagery basemap.

Oval footprint shapefile

The code with some comments is below:
## Levels attribute serves as a counter, similar as the ## count in a for Method attr levels = 4 Lot--> Go ## The outer level only has an offset of -2, therefore it ## calls the Level Rule with an argument of (-2) Go--> case levels == 4: Level(-2) case levels == 3: Level(-15) case levels == 2: Level(-15) case levels == 1: Level(-15) else: color("#FFC68C") ## The Level rule creates an offset using the argument is ## was called with (x). It then calls the Border_Split rule ## to extrude each level Level(x)--> offset (x) Border_Split Border_Split--> comp(f){border: Extrude| inside: Recursive} ## The Extrude rule extrudes each level 12 (level height) * levels, making ## sure that each ## level's height is reduced by 12. ## Also the first level (a.k.a the outside level) is represented ## differently from the ## other levels, as it will have Arches on the side Extrude--> case levels == 4: extrude (levels*12) Split_First else: extrude (levels*12) Split_Rest ## The recursive rule deducts 1 from the counter and Re-calls the Go rule, ## creating a different extrusion height for each level Recursive--> set(levels, levels - 1) Go ## First (outer) level is divided into the front (which are assigned arch ## geometries) and top sides (tower) Split_First--> comp(f){front: Wall| top: Tower} ## Splits the outer-wall vertically every 12 meters, leaving a 2 meter ## ledge ## at the top. Each split is assigned an arch, while the ledge keeps its ## normal shape Wall--> split(y){{12:Arch}* | 2: Shape} Arch--> i("data/Raw/Arch.dae") r(0, 90, 0) s(scope.sx-0.1, scope.sy-0.1, 5.5) color("#F1B57E") ## The top part of the outer level is split into blocks on the X and Y axes ## and the middle bloch is extruded 5m creating a pole/tower Tower--> split(x){2.6:Shape| 0.2: Tower2| 2.6:Shape} Tower2--> split(y){1: Shape| 0.2:TowerExtrude| 1: Shape} TowerExtrude--> extrude (5) Color ##The remaining levels are colored dark grey on top and light on the sides Split_Rest--> comp(f) {back: DarkColor| top: Color} Color--> color("#514E4D") DarkColor--> color("#F1B57E")



The Result:

Random Tree Generation using 3D Vegetation Library

The 3D Vegetation Models Library from LumenRT is a very user friendly way of creating quick, realistic urban vegetation with a variety of plant species.

The library offers a large variety of trees (some of which I have never used). I wanted the CGA rule to create trees for my shapes at random, from a specified selection. A small alteration to the CGA code changes the default value.

For this example I used the Plant_Loader_with_LumenRT_Models.cga

The Plant_Loader_with_LumenRT_Models.cga uses the Name attribute to determine the file path of the model. The "Alder Buckthorn" model is used as a default. As seen below.

attr Name = 'Alder Buckthorn'

By changing the Name attribute to a conditional attribute, and setting a probability for specified plant models, the CGA rule will automatically assign models to shapes. In the example below, only 20 tree models were specified with a propablity of 5% each.

attr Name = 5%:"Alder Buckthorn" 5%:"American Chestnut" 5%:"American Sycamore" 5%:"Australian Pine" 5%:"Black Locust" 5%:"California Walnut" 5%:"Date Palm" 5%:"Ficus" 5%:"Field Elm" 5%:"Northern Red Oak" 5%:"Red Hickory" 5%:"Sassafras" 5%:"Southern Magnolia" 5%:"Strawberry Tree" 5%:"Sweetgum" 5%:"Umbrella Acacia" 5%:"White Ash" 5%:"White Oak" 5%:"White Poplar" else:"White Willow"

The resulting rule only assigns the models  that were specified as a default. Keeping the original @Range annotation in order to still be able to select any of the other available models.

Network Analysis in CityEngine!

OK, actually its network analysis in ArcScene...and viewing it in CityEngine :D

The aim of this task was to create a 3D routing workflow to calculate the route to the closest emergency assembly point from anywhere within a building.

I started with the floor layout of a building (which have been captured from CAD data). The floor layout polygons are z-enabled and the stairs have been included. As seen below in ArcScene.

Using the rooms, corridors and stairs as a guide, I proceeded to capture Z-enabled emergency evacuation routes for each floor. After a frustrating route capturing session the emergency routes were created.

The next step was to create a network dataset from my assembly points and emergency routes.It is vital that the emergency routes are split at each and every intersection, as well as to make sure that each assembly point is snapped (in 2D and 3D) to the endpoint of an emergency route.

Using Model Builder in ArcGIS, I developed a model which calculates the shortest route from a specified point to the nearest Assembly Point according to the network dataset in 3D.

The model does the following:

1. Takes the Network Dataset and creates an empty Closest Facility layer
2. It then takes the z-enabled assembly points and loads it into the Closest Facility as the facilities
3. It then takes the user-specified points (interactively pointed on map - see image below) and loads it as the incidents features of the Closest Facility layer. To read more about Network Analyst's Closest Facility Layers click here.
4. The model makes copies of both the incidents and the facilities and outputs it to a specified FGDB.
5. Finally Model Builder uses the Solve tool to perform the analysis and determine the shortest route.
6. Next step is to apply a pre-defined symbology layer to the resulting Closest facility route layer
7. The final step consists of utilizing the Select Data tool to select the Route layer (line with 3D symbology applied) to export it to both a line and multipatch feature using the "Feature class to Feature class" and "3D layer to feature class" tools, respectively.

The Red flag represents the starting point, while the Green flags represent the Emergency assembly points

In this example, CityEngine was used minimally. It was used to create some of the walls around the rooms ans well as the steps for some of the staircases. The final ArcScene document was saved and exported to a web scene using the "Export to 3D Web Scene" tool (the next step will to include this tool in the model builder, creating a "one-click" solution from model builder to web scene.

View the 3D web scene here.

Cape Town at a Glance - 3D

It took a while to remove all the cobwebs after the long break, but I finally got around to playing with CityEngine 2013 (could have just as well been CE 2014!).

The main talking point this year at the office is the first ever Esri Africa User Conference in Cape Town later in the year. Esri South Africa created an ArcGIS online story map to help guide visitors around the city. I then decided to create a 3D version of that map. This was the result...


The first thing that I noticed with CityEngine 2013 is the new way it displays raster images. When I draped an aerial image over a height map, I saw that raster values with a 0 height (at sea level) were displayed as white. Although the image layer appears to be a null, for cells with height values of 0; it displays the entire terrain once exported.

Aerial terrain layer in CE 2013

I decided to include the Cape Town building footprints in the scene as 3D basemap only. Since the buildings are not really the main focus area of the scene, and used as reference only, I applied a simple Extract rule to extrude all the buildings to their height attribute and set the transparency at 0.8 (1 = fully visible).

Cape Town buildings

The next step was to create simple rules to display the data from the ArcGIS online story map. The 4 feature classes that were used were point features for:

• Breweries (always important!)
• Food and Drink
• Things to Do
• Where to stay

A simple CGA rule then assigned a 3D symbol for each point type:

#GeoBeer

Where to Stay

Food

Things to Do

Using the web scene to display image info

The point feature classes already contained URL information for each point of interest (displaying images). I created a new field which would contain the URL value as part of an IFRAME string. Using Field Calculator in ArcMap the new IFRAME fields were calculated as:

"<iframe height = "410" src = ' " + [URL] + " '></iframe>"

Doing this enabled the web scene to access imagery from the web, once it has been published.

Using an IFRAME to include image information

Also included in the web scene are locations of traffic cameras which monitor the traffic density on some of the major highways. Using an IFRAME string, each camera pulls a live image from the web and displays up to date conditions for that road section.

Live traffic camera

The live feed for the example above can be seen below:

The live traffic feed was obtained from i-traffic.

The web scene provides a fun, very interactive alternative to a normal 2D map.
One of the major changes with CE 2013 is the compression of the web scenes. My previous Cape Town web scene had a download weight of about 30 MB. With more data in the scene, the Cape Town at a Glance scene has a total size of 10MB.

Cape Town

You can visit Cape Town here.

P.s. 1000 points to the person who finds the Clock Tower!

Revit meets Procedural: Best of both Worlds

Often the buildings of new/re-developments are designed by architects which designs the buildings in a specialized software type. An example of this is the use of Autodesk's Revit software. Creating one detailed building can be a time-consuming process. Imagine modeling an entire neighborhood! This post looks at how CityEngine can streamline this process for an entire new development.

In the example developers created 4 individual housing building types (55 sqm ; 65 sqm; 85 sqm and 110 sqm) in Revit.

Revit models

The objective was to randomly place one of these 4 models at each residential lot of a new development area. In order to place these models on a lot using CityEngine's procedural rules, the models had to be exported to a .obj file format, which can be easily utilized by CityEngine.

The Revit models were however only created for the residential lots, while the generic buildings for the commercial lots had to be created procedurally. Therefor the first action that the rule does is test to see whether the Zone attribute of the feature is either Residential; Commercial or something else. As seen in the Lot Start Rule below:

Lot--> case Zone == "Residential": 
SplitErf
case Zone == "Commercial":
CommBuild
else: NIL

For residential buildings, a setback area of 6.5m were created and colored dark green, while the remainder was used to place the .obj models. The models were then Scaled, Centered, Colored and Placed...

SplitErf-->     setback(6.5){ all: t(0,-0.2, 0) DarkGreen| remainder: Building }
Building-->    s(10,5,10) i(BuildingModel)t(0,-1, 0)  center(xz) LightGrey

Residential areas

The commercial buildings had no Revit models and had to be generated procedurally. The first step (similar to the residential buildings) was to create a "Building footprint" from the existing feature using the setback tool. The outside area of the feature was colored Beige while the remainder was extruded to the randomly selected building height. The extruded buildings were then divided into a top part (Roof); a front side (entrance) and the remaining sides. The building block was then split vertically and horizontally to create building tiles. These building tiles each represented a window, which were made transparent.

Commercial Building

For the front side of the building an entrance roof overhang was created (the ground floor of the entrance was also colored differently than the other sides.

Because the Commercial buildings weren't the focus point of the scene, a generic "Commercial-appearance" rule could be applied to all the features. It only needed to indicate where commercial areas were located (not a lot of detail necessary).

Additional features were added such as Static Buildings ( for example Religious buildings, a Hospital, Clinics; a School; and Sport Stadium) as well as the surrounding area elevation and imagery which contributes to a better understanding of the area.

Hospital

Stadium and Clinic

The CGA rule file that was created, generated Residential and Commercial buildings in completely different ways. 3D building geometries were generated  using existing Revit models for multiple features at the same time or (in the case where there were no existing models) used the procedural CGA functionality to create new buildings. The end result is a 3D scene that moves uninterrupted between different software types.

School (SketchUp)

Bubbles and Towers

This week I played around with the idea of using CityEngine to view the coverage areas produced by cellphone towers in 3D. This is just a quick example to see what it would look like.

As always, getting your hands on data was quite an exercise. I eventually found a spreadsheet with the locations and types of towers points in the study area. Unfortunately the towers point data didn't have any ranges associated with them. After consulting a reliable source (Wikepedia) I very carefully estimated (guessed) the range of each tower. This is the point where I probably have to mention that this example was done purely for research purposes and that none of the ranges are correct....as far as I know.

The points were plotted from an Excel spreadsheet in ArcMap and converted to a point feature class. The feature class points were interpolated to accept the z-value of an elevation raster of the area. Next I added a Range field to specify the maximum range of each tower according to its type. The ranges varied between 100 - 800 meters.

Range Bubbles

I used the ranges as the buffer field for the 3D Buffer tool in ArcScene to create multipatch bubbles of the maximum ranges for each tower. The range bubbles were imported into CityEngine and a rule file was used to set their colors and transparencies.

Towers

The points were converted to the different tower models according to type in CityEngine. The tower models were downloaded from Trimble 3D Warehouse.

Tower 1

Tower 2

Tower 3

Tower 4

A CGA rule was created to generate the models and exaggerate the size for better visibility. The rule uses the i (geometry) asset tool to plot the appropriate tower model and then re-scales it using the s(x,y,z) tool.

The Code:

attr Structure_Type = "Rooftop"


Lot--> case Structure_Type == "Rooftop":
Antenna
case Structure_Type == "Camouflage":
Camouflage 
case Structure_Type == "Monopole":
Monopole
case Structure_Type == "Lattice":
Lattice
else: Camouflage


Antenna--> s(6,6,6) i("models/3DWAREHOUSE/Antenna.dae")

Camouflage --> s(20, 200, 20)i("models/3DWAREHOUSE/CellTower.dae")

Monopole --> s(50, 100, 50)i("models/3DWAREHOUSE/Monopole.dae")

Lattice --> s(30, 200, 30)i("models/3DWAREHOUSE/Tower3.dae")


The rooftop type towers are located above the ground on top of buildings. Some building footprints were added to show this. CGA rules were also created to set the color and transparency of the buildings and range "bubbles" as well as extrude the building to their correct heights.

Areas with a lack of coverage were identified. Additional towers were added and their coverage were calculated. These additional coverage areas are displayed in the web scene as yellow bubbles. Finally IFRAME attributes were created for all towers, displaying a picture when a tower is identified.

Final web scene

View the web scene here (Note: It is about 48MB)

Serving a large 3D City Basemap

Urban data normally arrive from different sources. The challenge is to put them together in order to create an accurate representation of the city.

In the case study that I have been working on the challenge was to share a 3D representation of an entire city among users.

I have done a number of projects with CityEngine and considered using the 3D webscenes for this, however I found a couple of limitations:

• CityEngine uses Python scripting to import cities with a diameter of about 13km. The city in this case study has a diameter of more than 40km.
• The final compressed webscene (.3ws) has to be downloaded before being viewed. Best practice limits this file to 30 MB

I eventually (after a lot of research and blog reading) decided to try and host my 3D Basemap on ArcGIS Server as a Globe Service. 

The Workflow:

The data consisted of 3 types of building features:

1. Photo-realistic multipatch features of buildings
   
   
   
2. Digitized 2D building footprints
   
   
   
3. 2D cadastral properties
   

Step 1: Converting the .3ds building files to multipatches is a whole blog post on its own. I will explain this in a bit more detail later. (Hint: The Import 3D files tool + Blood Sweat and Tears). As the focus of this blog is hosting a city on ArcGIS for Server, just know that the textured buildings were finally converted to multipatch features. It is also importatnt to know that the Buildings were set to their correct z-values during the conversion process. 

Step 2: The 2D Building footprints were provided with the correct z-values through the Interpolate Shape tool. The footprints were then extruded to their height attributes in ArcScene and converted to multipatches by using the  Layer 3D to Feature Class tool. 

Step3: At this point the remaining areas of the city had still had to be represented by building footprints. Due to the lack of data, generic "fictional" footprints had to be generated in order to flood the rest of the urban area.

To generate these footprints I used CityEngine. The 2D cadastral data first had to be divided into 7 regions (due to the fact that the total area of the city is too large for CE).

The properties contained attributes describing its zoning characteristics as well as restrictions. Using these attributes as  guide lines for building shapes (L-shape, O-shape and U-shape) and heights, buildings could be generated procedurally in CityEngine. The procedural rule was based (and borrowed from) on the rules found in Tutorial 8: Mass Modeling at the CityEngine Resource Center.

The result was 7 regions of procedurally generated  (fictional) buildings ( +800 000). 

The buildings were then combined before merging with the "real" digitized building footprints.

Green = Digitized footprints      Red = Procedural footprints    Pink = Photo-Realistic buildings

Step 4:  The final step was to add each of the multipatches (textured as well as extruded footprints) to ArcGlobe. I decided to create 2 globe service. The first one would show the Textured buildings and the second one would be the footprints.

Publishing a globe service was much easier than I anticipated. Once the multipatches are added to ArcGlobe simply remove all elevation and image layers (the standard ArcGlobe layers); click on File > Share As... > Service... Next fill in the relevant information in the Service Editor > Analyze and Publish your globe service.

Once the Service Publishing Result has popped up, you can open a new ArcGlobe and access the data straight from your ArcGIS Server.

The final result is two Globe services which is hosted locally and can be shared to other users, thereby creating a online 3D Basemap of the City.

City globe services