When documenting a building, it is often necessary to generate internal room elevations. Depending on the building typology, this may include all rooms or just those with special finishes or fixings, such as bathrooms. Within Revit, internal elevations can be easily created via View > Create > Elevation. What is nice about this process is that the elevation marker, and its corresponding view, are automatically rotated upon placement so that it is perpendicular to the wall so that the elevation is true.
The problem
The problem with this process is that if walls are orthogonal, the best practice is to use a single elevation marker with multiple view indexes enabled to keep the documentation as clean as possible. But suppose this process is used on non-orthogonal walls. In that case, the internal elevation won’t be true and cause confusion. Take a stadium, for example, where there might be numerous radial walls, each of which will require its own elevation marker. This can be very time-consuming, especially if there are many rooms and each view needs to be renamed to match some naming convention. The challenge, therefore, is that two systems need to be adopted depending on the wall alignment:
- If walls are orthogonal, use a single elevation marker where possible.
- If walls are non-orthogonal, place a separate elevation marker perpendicular to the wall.
Creating internal elevations with Dynamo
To solve this problem, Parametric Monkey has developed a custom Dynamo graph, available as part of our Dynamo Package Development service, which can be run within Dynamo Player. Given a list of rooms, the graph places the relevant elevation marker depending on the wall condition. The views created are named – Room parameter value + View name constant + sequence, for example, “101 – ELEVATION 1”. Before running the graph, ensure your active view is the floor plan you wish to place the elevation markers.
To run the graph:
- Select the rooms to generate views from (#1). Note the graph automatically filters out everything that isn’t a room, so there is no need to isolate elements first.
- Define the view family type to be assigned to the new views (#2).
- Define the offset from the wall where the elevation marker should be placed (#3). Note that this value is from the family insertion point.
- Define the view template to be applied (#4).
- Define the crop region offsets for the view’s extent (#5-8).
- Specify if the crop region should be visible (#9).
- Define the room parameter to reference in the view name (#10). The default is “Number”.
- Define the view name constant (#11).
- Define the suffix numbering convention (#12). Values can be numeric or alphanumeric.
- Specify the hide as scales coarser than value to be assigned to the views (#13).
- Press Run.
Once complete, users can then run the separate Place views on sheet graph to finalise the documentation process.
Computational logic
Rooms are filtered to ensure only placed and bounded rooms are used. Rooms where the boundary cannot be calculated due to self-intersecting boundaries or unbounded rooms, are excluded and returned separately. The finished face of the room’s boundary is then calculated, and its orientation is evaluated.
If the room contains orthogonal walls (0, 90, 180 or 270 degrees), an elevation marker is placed at the room’s centre point, and the corresponding view indexes are enabled. The view’s crop region is then updated based on inputs #5-8.
If the room contains non-orthogonal walls, individual elevation markers are placed orthogonally but perpendicular to the wall’s centre point and offset based on input #3. The elevation marker is then rotated to be perpendicular to the wall. The view’s crop region is then updated based on inputs #5-8.
Views are then renamed based on the following convention: Room parameter value + View name constant + sequence, for example, “101 – ELEVATION 1”. The sequence naming convention can be numeric or alphanumeric, with orthogonal walls number first, followed by non-orthogonal walls. If views already exist with the same name, then the elevation marker and associated views are not created, and an error returned. Finally, the view template is assigned and the visibility of the crop region set.
Conclusion
Generating internal elevations is often a rite of passage for many young graduates. But it need not be labour-intensive. As shown above, the process can be substantially automated, reducing errors and ensuring more consistent documentation. To learn more about our Dynamo Package Development service, drop us a line and discover how we can automate your Revit workflows.
