The provision of adequate viewing standards in a stadium is a key factor in ensuring that seated accommodation is both safe and serves its intended purpose. Referencing the ‘Green Guide‘, which was produced by the Department for Culture, Media and Sport in the UK, this tutorial will explain how to use Dynamo to automate the seating bowl for a stadium.
Step 1: Pitch
The first step is to draw your playing field. Depending on the type of stadium you are designing, this might be purpose built, e.g. football only, or multi-purpose. I would recommend using a generic model family with model lines so that it will be visible in 3D. There is no need to parameterise the family as the pitch is unlikely to need to flex. The exception to this would be if the pitch was to be multi-purpose, in which case it is best to create separate generic model families for each type, and the nest these into a parent family and use the visibility parameter for graphic control.
Step 2: Point of focus
The next step is to define the point of focus. The term ‘focal point’ is a bit of a misnomer as it is not actually a point, but rather an imaginary line delineating the extent of the sightline. The location of the point of focus will vary depending on the sport. Football for example may be aligned with the nearest touchline but have filleted corners. Rugby on the other hand may allow the point of focus to be within the try zone. Obviously, the more of the pitch you can see the better.
NRL pitch with dashed point of focus
For illustrating the point of focus, we simply need to use mode lines (shown dashed above). It is important to remember that lines have a direction which will impact how they are offset. Best practice is to ensure the lines are drawn in a clockwise direction, although the Dynamo nodes shown later will ensure all curves are in the same direction.
Step 3: Sightlines
The term sightline refers to the ability of a spectator to see a predetermined focal point over the top of the heads of the spectators immediately in front. The better the quality of the sightline, the more likely it is that spectators will remain seated during the event. Ensuring adequate sightlines is therefore an important part of providing safe seated accommodation. The quality of a sightline is often expressed as a ‘C-Value’. The recommended C-Value for spectators varies according to the sport. The C-Values can be described as shown on the table below:
Need to look between heads in front
Can see well with head tilted backwards
Optimal viewing standard
Can see well even if over spectators with hats
C-Value diagram from the Green Guide, p.109
As shown in the diagram above, Section 12.3 (p.109) of the Green Guide demonstrates how the C-Value can be calculated using the formula: C = ((D(N+R))/(D+T)) – R. However, typically we will have a predefined C-Value and will want to calculate the resulting riser heights (N), which will be different from row to row. To get N, we can use algebra:
C = ((D(N+R))/(D+T)) – R
R+C = (D(N+R))/D+T
((R+C) x (D+T))/D = N+R
(((R+C)*(D+T))/D)-R = N
Since we need to know the previous N value in order to calculate the next N value, we need to use recursion. Recursion is a computational process which requires a series of operations to be continually performed until a stopping condition is met. In Dynamo, this is best achieved using a simple Python script:
#Load required modules
from Autodesk.DesignScript.Geometry import *
#coverts to integer if text or number
numRisers = int(IN)
# Seating step width
T = IN
#Initial N value (starting height)
N = IN
C = IN
#Point of focus
D = IN
#sets counter to zero
Rprev = 0
#container for output
rList = 
#create list of N distances (riser heights)
for i in range(numRisers):
Rcur = N + Rprev
N = (((Rcur+C)*(D+T))/D)-Rcur
D = D+T
Rprev = Rcur
#Assign your output to the OUT variable.
OUT = rList
To save you the trouble of writing this, you can use the ‘Stadium.Cvalue’ node from the BVN Dynamo package. The custom node defines the constants including: Seating row depth (T); Eye offset from rear of row (A); Focus distance (F); Number or risers; Initial N value, C Value; and, Eye height (E).
Dynamo script, Step 3
The ‘frontDownturn’ input is typically the same as the initial N value (N) unless you are doing multiple tiers (refer Step 5). The Eye offset at rear of row (A) has a default value of 150mm, while Eye height (E) has a default value of 1200mm. Both of these are considered industry standard dimensions. Focal distance (F) was defined in Step 2 and relates to the sport/pitch. As you can see, the vertical height to the point of focus (R) is not explicitly defined. This is because the initial value of R can be calculated as:
R = initial N value (N) + eye height (E)
Similarly, the horizontal distance from the eye to the point of focus (D) is not explicitly defined. This is because the initial value of D can be calculated as:
D = Seating step width (T) – eye offset from rear of row (A) + focus distance (F)
Diagram showing manual calculation of a C-Value of 70
Seating row depth (T) relates to what the Green Guide terms a ‘clearway’ (refer Section 12.14, p.118). The clearway is the distance between the foremost projection of one seat and the back of the seat in front of it. The size of the clearway determines how safely and freely spectators and other personnel can move along rows of seats. The minimum clearway should be 400mm. It is therefore recommended that the seating row depth (T) should be at least 800mm, although 850mm is more common. (Note the key to diagram below is different to the C-Value diagram above.)
Seat and seating row dimension diagram from the Green Guide, p.118
The ‘Stadium.Cvalue’ node will output several values: the Z-coordinates of the top of the riser; the Z-coordinates of the bottom of the riser; the Z-coordinate of the eye (R); riser heights (N); and, row offsets (D). These values can then be used to generate the seating bowl profile in the next step.
Step 4: Seating bowl profile
Generally speaking, a seating bowl can be generated as a sweep using a profile and path. Typically, but not always, the path will be the line of focus in order to ensure consistent C-Values. The sweep path (line of focus) can be manually drawn as described in Step 2. The sweep profile on the other hand can be automated now that we have the values from Step 3. There are multiple methods we can use to generate the profile curve:
- Option 1 – Revit Project Environment. In this scenario we can use the ‘Stadium.ModelCurve’ node from the BVN package to create the sweep profile directly within the Revit project environment. This will create a polycurve in the XZ plane which will act as the sweep profile. Note, it is assumed that the stadium is centred around the Project Base Point. If not, you’ll have to amend the script so that the sweep profile is translated into the correct position. Also, due to how Revit generates sweeps, it is unlikely that the sweep will work on a rectangular path. The path should have fillets or chamfers, which is actually more realistic, for Revit to generate the sweep. Once the sweep profile is created, we then have two main options for generating the sweep:
Option 1A – Direct shape with Dynamo. Using Dynamo, we can sweep the profile around the line of focus. Using the resultant solid we can then generate either a direct shape or import instance. However, the baked geometry will have limited capacity to be modified outside of Dynamo. Furthermore, if you use Dynamo’s OOTB ‘DirectShape.ByGeometry’ node, the geometry will be tessellated which will cause unnecessary visual complexity.
Dynamo script, Step 4, Option 1A
Seating bowl generated by direct shape
Note that if you didn’t define the materials of the direct shape in Dynamo, you’ll need to modify the ‘Dynamo’ material properties. To do this, go Manage > Settings > Materials.
Material modification for direct shape
While this method can be considered the most parametric in terms of pure Dynamo workflow in the sense that the results can be seen immediately within the Revit project, the end result is a less user friendly Revit element. In order to allow the greatest versatility and flexibility, this method is best avoided.
Option 1B – Manually create an in-place mass. We can use Dynamo to generate model lines for the profile curve and then manually create an in-place mass. To do this, go Architecture > Build > Component > Model In-place, and set family category to ‘Floors’. Then use the ‘pick lines’ command to define the profile. The creation of the in-place mass needs to be done manually due to a well-known limitation of the Revit API.
Dynamo script, Step 4, Option 1B
While the profile of the sweep can be locked to the model lines coming out of Dynamo, if extra rows are added for example, the sweep will not be automatically updated to include the additional rows. However, the benefit of this workflow over Option 1A, is that the sweep will be ‘clean’ without any tessellations or triangulations. Furthermore, it allows for easy manual modifications outside of Dynamo.
Seating bowl generated by in-place mass
If preferred, both Options 1A and 1B can be generated within a generic model family (but not a profile family). However, you will come across similar limitations as mentioned above.
- Option 2 – Revit Family Environment. In this scenario, we can use the ‘Stadium.ProfileCurve’ node from the BVN package to create the sweep profile within a 2D profile family. First, create a new Family file by going File > New > Family > Metric Profile. Ensure that Dynamo is pointing to the new family file and not a Revit project. The script below will create detail lines in the XY plane of the profile family. Any manual modification can then be made as required, before loading the profile family into the Revit project.
Dynamo script, Step 4, Option 2
2D Profile generated within profile family
Once the profile family has been loaded into the project, an in-place mass can then be created via a sweep. To do this, go Architecture > Build > Component > Model In-place, and set the family category to ‘Floors’. If the seating bowl profile needs to be updated in the future, simply re-run the Dynamo script in the profile family and reload (and overwrite) the family into the project. The sweep will then be automatically updated.
Seating bowl generated by in-place mass
While this method is not necessarily the most parametric in the sense that you must go via the family first and then the project, it does afford the greatest flexibility for non-Dynamo users once the element is created. For this reason, this is the preferred option.
Step 5 (optional): Concourses & Multiple tiers
Stadiums will typically have multiple tiers separated by a concourse. A concourse is defined as a circulation area that provides direct access to and from viewing accommodation to which it may be linked by vomitories, passageways, stairs or ramps. It serves as a milling area for spectators for access to refreshments, entertainment and toilets, and may also be part of the entry and exit routes.
To create multiple tiers, simple repeat Step 4 but with new values. For example, while many of the values may remain constant, such as C-Value and seating row depth (T), the new tier will have a different point of focus (D) and initial N value (N). Note that although shown combined in this example, it is recommended to produce separate profiles as described in Step 4, for versatility.
Dynamo script, Step 5
Multi-tiered profile generated within profile family
Step 6: Vomitories
Section 9.1 (p.75) of the Green Guide defines a vomitory as ‘an access route built into the gradient of a stand which directly links spectator accommodation to concourses, and/or routes for ingress, egress and emergency evacuation.’ Since the layout of vomitories will be different for each stadium, this step is best done manually. To create the vomitories, first edit the seating bowl sweep created in Step 4/5, then go Create > Forms > Void Forms > Void Extrusion, and draw the vomitories in plan. The extrusion should be sufficiently high to cut through the sweep. You can create one void element with multiple vomitories or multiple voids, one for each vomitory – the choice is up to you.
Seating bowl showing void extrusions
Seating bowl with vomitories
Step 7: Gangways
Next we need to add radial gangways to ensure spectators can travel from their seat to an exit. A radial gangway is defined as ‘a stepped or sloping channel for the circulation of spectators through viewing accommodation, running between terrace steps or seat rows’ (refer Section 8.2, p.66). The minimum width of a gangway should be 1200mm wide (refer Section 6.5, p.56 ) and all spectators should be within 12m of a gangway or exit, hence the maximum spacing of gangways 24m apart.
Continuous crush barrier configuration diagram from the Green Guide, p.99
However, often the gangway distribution will be dictated by the seat spacings. Since the maximum number of seats per row is 28 seats (refer Section 12.16, p.119) and the minimum spaced allotted to each seat is 460mm (refer Section 12.13, p.116), this means the maximum gangway spacing is reduced to approximately 12.8m. Moreover, if the recommended 500mm seat spacing is used, the maximum gangway spacing is approximately 13.9m. In any case, the gangway spacings will usually be significantly less than the maximum 24m.
Seat and gangway spacing diagram
Gangways are best modelled as a single mass with multiple extrusions. To create these, go Architecture > Build > Component > Model In-place mass > Mass. Include any vomitories as essentially we are creating a void within the seating bowl where we don’t want seats. This mass will be used in the next step to create the seating line work.
Step 8: Seating row linework
Next we need to extract the row curves of the seating bowl in preparation for the seat placement. One way of achieving this is to extract the edges from the seating bowl that we created in Step 4/5. However, this is an unnecessarily complex process as a series of sorting procedures would need to be undertaken to order the curves in a logical matter. Since we know the line of focus as well as the row offsets and Z-coordinates from Step 3, we can simply recreate the base linework. This will give us a clean, structured list which will be easier to work with.
Seat spacing set-out from front of seat line
When placing seats in a radial configuration, care needs to be taken in setting-out in order to prevent seats from overlapping. To achieve the desired spacing, we actually need to determine the front of the seat line. The ‘Stadium.CreateRows’ custom node in the BVN package solves this though the ‘SeatDepth’ input. Essentially, the node offsets the back of row curve based on the seat depth input. The node then splits these curves with the gangway masses created in the previous step in preparation for the placement of the seats and gangway step generation.
Dynamo script, Step 8
Step 9: Gangway steps
Using the curves from the previous step and the riser heights from Step 3, we can create the gangway steps. The number of steps will vary depending on the row riser height. Section 12.11 (p.115) of the Green Guide states that:
- The goings of steps in radial gangways should not be less than 280mm, and should be uniform.
- The risers of steps in radial gangways should not be more than 190mm, and should also be uniform.
A conditional statement is therefore required which states that if the going between rows is greater than the maximum step riser (190mm), then a step is required. Next, calculate the riser height of the step and determine if it is greater than the maximum (190mm). Repeat this process until the riser heights are below the maximum. To simplify this process, use the ‘Stadium.GangwayStep’ node from the BVN package. The node will create uniform steps where the gangway voids existed (refer Step 7) which is then automatically cut by the vomitory voids (refer Step 6). In order to be able to select the vomitory void form for the ‘select model element’ input, you’ll need to edit the seating bowl sweep so that the void form is available.
Dynamo script, Step 9
Gangway steps as direct shapes
Step 10: Place seats
The final step in creating our seating bowl is to place the seats following certain criteria: Justified to the edge of the gangways; equally spaced between gangways; and, perpendicular to the row. Before we place any seats we need to first ensure our seat family is correct. When placing a family in Dynamo, Revit will use the insertion point as defined by the ‘Defines Origin’ parameter within the family. The example below shows how the reference planes have been modified and renamed so that the centre (front/back) and centre (left/right) align with the front of the seat.
Seat family showing origin at front of seat
When rotating a family using Dynamo, Revit will use the local Z-axis regardless of where you have defined the origin. To check that the rotation point is the same as the insertion point, create a point at 0,0,0 in the family using the ‘Point.ByCoordinates’ node and ensure that the Revit background preview is enabled. Alternatively, you can load the family into the project and check the rotation there using a simple script:
Dynamo script to check seat rotation in Revit
Once you are happy with your seat family, ensure it is loaded into the project. To place the seats we can use the front of seat polycurve generated in Step 8 and the ‘Stadium.PlaceSeats’ node from the BVN package. The polycurves already accommodates any gangways or vomitories so there is no need to do any further modification to the base geometry apart from removing the last row.
Dynamo script, Step 10
The node calculates the start and end point of our seating array. If we were to simply use the start and end point of the polycurve, we would have seats encroaching into the gangways which is unacceptable. We therefore need to ascertain the seat width and trim the polycurve by half of the seat width at either end. This will ensure that seats are justified to the gangways.
Next the node divides the shortened polycurve by chord length (as opposed to along the polycurve) using the minimum seat spacing. This returns a preliminary result as it will generally be a number (float) rather than an integer. Since we can’t have part of a seat, the node uses the ‘Floor’ node to round down the number to the nearest whole number. Knowing how many whole seats will fit, the node then divides the shortened polycurve with the new integer value. The resultant points on the curve are the insertion point for our seat family which corresponds to the front of the seat. Note that the number of seats per row between gangways is going to differ. This is most evident in the corners of the stadium where there is radial geometry.
Since it is not possible to place a family instance with the correct rotation in one step, the node first places the seats using the ‘FamilyInstance.ByPoint’ node before setting their rotation. The seats need to be rotated so that they are perpendicular to the normal along the rows. To calculate this, the node uses the insertion points of the seat family and the polycurves to generate the parameters along the curve using the ‘Curve.ParameterAtPoint’ node. With these values, normals are then returned using the ‘Curve.NormalAtParameter’ node. Next we need to calculate the difference between the orientation of the seat family and the normal vector. Prior to Dynamo 0.8.2 this was impossible using OOTB nodes. However, Dynamo now has the ‘Vector.AngleAboutAxis’ node. Since in this example the seat has been modelled facing ‘down’, I need to compare the normal vector to the negative Y vector. The result of this calculation is the required seat rotation in degrees from 0 to 360. The seats are then rotated to the correct orientation using the ‘FamilyInstances.SetRotation’ node. The ‘Stadium.PlaceSeats’ node will also output the total number of seats and the number of seats per row so that you can ensure all brief and regulatory requirements are met.
While this tutorial demonstrated that it is possible to parametrically create a seating bowl using Dynamo, it highlighted the fine line between the desire to achieve full automation verse the usability of the output. In this scenario, a fully parametric definition would have been detrimental to the workflow due to the inability to manually edit direct shapes. Instead, an augmented workflow was advocated which afforded both manual intervention and more usable Revit geometry. Computational designers must be aware of such software limitations and ensure they customise their workflow appropriately so that the entire project team can engage with the model.
To see how Dynamo can be used to create an entire stadium, check out this post.
Building Information Modelling, or BIM, is often portrayed as the saviour of the Architecture, Engineering and Construction (AEC) industry. On the whole, BIM can be seen as a positive direction for the industry, attempting to address the inefficiencies and waste in the industry. Yet at the same time, numerous fractions of the BIM movement are threatening to hinder its cause.
Go into any architectural office in the world today and you’ll find someone ‘doing BIM’. Typically with a technical background, they are known as evangelists, preaching the word of BIM. Listen to them closely and you’ll discover common threads in their arguments – All projects should use BIM; People in my office don’t understand BIM; BIM should be mandated by governments; and, Software X is better than software Y. While I have no doubt that many of these people’s hearts are in the right place, I can’t help but think we are approaching the problem of BIM adoption all wrong. Let’s dissect each issue first, before discussing a different way to look at things.
Issue 1: All projects should use BIM
BIM is touted as being more effective at coordination, communication and collaboration. Chances are, it probably is. However, this doesn’t mean BIM should be imposed onto every project from day dot. Its implementation into the project needs to be carefully timed and curated.
Despite what software vendors may claim, BIM is slow compared to CAD. This shouldn’t come as a surprise. Technology was supposed to save us time and make our lives easier. We can confidently say neither of these things have happened. Many technological innovations, from email to instant messengers to productivity apps, promise to make our lives faster, easier and more efficient. Yet we are as busy as ever.
Sure, if you are designing conventional buildings with repeatable elements, BIM will mostly likely save you time. But most architects design custom buildings that a one-offs. Even if an architect specialises in a single typology, say housing, chances are each house will be substantially different from the next. And herein lies the problem. Since no two projects are ever the same, it is not possible to simply ‘arrive’ at an architectural outcome. Each brief will be different, each site different and each budget different. An architect is obliged to go through the schematic design process or they would be doing a disservice to their client. Keeping in mind that the design process is an iterative process of ideation, testing, and refining.
Traditional linear thinking vs Feedback Loop, Randy Deutch 2017 1
During the design exploration process, BIM can actually be a hindrance rather than a benefit. There are other design methodologies which are more fluid, agile and informative, and therefore better equipped to undertake the design exploration process. Many of these process which we’ll discuss later, do not fall into the traditional definition of BIM and are therefore often considered second-class citizens in the eyes of BIM evangelists. This prejudice is mainly premised on the argument of interoperability – If the project is going to move into BIM anyway, why not just start the project in BIM from the beginning? At face value this seems like a logical argument but it couldn’t be further from the truth.
The AEC industry needs to learn from the software industry. Rather than embarking of months and months of development using ‘text book’ methodologies, software developers create quick proof-of-concepts to test viability. Known as ‘sprints’, they are focused developments of the project which tries something, gets fast feedback, and then rapidly inspects and adapts.2
Sprint Cycle, Nate Miller, Proving Ground 3
Yet in architecture, there are many BIM managers who want to mandate BIM from day dot. Staff are given Revit templates with countless filters, view templates and office standards to follow. The logic behind this is that of doing it once and doing it right. But this is misguided. Designs are going to change. And not in an incremental, progressive way. They are going to change radically. Why? Because buildings are complex and the problem solving needs to be broken down into manageable chunks, starting with the macro and working to the micro. BIM, which relies on progressive refinement, is therefore at odds with this design methodology.
Like it or not, many architectural commissions are derived from architectural competitions. Whether prescribed by fair competition laws, governmental requirements, or clients simply seeking ideas, architects are required to produce resolved designs in a relatively short period of time. Design competitions as a method of ideation is a contentious issue and its appropriateness is beyond the scope of this article. However, what is certain, is that the probability of winning a competition is low. Even the most successful practices only have a success rate of say one in four. Given the volatility of the design process and the low probability of gaining the commission, should BIM be adopted at the beginning of a design competition? Personally, I don’t have a problem with this except for one caveat – Don’t be surprised if the quality of the BIM model is not what you expect. If you win, fantastic. But due to the tight timeframe and the continuous design changes, the BIM model is probably so poorly constructed that most BIM managers will insist on rebuilding it from scratch.
Tool vs Toolbox, Chris Mackey 4
Wouldn’t it be better to use the best tool for the job, settle on a design trajectory and then embark on your BIM journey? Rather than resenting this as an inefficient design process, BIM managers must embrace a BIM ecosystem. If all you have is a hammer, everything is going to look like a nail.5 But actually what we really need is a screwdriver, or better yet, a whole toolbox. Trying to control the design exploration process is futile. As Randy Deutch points out, “Architecture is a complex undertaking requiring the input of many individuals with varying interests, backgrounds, and expertise. This has not changed – and will not change. What is changing is the way these individuals are working, communicating, and collaborating.”6 Architects and BIM Managers must be flexible in BIM deployment and adopt interoperability as a process in order to ensure continuity of design intelligence. The principle here is simple – Don’t force BIM on a project until it is ready.
Issue 2: People in my office don’t understand BIM
One only needs to look at the high staff turnover in the design technology field to see that the industry has a problem when it comes to understanding BIM. Time and time again, I see talented and motivated staff become demotivated and disillusioned with the way design technology is being adopted in their office. With the shared belief in technology as an enabler of good design, they come across barrier after barrier to digital nirvana. It might be that there is no BIM deliverable in the contract. Or it might be that senior staff members only see them as a BIM monkey, someone who simply models what they have designed. Or it might be that they were hired as a BIM manager when actually they are doing a Model Managers role. Or it might be that is doesn’t matter how hard they beat the BIM drum, people simply don’t want to change from their old ways of working. Whatever the barrier, the end result is the same – high turnover of design technology staff, which is turn fuels the demand for design technology staff.
“If you want to gather honey, don’t kick over the beehive”
Over time, the continual repetition of this process leads to a breakdown in trust between management and design technology leaders. Both parties feel they are not being listened to, which furthers resentment and marginalises the design technology professions into the problem child of architectural design. Design technology staff need to be clever if they are to have any hope in changing this dynamic and winning people to their way of thinking. After all, as Dale Carnegie eloquently sums up, “If you want to gather honey, don’t kick over the beehive.”7 must understand that whether you are a BIM Manager, Computational Designer, Chief Digital Officer, or any other digital design professional, the AEC industry is still coming to terms with this disruptive technology. Organisations have been slow or resistant to seeing these digital design roles in a position of leadership. Becoming frustrated only furthers this perception and undermines the value that these professionals bring to the company.
Super User, Randy Deutch8
BIM evangelists like to stand on their soapbox and preach the benefits of BIM. The argument is generally that BIM is faster, more efficient and cheaper, which may be true. However, this line of argument is not necessarily the best way to educate architects on the benefits of BIM and champion its adoption. Quite simply, architects are not efficient beings. Much to the frustration of other AEC professions, architects continually change their mind and often refuse to commit to a design decision until the last possible moment. At least for the time being, I can’t see this working model changing. Ideas take time to emerge and one cannot predict when that will happen. One only needs to witness the design process during a design competition to understand this. Rightly or wrongly, architects are focused on the design outcome above anything else. BIM therefore needs to be presented in these terms in order to convince the other party of its value.
Rather than promoting BIM efficiency, it is far better to promote design quality. By demonstrating that BIM will deliver a better building, you will be more likely to influence change. Most presentations and articles on the benefit of BIM fails to acknowledge this. Again rightly or wrongly, due to the adversarial nature of the construction industry, most architects are not interested in making the contractor’s role easier by providing a fully detailed LOD 500 BIM model. If however, you can demonstrate that the quality of space is significantly improved due to improved sunlight access or minimised overshadowing, than you are beginning to speak in their language. Rather than emphasising differences in methodology, find common ground in your shared aim to create better buildings. There are many faces to BIM and we must understand our audience if we are to convince them.
Another common barrier which causes much frustration is the level of detail in the BIM model. Many architects use BIM simply for design authoring even if they have no intention of using the model for any higher purpose such as Facility Management (FM). Again, time and time again, I see over-zealous BIM managers embedding enormous amounts of detail into the BIM model. This seems more like an exercise of doing it because it can be done, rather than what the project requires. This takes us back to an earlier point on the role of technology in the profession. BIM is not necessarily saving us time, but it is making us more productive. But here is the catch – that additional productivity is only beneficial in a commercial sense if you are being paid for it.
A BIM manager will typically only get involved in a project long after the Client-Architect Agreement has been executed. This means that many of the project deliverables are already defined before the BIM model is even commenced. While it might be satisfying to build a fully parametric, fabrication level Revit family, BIM managers need to show restraint and business acumen. The rational seems to be that by demonstrating what BIM can do, one will be more likely to influence the scope of work for the next project. However, being over-zealous and covertly taking things into your own hands only further divides design technology professions from project directors and managers. Seek to understand the commercial realities of projects and see things from the other person’s point of view.
Architects are interested in buildings. They are not necessarily interested in BIM models. For many, BIM is a means to an end in getting the building built. How often do you hear architectural journals talking about the quality of the BIM model for an award winning design? Never. It is the final built work, the resolution of many competing interests, that ultimately counts. This must be keep in the back of the mind at all times.
If a client or manager can’t be convinced of the benefits of producing a fully resolved BIM model, change tact and demonstrate how you can harness the power of the BIM model. Extract the data that you do have, this could be elementary information like room distribution, areas and functions. Synthesise this data longitudinally across multiple projects to unearth patterns in how your company designs buildings. For example: Are residential buildings orientated in a certain way to achieve solar access compliance?; What were the significant changes in the model and can these be visualised in a decision tree to understand how we design? These sorts of questions are selfishly internally focused but they begin to open up the discussion of the value of data without imposing it onto a project. Demonstrate usefulness without exceeding your scope of work and blowing your budget. And above all, see things from the other person’s point of view.
Issue 3: BIM should be mandated
Report after report10 has demonstrated the wastefulness within the AEC industry. Moreover, the AEC industry is notoriously slow at adopting new technologies. By mandating BIM, many seek common ground on which to collaborate and share BIM information. While this is an admirable endeavour, it opens up a whole can of worms which in my opinion is not positive for the BIM movement.
Before BIM, there was CAD. In fact, CAD is still around today. For decades, CAD managers debated and argued over standards including layer naming and line weight conventions. The aim was to achieve uniformity and consistency across the profession so that if someone shared a *dwg file, you could easily XREF it in, understand the layer system, and turn on/off layers as required to minimise re-work. Yet for all the discussion that took place, every architectural office seemed to adopt their own standard. It was a complete and utter failure. Not only could we not decide on graphic standards, we couldn’t decide on methodology. Some people preferred to have each floor plan of a building in a separate file. China and Europe seemed to prefer all floor plans in one file and use blocks for repetitive elements. Some annotated in ‘model’ space, others in ‘paper’ space. While we had standards, we were far from having standardisation.
The discussions around mandating BIM appear to be heading down the same familiar path, focusing on industry standards and protocols. For example, we have BS-1192 which aims to provide:
…a “best-practice” method for the development, organization and management of production information for the construction industry, using a disciplined process for collaboration and a specified naming policy. It provides the template for common naming conventions and approaches to collaborative working for use in architecture, engineering and construction. It also facilitates efficient data use in facilities management.12
Together with PAS 1192-2, which specifies the requirements for achieving BIM Level 2, we are inundated with endless workflow diagrams and definitions. On top of this we have Industry Foundation Class (IFC) and Construction Operations Building information exchange (COBie) as our common data platforms. Clearly these initiatives are a response to software not seamlessly and harmoniously working together within the BIM ecosystem. But is this really the best way forward?
The Harvard Business Review has written extensively about how tight controls strangles innovation.13 The inherent uncertainty of the innovation process makes side-tracks or unexpected turns inevitable. Even if standards are guidelines, over time, they often become enshrined through secondary legislation. NSW’s SEPP65 solar access requirements are a prime example of this. Let’s not resort to the lowest common dominator by adhering to strict protocols and instead focus on where we want to end up – the creation of better buildings, communities and the environment through architecture. For example, rather than trying to get consensus on the naming system of elements, why not create software which automates the process. With the release of Revit, there is now no longer a debate over layer naming conventions. If an element is a wall, it is categories as a wall. There is no need for a debate over what the layer should be called – ‘A-Wall’ or ‘A-WALL’. The software removed this from the equation. Why can’t this be done for file naming or element naming? Focusing on naming conventions is archaic and pointless. Newforma for examples offers advanced searching and indexing capabilities. It no longer matters if someone didn’t save the email attachment separately onto the office server or didn’t name the word document as per office standards. Yes it might look messy if you use Windows Explorer, but that is old technology and not the way of the future. Indeed, Autodesk’s Project Quantum, which is slated to be cloud-based and platform agnostic, will surely address these issues.
While loosening formal controls, BIM managers should tighten interpersonal connections between innovation efforts and the rest of the business. Undervaluing and underinvesting in the human side of innovation is a common mistake. Emphasising tasks over relationships creates missed opportunities to enhance the team chemistry necessary to turn undeveloped concepts into useful innovations. Next time, rather that set out all the standards and protocols that must be followed, throw down a challenge and ask the team, what is the best way we can design and procure this building? Not only will this motive the team but you may actually end up with a better building and a more cohesive team.
Issue 4: Software X is better than software Y
Both Revit and ArchiCAD are BIM authoring softwares. Yet rather than seeing this as a positive from self-proclaimed software evangelists, there are frequent quips that Revit is better than ArchiCAD (or vice versa). Similarly, there are often degrading comments made about the inferiority of Rhino as it isn’t considered proper BIM software. These types of statements are prolific, detrimental to the AEC industry and must stop. We must acknowledge that no software can do everything and that each has their limitations. Practices such as FRONT Inc, DesignToProduction, Proving Ground and AR-MA, have produce fabrication level models of incredibly complex designs using ‘non-BIM’ software. Does this undermine the outcome? Absolutely not, and in fact, such an outcome probably wasn’t even possible with conventional BIM authoring software.
A lot can be learnt from the soda industry and the so called soda wars. Coca-Cola and Pepsi have been long-time rivals. However more recently they have discovered that their biggest rival is not each other but tap water. Indeed, in 2010, Coca-Cola drew enormous public criticism for their ‘Cap the Tap’ program. In sum, it instructed restaurant employees on how to discourage patrons from drinking water, and then steer them toward revenue-generating beverages.14
Software evangelists need to stop seeing their competitor as rivals. To follow the same analogy, Autodesk’s biggest rival is not Bentley nor Nemetschek, but AEC professionals that don’t embrace technology at all. Despite this and to a huge social media backlash15, Autodesk recently decided to ban certain ‘competitor’ software from exhibiting at Autodesk University. One cannot help but see this as a disingenuous and hypocritical move, further siloing Autodesk from the greater BIM community. In stark contrast, the RTC conference, which is historically Revit centric, partnered with Archicon, an ArchiCAD event.16 The conference organisers recognised that the problems the industry are facing are bigger than just a single software platform. In even further recognition of this community attitude, this year they changed their name to ‘BILT’ to reflect the broader scope of topics and software.
We live in a BIM ecosystem – Criticising and complaining about other software only undermines our industry and does more harm than good. Rather than critiquing an approach based on the software used, we should be critiquing the output based on the methodology and the embedded design intelligence. It is far better to work towards a common goal than taking cheap shots at a competitor’s software preference. We must learn to stop prejudicing software – After all, it may have something to offer which yours can’t.
Bill Allen of EvolveLab recently gave a presentation at Autodesk University titled, ‘The future of BIM will not be BIM: And it is coming faster than you think’.18 In the presentation, Allen predicts that rather than BIM, we are going to see Building Information Optimisation. Not only will we see ubiquitous computational design, we will also see machine learning and artificial intelligence infiltrating architectural design. To many this may seem a distant reality. But technology is changing the profession at a much faster pace than people think.
Humans tend to think in terms they can relate to and we base our expectations on our experience. We live in linear time and space, yet technology is fundamentally different, growing exponentially.19 As Diamandis explains:
…if I were to take 30 linear steps, it would be one, two, three, four, five. After 30 linear steps I’d end up 30 paces or 30 meters away and all of us could pretty much point to where 30 paces away would be. But if I said to you take 30 exponential steps, one, two, four, eight, sixteen, thirty-two and said where would you end up? Very few people would say a billion meters away, which is twenty-six times around the planet. 20
While BIM may be the topic du jour, technology is changing fast – faster than we can comprehend. It is important that we put BIM in perspective and not lost sight of the big picture – how do we create better buildings, communities and the environment through architecture. After all, isn’t this why we got into the industry?
1 Deutsch, R. (2017). Convergence: The Redesign of Design. John Wiley & Sons Ltd, Chichester, p.28.
2 Miller, N. (2015). What Building Teams Can Learn from Scrum.
3 Miller, N. (2017). 4 Tips for Getting Value out of Software Customization.
4 Mackey, C. (2015). Open Geo Data and Performance Workshop. ACADIA, Cincinnati.
5 Maslow, A. (1966). The Psychology of Science. Harper & Row, New York.
6 Deutsch, R. (2017). Convergence: The Redesign of Design. John Wiley & Sons Ltd, Chichester, p.10.
7 Carnegie, D. (1936). ‘If You Want to Gather Honey, Don’t Kick Over the Beehive’. In How to Win Friends and Influence People. Sydney: Harper Collins, pp.31-46.
8 Deutsch, R. (2017). Convergence: The Redesign of Design. John Wiley & Sons Ltd, Chichester, p.104.
9 Deutsch, R. (2017). Convergence: The Redesign of Design. John Wiley & Sons Ltd, Chichester, p.156.
10 Latham, M. (1994). Constructing the Team. HMSO.
11 Penwill, R. CAD standards.
12 BIMe Initiative. BS 1192. BIM Dictionary.
13 Kanter, R. (2013). ‘Innovation: The Classic Traps’. In HBR’s 10 Must Reads on Innovation. Harvard Business Review Press, Boston, pp.101-124.
14 Indermill, L. (2014). Drink Marketers’ Great Challenge: Competing Against Water, Without Badmouthing It.
15 Young, B. (2017). Bluebeam vs. Autodesk: Why Can’t We Get Along?
16 Langella, S. (2016). ARCHICON and RTCAUS 2016.
17 Introducing BILT.
18 Allen, B. (2016). The Future of BIM will not be BIM: And it is coming faster than you think.
19 Huffpost. (2016). Exponential Thinking and why it will Change the World.
20 Diamandis, P. The Difference Between Linear and Exponential Thinking.
Standard architectural documentation convention dictates that all notes should be in uppercase. When working in Revit, if a team member hasn’t followed this convention, it can be a major task to fix, especially if you have hundreds of views and sheets. Rather than updating these manually, it is possible to use a plug-in such as BIMlink to export the values into Excel where they can be modified using the UPPER () function, before being imported back into Revit. This is somewhat tedious and can be further expedited with the use of Dynamo.
As part of the BVN Dynamo package (v1.4.3), there are three custom nodes: ‘View.NameToUppercase’, ‘Sheet.NameToUppercase’, and ‘Schdule.NameToUppercase’.
The ‘View.NameToUppercase’ uses the ‘View.IsViewTemplate’ node from the Clockwork package and will update both the view name and “Title on Sheet” parameter.
The ‘Sheet.NameToUppercase’ will update both the sheet name and sheet number parameters.
The ‘Schedule.NameToUppercase’ is a little more complicated because we need to exclude the revision schedule which are nested into title block families. Once this is done, it will update the view name.
Despite being super simple, these custom nodes are highly effective and may save you loads of time.
When spatial planning, some practices prefer to use proxy Revit elements to speed up the design iteration process. At BVN, we have developed a suit of families which we call ‘Push-it’. We use this methodology for the early stages of healthcare projects where the schedule of accommodation is critical.
In this workflow, an architectural column family is created which represents a ‘real’ Revit room. It contains various instance parameters including the width and length. This allows users to easily flex the family without fear of the room ‘breaking’ due to a missing wall. Hence, it is a quick and dirty spatial planning tool before we proceed to substituting these families for real Revit rooms and walls.
The family has a 2D door family nested into it. Using instance parameters, the user can decide where the door is to be placed. However, to ensure fast computation, only two adjacent walls are available for the door to be placed. If the door is required to be in the opposite wall, the family can simply be flipped using the instance hands. Sometimes when placing the family, users will not set the rotation correctly, resulting in doors not opening onto the corridor. To fix this, since only two door locations are possible, the family must be rotated 90 degrees, flipped if required, and then the width and length parameters swapped.
Obviously, prevention is better than cure but if some families do manage to slip through the gaps, you can use the ‘Family.RotateAndSwapParameters’ custom node available in the BVN Dynamo package (v1.4.2). The node will rotate the family 90 degrees and swap the width and length parameters. By default, these parameters are named ‘SP_Width’ and ‘SP_Depth’ but they can be updated to suit your own shared parameter names. After running the script, the room should look exactly the same but with the door on the adjacent wall.
The custom node first calculates the existing rotation of the family. Known as ‘Facing orientation’, the rotation is actually expressed as a vector within the Revit API. If you simply try to rotate the family 90 degrees using the ‘FamilyInstance.SetRotation’ node, it will override the facing orientation rather than adding 90 degrees to the existing rotation.
Therefore, we need to use the ‘Vector.AngleAboutAxis’ node to compare the existing facing orientation to the Y-axis to calculate the existing rotation in degrees. Once calculated, we can set the rotation to equal the existing rotation plus 90 degrees. After that, it is just a matter of swapping the width and length values.
Revit’s Project Browser allows you to sort and group views and sheets within your project. Each practice will generally have their own preferred project browser configuration embedded within the project template. Despite their differences, many practices adopt an approach of separating documentation views from working views. Documentation views are generally views which reside on sheets. They will generally be ‘locked down’ with the use of a view template. This ensure the views appear as desired when you go to print the sheets.
To avoid the temptation of working in the documentation views, separate working views can be generated. Note that this isn’t essential and some practices/projects prefer to utilise the ‘enable temporary view properties’ command. However, from experience I find this method more cumbersome and prefer to have my own working views.
When creating the working views (View > Create > Plan Views > Floor Plan), you have the option of setting the view type. By creating a dedicated working view type for each team member, view templates can be applied automatically when the new views are created.
To maintain flexibility within the working views, the view templates should only include values for how the view is to be organised within the project browser. All other parameters, including model categories, can be excluded from the view template.
During the view creation process, Revit will typically suffix each new view with “(1)” to distinguish it from the main view. Having views named “LV 00(1)” is not very descriptive. At BVN, our convention is to rename these views so that the suffix is your initials, for example, “LV 00_PW”. Depending on how many working views you have, this can be a time consuming process.
To automate this process, I have developed the ‘View.RenameWorking’ custom node as part of the BVN Dynamo package (v1.4.1). The node allows for two levels of view filtering. The default parameter for the first filter is “Design Stage”, which is set to “Working”. The default parameter for the second filter is “BVN Alphabet”. The second filter value is the new suffix, typically your initials.
By running the script it is possible to batch rename all of your working views. Note that if you have a copy of a copy, for example, “LV 00(1) Copy 1”, you may receive an error message within Revit saying “the name you specified is already in use. Enter a unique name’. In this scenario, the view will be excluded and will not be renamed.
When creating grids in Revit, Revit will name/number them in the order that they were created based on the naming convention last used. If you haven’t been consistent in your creation of grids, you’ll more than likely need to rename them. This can prove problematic as Revit will not allow you to have two grids identically named. If you try, Revit will return an error saying, “the name entered is already in use. Enter a unique name.” As a workaround it is necessary to temporarily rename the grids before naming them as intended.
To speed up this process I have developed two custom nodes available in the BVN Dynamo package (v1.4.0). ‘Grid.RenameAlphabetical’ will rename grids alphanumerically from A to ZZ, excluding “I” and “O” as per convention. ‘Grid.RenameNumerical’ will rename grids from 01 to 99. The sortAxis input requires a string, either “X” or “Y”, which relates to the axis the grids are sorted along. This affords flexibility in deciding which values (alphanumerical or numerical) you want to run from left to right, and bottom to top. The tempPrefix input is a string which can be used if other grids are currently using the same mark value. The toggle will update the temporary mark values to the final mark values.
Dashboard is an app developed by Flux and can be launched from your Flux home page. Unlike some of the other apps developed by Flux, it is not yet open-source. To create a Dashboard:
- Create your Grasshopper or Dynamo script with the usual input components to verify the script is working as intended.
- Create a new Flux project .
- Add in all the data keys that you’ll need, matching the Grasshopper/Dynamo inputs and outputs. For example, in our ‘twisty tower’ example I’ll need to create 10 as follows (6 input, 4 output):
These are currently empty keys. We’ll assign a value to the keys later.
- Back in Grasshopper/Dynamo, replace the input slider with Flux components. We’ll need to use the ‘Flux Project’, ‘Select from list’ and ‘From Flux’ components. These components will pull data from Flux. When removing the input components, be sure to take note of its function so that you can match it up with the relevant Flux key in the ‘Select from list’ component. Since the Flux keys don’t have a value yet, you will likely get an warning errors. This is OK.
Similarly, add in the new Flux output components to send the data to Flux. We’ll need the ‘Select from list’ and ‘To Flux’ components. Note that Flux only supports the following data types.
- In your Flux home page, click the ‘Launch’ button under Dashboard.
- Create a new dashboard by clicking on the plus button.
- Add in new dashboard panels as required. Generally you’ll need a ‘slider’ panel for an input, a ‘geometry’ panel to visualise the geometry, and a ‘value’ panel to report a value such as Gross Floor Area.
- When creating the dashboard panel, select the key to be paired with and give the slider a name (usually the same as the key). The min and max of each key is controlled here as well as opposed to Grasshopper or Dynamo, which is somewhat frustrating. Rather than adding multiple individual sliders, it is often better to ‘add a slider’ within the slider dashboard panel to create a multi-slider. The sliders will be structured in the order that they were created. Currently it is not possible to re-order the sliders once created, something I’m sure will be fixed in the near future.
- Once created, each dashboard panel can be scaled and moved as required.
- Modify the Flux sliders as required. There will be a short lag between adjusting the sliders until the geometry is updated. This is because data is flowing from Flux into Grasshopper before being send back into Flux. This process could be sped up by creating the entire script within the Flux Flow app, thereby eliminating Grasshopper or Dynamo altogether. Also note that unlike Dynamo or Grasshopper, it is not possible to double click in the slider and enter the desired value. You must use the slider by sliding it which makes achieving the desired value difficult.
Overall Flux’s Dashboard is still in an embryonic state and has some development to go before it is sophisticated enough for what most architects need. Plug-ins like HumanUI or Conduit offer much more advanced user interfaces if using Grasshopper. If your using Dynamo then there are less options. While the dashboard example above can be shared via a URL, it requires the recipient to have both Rhino, Grasshopper, Flux and any other plug-ins installed to run as expected. Therefore, in order to harness the full potential of Dashboard, the underlying script really needs to be written in Flow, Flux’s visual programming app. This would allow easy URL sharing, cloud computing and eliminate any software installation. The obvious problem with this is that Flow uses a completely different language to that of Dynamo or Grasshopper. Any existing scripts would need to be rewritten completely from scratch within Flow which is not necessarily practical nor desirable. Having said that, I’m sure Flux is aware of its limitations and I look forward to seeing the product evolve to reach its true potential.
If you like your classical architecture and proportions, you will be familiar with the concept of the golden mean. Also known as the golden ratio or golden section, it has fascinated architects and artists for centuries. The golden rectangle is thought to have the most pleasing proportions of any rectangle.
When spatial planning, it may be useful to first start with a room’s ‘ideal’ proportions, before adjusting it to suit the various project’s requirements. One example of how this could be used is in healthcare where the schedule of accommodation is critical.
In this workflow, an architectural column family is created which represents a ‘real’ Revit room. It contains various instance parameters including the width and length. This allows users to easily flex the family without the fear of the room ‘breaking’ due to a missing wall. Hence, it is a quick and dirty spatial planning tool before we proceed to substituting these families for real Revit rooms and walls. The family also contains the briefed area and actual area for instant visual feedback.
Since we know what the area should be and the equation for the golden rectangle, we can calculate with simple algebra the width and length. To automate this process, I have created the ‘GoldenMean’ node as part of the BVN Dynamo package.
Note that the area input, and the width/length output, will be of the same unit. Therefore, if you are modelling in millimetres but your area schedule is in metres, you’ll need to use the ‘Convert Between Units’ node.
When developing a project document list, the most convenient way is to create the information within Excel. The formulas and formatting in Excel allow for a lot of mundane document management tasks to be expedited. The next step is to get the document list into Revit and generate sheets from that list.
For a simple document spreadsheet containing sheet number and name information, we can use a simple Dynamo script as follows.
The title bock family and file path of the sheet list needs to be assigned as the inputs for the script which then get sorted and any redundant spreadsheet data removed before the sheets are created. There are 2 possibilities for sheet creation within Dynamo:
- ‘Sheet.ByNameNumberTitleBlockAndView’ – This is a standard Dynamo node that requires, Sheet Names, Sheet Numbers, Title block Family Type, and View inputs. If the project is in very early stages the views for the sheets are generally not created, so they cannot be used as an input without generating an error.
- ‘Tool.CreateEmptySheet’ – This is a node from the SteamNodes package that requires, Titleblock Family Type, Sheet Numbers, Sheet Names and the refresh inputs. The good thing about this node is that you don’t need to have the views in your model already created for it to work, as it will create empty sheets.
For a more complicated spreadsheet, we may have multiple worksheets and additional parameter information. For example, BVN utilises an organisation method for assigning different trade packages in a document set via the ‘BVN Alphabet’ parameter. This allows us to group and easily identify views and sheets in the Project Browser and group trade package documentation together. In the example below, the Excel document spreadsheet is identifying Sheet Number, Sheet Name, BVN Alphabet series, Sheet Issue Date, Design Stage, as well as having multiple worksheets corresponding to the different BVN Alphabet series.
Although these additional fields allow for greater functionality in Excel they add complexity in how Dynamo extracts the data. The enhancements to this script allows for the additional sheet tabs in excel to be read.
When converting a non-workshared model into a workshared model, all elements apart from grids, levels and reference planes will be automatically assigned to the default workset ‘Workset1’ (unless of course you renamed it something different). This is not very useful and depending on how far progressed the model is, it can take significant time manually assigning elements to the respective workset. Historically, BIM managers have utilised the Ideate Explorer add-in as a way to speed up the process.
To assign elements to a particular worksets, it was necessary to sort by ‘category’, and then possibly use the Ideate Query function to further refine the selection process before modifying the selected elements Workset parameter in the Properties Pallet.
Once assigned to a workset, it is possible to sort by ‘workset’ and then find any offending elements and change their workset parameter in the Properties Pallet.
This can be a very time consuming process, especially if you need to repeat multiple times. However, we can use Dynamo to automate this process.
As the worksets created are to an office standard they can be pre-programed into the Dynamo script for element assignment. The ‘Element.AssignToWorkset’ node utilises the BVN workset naming convention to automatically assign model elements:
- Non-structural walls, floors and roof whose type’s ‘Function’ parameter is ‘External’.
- Windows and doors whose type’s ‘Function’ parameter is ‘External’.
- Walls, roofs, floors who has the ‘Structural’ instance parameter checked.
- Structural columns.
- Note that this process takes precedence over the façade workset. Therefore, if a wall is both external and structural, it will be placed on the ’10_STRUCTURE’ workset.
- 20_VERTICAL CIRCULATION:
- Ramps and Stairs.
- Non-structural walls, floors, roof, windows and doors whose type’s ‘Function’ parameter is ‘Internal’.
- Furniture, Furniture systems and speciality equipment.
- Topography, planting, entourage and parking.
- 99_LEVELS & GRIDS:
- Levels, grids, reference planes, reference lines, and scope boxes.
Again this node is highly specific to one particular workflow but it can be easily modified to suit your specific needs.