Building Simple Urban Development rules Post 4: Reporting on Building Floors

Up to this point in the Building Simple Urban Development series we've had a look at designing parts of the city. Extending on the previous post where I added detail to our rules (in the form of parking), this week I will have a look at creating reports at floor level.

In most cases a building is occupied by various inhabitants. In the example used during this post, we will imagine that each building can have a "Mixed" zone type. These buildings have different uses per floor, these will include Commercial Use, Residential Use and Unspecified. I will also create reports showing revenue generated by all floor types (using the floor area).

Individual Floor Usage

Attributes

In this post, there was only 5 attributes added (see the image below). These were:

• CommercialFloorUse: The % of floors that will have a commercial use
• ResidentialFloorUse: The % of floors that will have a residential use
• CommercialRevenueSquareMeter: Revenue generated per square meter of commercial use
• ResidentialRevenueSquareMeter: Revenue generated per square meter of residential use
• VoidRevenueSquareMeter: Minimum Revenue  lost per square meter

     **Another disclaimer: Just ignore the bad attribute naming convention....I didn't spend too much time on the attribute names

• I also added a "Mixed" type to the ZoneType attribute that we created in Post 2.

Attributes

Rules

Only two rules were added during this post: ColorFloors and ColorFloors2 (once again great usage of my naming convention).

• ColorFloors checks if a floor has a "Mixed" ZoneType, and calls the ColorFloors2 rule if it does. It also creates a report for all floors created. To read more about reports, click here.
• ColorFloors2 uses the CommercialFloorUse and ResidentialFloorUse attributes to determine the usage of each floor by applying the "p-function". The remaining floors  are assigned a usage of Unspecified. The rules also create reports on each floor usage as well as the potential revenue generated.

Rules

Reports

The reports that are created with the new rules can be seen in the image below. The N, Sum and Avg, columns returns the Count, Sum and Average of each floor or floor revenue, respectively.

• All Floors displays the count of all floors (excluding the ground floor) 
• Commercial Floors, Residential Floors and Unspecified Floors returns the count for each floor usage type
• Commercial Floors Revenue and Residential Floors Revenue returns the count of each floor type as well as the estimated revenue generated by each (as a sum and average). The revenue is generated by multiplying the square meters of the floor (getArea in the image above) with the price-per-square-meter for the specified floor type (e.g. CommercialRevenueSquareMeter) 
• The Unspecified Floors Revenue calculates the estimated amount of revenue lost by having a unspecified/void floor. 

Reporting per Floor

Building Simple Urban Development rules Post 3: Adding Detail (Parking)

In the 3rd post of the Building Simple Urban Development rules series, we'll have a look at extending the rules by adding more detail.

In the previous post we divided our building into 4 "types", Commercial, Industrial, Residential and Parks (coloring each one individually). In this post we'll have a look at adding parking areas to our buildings.

Procedural Parking in CityEngine

But first we'll make a couple of assumptions:

• Parking areas will only be assigned to half of all Commercial buildings
• Parking areas will start from the floor and will extend to a quarter of the building height.
• We will add ramps between the parking floors on both sides of the building (up and down)

Attributes

Following the same template for the rest of the post series, we'll first have a look at the attributes added during this post.

Attributes

From the image above, the attributes that were added include:

• useHeight ( remaining building height after the parking has been subtracted)
• floorHeight (random number between 2.8 and 4 meters)
• parkingHeight (roughly a 1/4 of the building height)
• rampObject (a Collada file for the ramps)
• Textures
• Counts for reporting purposes

Rules

There were quite a lot of rules added during this post. The first half of the rules are shown below

Rules added (part 1)

These are:

• ErrorTracking: Defines whether a building exceeds its height restriction
• SplitBuilding: Guides 50% of all Commercial buildings to create parking
• ExtrudeFloor and ExtrudeFloor2: Uses the bottom part of an extruded building (while discarding the sides and top parts) and extrudes it inversely (-Height)
• CheckDimensions: Verifies that neither sides of the footprint polygon exceed 60% of the length of the other. This helps to cancel out lop-sided buildings
• HasParking: Checks if a building exceeds it maximum height and splits it accordingly:
• If it exceeds the max: The building is split into a groundfloor, parking, remaining height and an error
• If it doesn't exceed the max: It is split into a groundfloor, parking and remaining floors
• RemainingFloors: Counts and reports on the number of non-parking floors. Splits the remainder of the building into floors and color it
• CreateFloor: Counts and reports the number of parking floors and uses the bottom part of the floor "cube" to create parking floors.

The second part describing the rules in this post is focused on splitting each floor horizontally into parts in order to create Ramps, General Parking, Ramp Platform and Pillars respectively (see image below).

