Designed to draw people, The Arena in Diriyah posed a bold architectural challenge: To create a technologically advanced, globally iconic venue that remains deeply rooted in local heritage, geology, and culture. HKS responded with a striking building envelope composed of stone-like monoliths that echo both in the rugged rock formations of the region and the timeless architecture of Najdi forts and palaces.
To bring the organic vision to life, the Arena’s envelope features 23 uniquely faceted “monoliths,” clad in over 21,000 custom GRC (Glassfibre Reinforced Concrete) panels. These panels span more than 200 distinct planar faces, creating a dynamic interplay of light, texture, and form.
The objective was to achieve perceptible yet organic gradation across the facade, with panel characteristics subtly shifting based on their vertical height and proximity to monolith edges. The final enclosure design has a panel count of eight—each with its own unique layout and texture—allowing for a modular yet expressive facade that merges modern functions with cultural identity.
Achieving this level of complexity and cohesion required a highly coordinated digital workflow, developed for constructability at scale. The process unfolded through four key stages:
- Data Structuring for At-Scale Documentation
- Parametric Panelization and Pattern Nesting for Cladding
- Maximizing Visual Differentiation Thorough Limited Modularity
- Interoperability Across Platforms
1. Data Structuring for At-Scale Documentation
Panelization workflow typically requires a solid data structure, especially when managing thousands of facade elements. For The Arena in Diriyah, we developed a hierarchical system that organizes information from macro to micro, enabling precise control and traceability across design and documentation stages.
The structure starts at the highest level with the exterior monoliths, followed by each face, the row and panel numbers. This layered identification strategy is essential not only for design coordination but also for integration into Revit and downstream documentation.
Each panel is assigned a unique ID in the following format:
{ A ; B ; C ; D ; E }
A – Monolith ID (e.g. Exterior Monoliths – 2000)
B – Monolith Number
C – Face Number
D – Row Number
E – Panel Number
2.Parametric Panelization and Pattern Nesting for Cladding
Creating a coherent and constructible panel system across 23 uniquely faceted monoliths required a rigorously structured and adaptable parametric process. This stage began with surface preparation and extended to nesting data. Aiming to ensure accuracy and efficiency from early design through fabrication.
2.1 Surface Preparation and Validation
As surface geometries are received from the design team, the initial step was to validate geometry and data’s consistency. The validation process is as follows:
- Reviewing Rhino Organizational Layer Structure
- Ensuring UV alignments of surfaces are consistent to the world XY axis
- Optional trimming of surfaces based on relative distance parameters
- Safeguard scripts to preserve face IDs
These checks were aimed at maintaining a clean data environment and ensuring the downstream processes could proceed without interruption.
2.2 Monolith Panelization Process
Once geometry is validated, surfaces underwent a parametric tessellation process tailored to create continuous horizontal alignment “patterns per monolith” . The latest iteration of the workflow included:
- Identifying key faces for pattern alignment through point tracking
- Categorizing faces based on their orientation—angled vs. vertical
- Unrolling joined (merged) monolith surfaces into 2D
- Each monolith’s surfaces are tessellated with an equilateral organized grid to establish the primary layout for panel placement and indexing
- Retrieving and assigning data from design to merged trimmed panels
Data input for this process was:
- Merged Monolith Surfaces: Input data for initial panel generation for “per monolith” pattern approach
- Received Design Monolith Surfaces: As this data structure was organized in validation stage, the structured data served as the layout for retrieving final face organization
- Opening (when applicable), were identified and integrated into the panel layout logic
As part of refinement, additional optimization steps were introduced to reduce the total number of unique faces, improve fabrication efficiency, and compare design alternatives for best performance.
3.Maximizing Visual Differentiation Thorough Limited Modularity
One of the core design challenges for The Arena in Diriyah was to achieve rich visual diversity across the facade without introducing excessive complexity in fabrication. The solution lay in smart modular thinking; maximizing perceived variation while limiting the number of unique panel types.
3.1 Panel Subdivision: Formliner Insert Types
The panel subdivision strategy started with an equilateral triangle. The base geometry was rationalized to generate a hierarchy of extrusions—varying in depth and size.
Panel types we defined adjusting the subdivision options to create a language of subtle differentiation also integrating LED Panels and punched opening
and textures:
3.2 Populating Panelized Surfaces with panel types
The established tessellation served as the primary layout for populating the panels, across monolith massing. Each full panel (seen below in green) was assigned a panel type with a specific configuration.
A series of weighting functions were developed to drive gradation indices specific to each panel location within each monolith’s face:
Last steps of the mapping included, randomly assigned attributes such as panel orientation and rotation to further reduce visual repetition. This additional layer of variation aimed to make it difficult to detect repeating panel types, contributing to the appearance of natural flow.
4. Interoperability Across Platforms
With panel mapping logic established, the next step was to deploy the panel elements within the Revit Environment. Rhino.Inside.Revit enabled the revit-native element creation, through three deployment strategies. The common objective throughout these strategies were maintaining parameter responsiveness to Revit panel schedules, ensuring that metadata remained filterable downstream.
4.1 Panel formation in Revit: Full Panels
The first step involved creating the eight GRC panel types as Revit families, each established necessary parameters. With Rhino.Inside’s “Add Component (Work Plane)” function, panel instances were populated in the Revit model based on:
- World XYZ location (translated from Rhino)
- The assigned panel type, (referenced from placed revit family)
- Work plane definition, which included the randomized rotation data
Once placed, parameter values were assigned to each panel instance. These included key identifiers such as Panel ID, Monolith Number, Face Number, Row, and Panel width – allowing the Revit model to maintain alignment with the project’s broader data structure.
4.2 Panel Formation in Revit: Trimmed Panels
While most panel placements followed the standardized full panel workflow, trimmed panels required a more flexible strategy. These panels were categorized and deployed based on their vertex count, with a different solution tailored for infrequent number of vertices.
4.2.1 Trimmed Panels (Adaptive)
The revit “adaptive component” were created for panels with 3 to 8 the vertex count. These families were designed with the same parameter structure . The families were added to the exterior revit model and retrieved through use of rhino.inside to be placed to their specific locations within the model.
4.2.2 Trimmed Panels (Irregular)
This category mainly consisted of trimmed panels intersecting with curved interior elements. With up to 60+ vertices, these were translated into individual specialty equipment families within Rhino.Inside and were added to revit exterior project model.
Later were called with Rhino.Inside interface to be positioned at their specific 3d locations.
Bonus : Lessons learned & Additional Scripts
- Automating Document Tagging
As the project evolved and updates were made to the envelope, the documentation tags and references were often lost or disconnected. Rather than reapplying tags manually close to deadlines, we implemented a tag retrieval and re-placement script, ensuring consistency and saving time during critical delivery phases. - Safeguarding Monolith Face Numbers Across Design Iterations
Throughout the project, the design team introduced new monolith faces or altered existing face’s locations. To maintain a consistent reference system, a realignment script was developed. This ensured that all subsequent versions’ of the data structure remained closely aligned with the initial schematic design documentation – streamlining coordination with fabricators and contractors throughout the project lifecycle. - Strategy for Scope Extension
As a part on site development, additional masses were added to the list of components to be panelized. Thanks to the initial data structure’s flexibility, these additions were integrated without disrupting the existing system.
While the resulting cladding system is notably simple, the visual objective and appearance of complexity necessitated a robust workflow for iterative optioning, visualization and constructability evaluations. Evolving masterplan of the arena and localized geometry fluctuations highlighted a need for structured, persistent scalable data protocols.
The methodology for The Arena in Diriyah offers a case study on how constrained modular systems can deliver visually rich, scalable, and buildable architectural envelopes—even in projects with non-standard geometries and high documentation demands.