CUBIZEN: Global Mapper, CityEngine & Creative Tech

Part 1: Understanding "Compute First / Street Edges"

Since the theoretical explanation of First / Street Edges can feel a bit abstract, I will use CGA code to verify how they work in practice.

First, let's set up road segments and building footprints as shown below. For this setup, we will define the carriageway widths as 3m, 4m, 5m, and 6m respectively.

Currently, the First Edge (Index 0) for all these shapes is facing South by default.

[img 1 : Initial setup of roads and building footprints with default orientations]

Applying CGA Code for Visualization

Now, we will apply a rule file to these footprints. The following code extrudes the footprints by 3m and colors the face generated from the First Edge (index 0) Red, while making all other walls Green.

  Lot --> extrude(y, 3) Building
  Building --> comp(f) { front: Entrance | side: Wall | top: Wall }
  Entrance --> color(1,0,0) X.
  Wall --> color(0,1,0) X.
  

Don't worry too much about the specific syntax of the code for now; let's focus purely on the visual results.

[img 2 : 3D extrusion result showing all first edges facing south]

As expected, you can see that only the face corresponding to the First Edge has been colored red. This confirms that all buildings are currently oriented in the same direction, regardless of the road positions.

Practical Tip: Why First Edge Logic Matters

If you don't correctly set your First Edge, your facade rules (like shop windows or entrances) will face the backyard.

Running the "Compute First / Street Edges" Tool

Next, let's select the models where the rule is applied and execute Compute First / Street Edges from the Shape menu. As mentioned in the previous lecture, this tool re-indexes the edges so that the edge closest to a road becomes the First / Street Edge.

Learn how to automatically orient your building footprints in Esri CityEngine. This video demonstrates the "Compute First / Street Edges" tool, which re-aligns the primary edge (First Edge) of a shape to face the nearest road. This is a crucial step for ensuring that procedural facades, entrances, and setbacks are correctly positioned in your urban Digital Twin.

Following this rule, you can see that the positions of the red faces on the three buildings in the top row have changed to face their nearest roads. It is important to remember that this tool physically changes the location of the First Edge.

Selection Behavior: Single vs. Multiple Selection

There is another important detail to observe when comparing the result of performing this task on a single shape versus performing it on multiple shapes at once.

Discover how selection affects attribute calculation in Esri CityEngine. This video explains the behavior of the "Compute First / Street Edges" tool when multiple shapes are selected. Learn why some edges might return 'NaN' values for street width when adjacent selected shapes block the path to the nearest road, and how single-shape selection records data for all directions.

• Single Selection: When you perform the operation on only one shape, the widths of all carriageways in the direction of every edge are recorded.
• Multiple Selection: When performed on multiple shapes simultaneously, if another selected shape is blocking the path to a road, the carriageway width for that specific direction will not be recorded.

(However, if the size of the other selected shapes is smaller than the width range facing the edge, the data may still be recorded.)

I intended to keep this brief, but since this logic is crucial for CGA coding, I am providing this extra explanation.

Part 2: Advanced Data with "Compute Edge Attributes"

Practical Tip: Why Edge Attributes Matter

Edge attributes allow buildings to react differently depending on street context. This is essential for procedural zoning, facade variation, and frontage-based rule generation.

Procedural rules become significantly more powerful when each facade understands its relationship to surrounding streets.

While Compute First / Street Edges focuses on setting the "Front" based on the road and only extracts carriageway widths, Compute Edge Attributes allows you to retrieve more diverse information, including edge orientation, specific street categories, and total road widths.

By utilizing this information, you can create various conditional expressions to target specific edges. Imagine a zoning guideline that states:

"Building facades facing roads 15m or wider must have an entrance. Faces adjacent to pedestrian paths narrower than 3m must have a 3m setback. Buildings taller than 6m cannot be built if the road width is less than 9m."

All these conditions have one thing in common: they are based on the road. This is precisely when you should use Compute Edge Attributes.

[img 4 : The Compute Edge Attributes menu and conceptual diagram]

Understanding the Search Parameters

By comparing the items in the menu window with the conceptual diagram, you can understand how each setting works. (For more details, please refer to the CityEngine help documentation.)

• Adjacency Search Range: Defines how far to look for a road.
• Adjacency Search Angle: Defines the field of view for the search.
• Edge Indent: Offsets the search starting point to avoid precision errors.

Key Difference: Non-Selected Shape Interference

While Compute First / Street Edges excludes non-selected shapes from its calculation, Compute Edge Attributes applies the logic even to shapes that are not currently selected. This means unselected buildings can act as obstacles blocking the "view" of the road.

[img 5 : Comparison of results between the two compute tools]

Compute First/Street Edges vs Compute Edge Attributes

Practical Coding: Using Edge Attributes

Don't worry about memorizing everything. Just keep in mind that Compute Edge Attributes generates more attributes, allowing for more complex coding conditions. Let's see how to use it in practice.

Set up your road and footprints similar to the diagram below. You can refer to the grid size for approximate dimensions. Set the carriageway widths to 3m, 4m, and 6m, and set the sidewalks to 3m on both sides.

[img 6 : Practice setup with various road and sidewalk widths]

[img 7 : Applying Compute Edge Attributes]

Once set up, select the right-most shape and apply Compute Edge Attributes with default settings.

[img 8 : Checking attributes in the Inspector]

Defining Procedural Conditions

Now, we will create two specific conditions for our buildings:

1. Facades facing the "side" orientation will be colored Green.
2. Facades facing the "front" orientation with a total road width of 11m will be colored Red.

[img 9 : Visual mapping of orientations and attributes]

The Final CGA Rule

  Lot --> extrude(10) Mass # Extrude building by 10m
  Mass --> comp(f) { side: Side } # Disassemble facades
  Side --> 
  case edgeAttr.getString("orientations") == "front" && edgeAttr.getFloat("streetwidths") == 11 : 
        color(1,0,0) X. # Red for specific frontage
  case edgeAttr.getString("orientations") == "side" : 
        color(0,1,0) X. # Green for sides
  else : 
        X.

[img 10 : Final 3D result showing automated coloring based on street context]

The output matches our expectations! We have successfully targeted specific faces by assigning conditions and applied procedural rules based on their environmental context.

Practical Tip: Sidewalk vs. Carriageway

Beginners often confuse these two. Remember that "Street Width" in Compute Edge Attributes includes everything from curb to curb plus sidewalks. If you need to align your buildings to topography first, refer to [002-003] How to Create Terrain and Align 3D Buildings in Esri CityEngine.