Splitting the Parking Floors

I think it would be best to look at the above image step-by-step:

1. 50% of all Commercial buildings are defined as having parking available
2. Roughly 25% (bottom 1/4) of the building is split into parking floors, and then split again into sections
3. First, the parking floor is split into three parts (from top to bottom in the image). A ramp on the left, general parking and a ramp on the right
4. Each ramp is then split into three parts (from left to right). A ramp platform at the top, the actual ramp, and another ramp platform at the bottom
5. Similarly each ramp platform is split (again) to create pillars.

I know, I know....another long post. So grab a quick cup of coffee and lets wrap this up...

The rules showed in the image above are:

• ParkingRamps: Splits the parking floor in 3 parts (ramp, parking, ramp)
• ParkingMain: Textures the general parking area
• ParkingRampsLeft & ParkingRampsRight splits each ramp into 3 parts (platform, ramp, platform)
• Each of the ParkingPillar* Rules splits the 4 platforms (4 corners of the building to create pillars)
• ExtrudePillar: Extrudes the pillar upwards
• AddRamp: Adds ramps, either upwards or downwards. This rule calls a Collada file and rotates it accordingly
• Texture: Generic rule that takes a path name to an image as input and applies the texture to the shape

*Disclaimer: This example was made only to show the ability of using procedural rules. These methods are not perfect (far from it) so use the information and techniques on your own risk. 

Building Simple Urban Development rules Post 2: Applying Scenarios

I started my previous post by talking about New Years resolutions, and posting more often....I then went on to publish the follow up post 6 months later.... My apologies for the very late response.

In my previous post I started look at the basics of CityEngine to create easy-to-use rules that incorporate  commonly found Urban Development rules. This post will extend that theme by applying various scenarios to a city. The post shows the ease at which CityEngine quickly updates the 3D content using different sets of attributes.

Applying different Zoning scenarios on the same data

Continuing from the 1st post of this series, we'll start by adding some more attributes. The first two attributes in the image below specifies the themes that will be applied to the scene.

• Scenario: This attribute defines the Zoning theme that will be applied to the scene; either predominantly Residential, Commercial, Industrial or Mixed
• ErrorScenario: If true, the scene will show buildings that exceed its height restriction. If set to false, the scene does not allow the buildings to exceed the height restriction at all.

The remaining new attributes are:

• ZoneType: Assigns a percentage of the shapes to a ZoneType, according to the specified Scenario
• Height: This attribute is determined by the getHeight function (described below)
• HeightRatio: Assigns a value to HeightRatio according to the ZoneType. This value will be used later by the getHeight function.
• MaxHeight: This is the height restriction associated with each ZoneType 

Adding rule attributes

This post adds one function to the rule, namely the getHeight function. The height is determined by multiplying the HeightRation with the square root of the shape area.

Functions

Finally, the Rules that were added were:

• CreateBuilding: If the ZoneType is "Parks", go-ahead and color the shapes green, else call the ExtrudeBuilding rule
• ExtrudeBuilding: If the ErrorScenario is set to true call ErrorTracking, else compare the building height to the maximum height. 
• If height exceeds the max, extrude the building to the max, otherwise just extrude the building according to the height. (So to recap: if the ErrorScenario is set to false, the height exceeding errors will not be visible)
• ErrorTracking: Checks whether the Height attribute exceeds the MaxHeight, if it does it will call the SplitBuilding rule.
• SplitBuilding: This rule splits the building into a top (and colors it) and then into sides (which calls the ValidateBuildingHeight
• ValidateBuildingHeight: This rule splits the sides of the building horizontally at the maximum height. Everything below this split is colored according to the ZoneType while the parts exceeding the maximum height is colored as red.

New Rules

To see the ErrorScenario theme in action, have a look at the video below.

Building Simple Urban Development rules Post 1: Coverage areas

First thing first... Happy New Year! I've got a feeling that 2015 will be a big year for 3D.

After the long off period, I find it difficult to start being productive straight away... I'd much rather focus on a little bit of 3D first.

Normally when writing a blog post I get a bit carried away and end up writing very long posts. So I've decided to start writing shorter, more to the point posts. This will probably help me write more often...call it a New Year's resolution if you want :)

Building Simple Housing Development rules

The focus for this series (for lack of a better word) will be back to the basics in the sense that it will focus on Urban Development (CityEngine's original purpose believe it or not).

It is probably worth mentioning that I am expanding this series as I go along, so I have no idea what will be the follow up post, or how many parts there are - guess we'll find out together.

Post 1: Coverage areas

In short, coverage areas (in this post anyway) refer to the percentage of the lot/property area that is covered by a building footprint. As I am not from a town planning background, I don't necessarily need to know about the HOW and WHERE of using coverage areas, I only want to be able to represent the rules procedurally. The best way of achieving this is to create a robust RuleFile that can be used with a number of different inputs.

Coverage refers to the % of property that is covered by a building

The first part of creating the rule files is - as in most cases - is setting up some attributes and functions. Normally writing a rule file is an iterative process, and this part will most probably be re-visited.

   

In the image above, we can see two coding blocks for attributes and functions. Lets start from the top and work our way down:

The first line creates a constant called Area. The value of Area is determined by calling the getArea function. The getArea function in turn executes a CE system function (geometry.area()), which returns the surface area of the property. Area is set as a constant so that it can not be changed by the user.

The ValidArea attribute value is determined by the getAreaValidation function. This function checks if the area of the property is larger than 100 m² and returns a 1 if is, otherwise it returns a 0. This attribute will be used at a later stage to ignore areas that are too small.

The remaining attributes define values for the Minimum Coverage, Maximum Coverage and the offset area.

The image above shows the simple rules to procedurally represent coverage areas.
The First step (Lot) is to check whether the area is large enough to contain a building. The second part (TopArea) makes sure the rule works with the top part of the the property.

The FootprintOffset rule then creates an offset using the OffsetDist attribute. The offset size can be changed as needed by the user. It then calls the SplitFootprint rule.

The SplitFootprint rule applies different rules to each of the shapes created by the offset tool: border and inside. The border is colored RED, while the inside shape calls the CheckCoverage rule.

Lastly, the CheckCoverage rule checks whether the Coverage (new shape area ÷ original area) is within the Minimum- and Maximum Coverage range. The tool also display the Coverage in a report that can be seen in the Inspector window in CE (see video below). If the Coverage is within the valid range, it is displayed as Green, else it is colored yellow.

The video below shows how the coverage area changes dynamically when the attributes are altered. You can see the changes in the area (Yellow vs Green), as well as the report (Coverage) when the Maximum Coverage, Minimum Coverage and Offset attributes are changed.

Rugby Analysis in 3D

After 3 months of distractions and traveling I had to actually force myself to sit down and write this post. That is why the post (mostly about sport statistics) comes a couple of days before the end of the tournament that is the focus point of the post. My apologies. In any case...I finally had a chance to sit down and play around with CityEngine again. Being a big sports fan (rugby in particular) I thought it would be a cool to find a way to use CityEngine to display sport stats in a new way.

The Rugby Championship is rugby championship with four participating countries: South Africa, New Zealand, Australia and Argentina. Each team play two matches against all opponents home and away, resulting in 12 championship fixtures.

I decided to create a CityEngine web scene for each fixture. The web scenes shows an aerial image export (from ArcGIS.com basemap), a 3D model of the stadium (from Trimble’s 3D warehouse) and a polygon drawn manually in CityEngine which will be used to visually display the stats of the game by assigning a CGA rule.

The Rule

Step 1:

Creating attributes

The first step of the rule was to create attributes for the Home Team, Away Team and the Stats to Display (1^st half, 2^nd half, and Full Time). These attributes are used in later parts of the rule to add the team logo, as well as for the stats.

Step 2:

More attributes

The next set of attributes represents the actual statistics of the match. The stats were obtained from Rugby Stats - www.rugbystats.com.au

The attributes below represents percentage time in opponent’s half, percentage time in Own half and percentage possession for the First Half, Second Half and Full Time.

More attributes...

Step 3:
Display stats

The CGA rule starts by reading the Home team, Away team and which statistic type to display from the attributes. Next the rule splits the polygon horizontally into 2 parts according to the territorial attributes, as seen in the image below as the Split rule.

The Split rule (to show territory)

More territorial advantage = Greater area of the polygon

Each block is then extruded according to the percentage possession of the ball. 

Higher % possession = Higher block 

Finally, add a 3D model of each stadium as obtained from Trimble's 3D warehouse and its done! This is a simple example of how CityEngine can be very versatile. It is a quick rule, set up once, which I then used multiple times (10 so far). And it is really not difficult.

Have a look at the links below to view the web scenes:

Australia vs New Zealand - 16 August
South Africa vs Argentina - 16 August
New Zealand vs Australia - 23 August
Argentina vs South Africa - 23 August
New Zealand vs Argentina - 06 September
Australia vs South Africa - 06 September
New Zealand vs South Africa - 13 September
Australia vs Argentina - 13 September
South Africa vs Australia - 27 September *
Argentina vs New Zealand - 27 September


Congratulations to the All Blacks that clinched the title last weekend. As well as to the Springboks for taking sweet revenge on the Aussies. I will upload the final 2 web scenes after this coming weekend's games.

*This scene does not have a 3D Model of the stadium    (because I couldn't find one of Newlands in Cape Town)

Levels of Detail - Building Interiors

I've been focusing on CityEngine CGA rules for building interiors lately. The aim was to create a rule file (or set of rule files) to create a generic layout of a building from 2D shapes at various levels of detail (LOD).

The image below shows various levels of detail of the same shape.

The levels are:

Level 0: The first image (although not actually a LOD) shows a plain 2D shape in its original form.

Level 1: This is simply an extrusion of the building footprint. As the shape does not have any height values associated with it (in this example), the rule file chooses a random height value.

Level 2: This LOD takes the extruded block from Level 1 and divides it into a roof (which creates a simple roof ledge) and sides (which are split horizontally into floors as well as vertically into windows and ledges). An attribute called floor_height is created and implemented by the rule file to split the sides into equal floors.

Level 3: The 3rd LOD creates a detailed 2D layout of each floor. Although in this example the floors are all identical, I plan to extend the rule by creating layouts floor based on floor number (for example creating commercial layouts for ground floors; office spaces for the three following floors and create a residential layout for the remaining floors. For this example all the floors are allocated as office spaces. Each room is color-coded according to the specified use: Blue - Office ; Yellow - Hallway : Red - Conference Room ; and Green - Printer Room.

LOD 3

Level 4: The final level of detail extends the previous levels by displaying a much higher level of building floor utilization. The focus of this LOD is to place, rotate and align building furniture (mostly Collada features obtained from SketchUp 3D warehouse) on the various floors. This LOD also creates stairs which links floors vertically.*

Conference Room

Stairs

Offices

The various LODs were created by selecting the appropriate Level from a rule attributed named LOD. This is what the attribute looks like in the code, as well as the Inspector window:

LOD attribute

This scene is a great example of how CityEngine provides the ability use attributes (and when there is none...create attributes) to dynamically assign various scenarios to the same 2D data and generating 3D geometries.

Explore the scene here.

P.s. If you are bored of the usual office life you can always replace the humans with cyborgs...

*I might have a look at displaying elevators next ;)

The light at the end of the Tunnel

A very important aspect of urban design is the ability to model underground infrastructure. Most of this blog's posts are about CityEngine's ability to model urban infrastructure above ground level, however this post will have a closer look at different ways of modeling infrastructure, depending on the position above (or below) the earth's surface.

View from inside the tunnel

Large amounts of urban infrastructure is located underground. These range from electrical-, water-, and waste management elements. The focus of this post will look at how transport networks (railways) can be located above as well as below the ground.

The first step is to determine what the study area's surface looks like. This can be done by adding a heightmap (.tif) image as a terrain layer.

10 m terrain image

After your data infrastructure data is added to the scene, select the features and go to Graph > Align Graph to Terrain > Select the Height map (your terrain) and click on finish.

Now that the data is aligned to the surface of the earth, we can do a simple check, to see whether the data is located underneath or above the surface.

The rule developed in this post was similar to the Redland Redevelopment Rail Guideway rule, which can be downloaded here.

By inserting a small piece of code to the existing CGA rule, we can check if the features are located above or below the terrain and model it appropriately.

heightOverTerrain = convert(y,scope,world,pos,scope.sx,scope.sy,scope.sz)-elevation

@StartRule
Platform--> case heightOverTerrain > 0:
 Divide_Platform
else:  TunnelSplit

TunnelSplit--> comp(f) {top: Tunnel}

Tunnel--> i("Tunnel.dae") s(scope.sx + 5, scope.sy+5, 10)center(xy) Yellow

The code above does the following:

• Creates a heightOverTerrain function which takes the z-value of the geometry and subtracts the terrain value to determine the height above the terrain. If the value is less than 1, feature is below the surface. You can read more about the convert function at the CityEngine Online Help. 
• Platform --> is inserted as the StartRule. The rule calls the heightOverTerrain function to check if the feature is located below or above the surface. 
• In case the heightOverTerrain value is > 0, the Divide_Platform rule is called, which in turn creates railway and trains along the top part of the surface, and pillars on the bottom part of the graph shape.
  
•  In case heightOverTerrain < 0 (which means the feature is below the surface), the Tunnel_Split rule is called. This rule assigns and scales a Tunnel.dae asset to the top part of the shape and colors it Yellow.
  

By inserting this small piece of code at the @StartRule of the CGA, CityEngine dynamically checks whether to build underground tunnels or above ground railways every time that the shape is edited, depending on the location of the feature regarding the terrain.

You can view the web scene here.