Civil Object Creation - AECOM

Project Summary

Steve Hunter of AECOM addressed the delegates of the 2018 12d Technical Forum about his experiences with civil object creation in 12d Model software.

The Challenge

Most of the designers Steve was working with a couple of years ago had come to grips with workflows and mechanisms to expand their modelling of civil infrastructure with the solid modelling realms of trimesh pavements, plus linear elements such as kerbs and barrier systems. They were already reasonably proficient at reading in structural models, and two years later the focus on the digital engineering modelling effort has grown even more intense, with seemingly endless demands to expand the content and depth of 3D models. All this extra output has needed to come without taking its toll on the design effort put in to the generation of end products. This goes a long way towards explaining the major difference between the process that goes into developing a traditional Building Information Model (BIM) and those involved in developing a modern Digital Civil Engineering Model.

Virtually all the workflows and driving forces behind generating a structural BIM revolve around progressively adding more and more detail as the design evolves, with nearly all the detailed embellishments being edited in a virtually static framework. In a civil or linear engineering design – the ‘BIM PowerPoint’ – there is never any guarantee that even the most detailed object is in the final location, or that the number of objects won’t change as designs are optimised to give clients the most cost-effective, safe and practical design...invariably through a process of intensive duration that can even continue into detailed design.

A single ‘majestic pass’ for a civil engineering design progressively adding on more and more detail to the original concept can easily lead to a detailed but non-optimised solution. A civil engineering design is a dynamic process, and every detail added to models must be flexible and self-healing, adapting to the many ongoing design changes brought about by the optimisation process to prevent modelling errors. Designers should not allow themselves to be ‘painted into a corner’, unwilling to make major improvements or updates to alignments and designs because it’s just too hard to make any manual changes that result.

According to Steve, the term ‘BIM’ has come to represent the effort to ‘shoehorn’ into a civil engineering model a system designed around a building or structural framework. A classic example of this is the mindset of pretending a road is just a very tall building with cars driving on it, and that the floors are regularly shaped segments along the road. Of course, roads are notoriously uncooperative and have awkward stuff in them like interchanges, which pushes the building analogy to its limit!

By far the most important purpose of a federated linear engineering model is that of space-proofing – i.e. eradicating clashes between objects created by the various design teams that contribute to the final design; this has always been the cause of many last-minute frantic design changes out on site when most of these clashes were finally discovered.
Of course, to run this space-proofing or clash detection process, which is not always a formal reporting process as it also includes the simple but always effective ‘eyeballing’ process, it is important to have all these objects created to the level of detail appropriate to their use in the digital engineering model. This leads to debate over what constitutes an appropriate level of detail for a particular object. For instance, when modelling the top of an access chamber, does adding the surface textures really add to the value of the space-proofing process? As the list of details that don’t contribute to the space-proofing function of this object is worked through, the eventual result is something that takes up the rim of the riser and the lid, and which is located where the access point will be relative to the part configuration, as this may impact on surface features.

One of the other important uses of civil objects is as placeholders for additional information or metadata about an object, meaning that unnecessary detail does not need to be crammed into civil objects, particularly when most of these are actually standard objects, and this additional information can be provided by simply referencing the documents containing this additional detail. An example of unnecessary detail is including something like a physical grate in a model of civil objects. This level of detail bloats model data size with little real benefit to the primary reasons for modelling these objects in the first place. A solid object taking up the space occupied by the grate with metadata attached to it has exactly the same value without the data footprint.

"Humans are primarily visual creatures", Steve maintains, "and we are programmed to think that the level of pleasing, superficial visual detail is directly comparable to something’s true value in this world. In the 12d Model world, a classic example you often see of this is something simple like non-textured vs textured TINs – it looks pretty and visually appealing, but the true value of the 3D model in a perspective view is shown in a simpler but correspondingly more valuable non-rendered way when design abnormalities are visible and can be identified and rectified."

The 3D models produced by Steve’s team are engineering models, not visualisation models, and this is particularly the case when trying to inject realism into models to make them theoretically better, while actually reducing their true engineering value. There is an ongoing debate about how to model hybrid linear objects such as guardrails where they can use the realistic looking 12d Model extruders to show the posts and rail for guardrails, and even use these extrudes for sight distance checks.

AECOM’s guardrail snippet produces a trimesh region representing the space above ground for sight distance checking, and another below ground that the guardrail installation will occupy for clash detection. Their civil designers keep challenging the engineering value of modelling individual posts, and repeatedly point out that it can actually be misleading to apply interval-based posts based on the extents of the strings designed to represent the guardrail. Even if end treatments are excluded and simply paced out in two-metre steps from the start of the guardrail string, this process starts to unravel where the guardrail passes from one MTF function to another, resulting in a new string and a reset in the post placing. This means that the posts are potentially in the wrong location and false positives could result when running clash detection reports. False negatives that flag further investigation are vastly more acceptable than false positives, which can mask potential problems.

Steve pointed out that humans often have the tendency to jump to the conclusion that something which looks more detailed is automatically more accurate. There are examples of fence posts being shown in great detail but in purely interval-based locations; they are not representative of where they will actually be built. Treating fences and noise walls with the same logic as guardrails, the AECOM team runs a custom extrude along a super string representing the fence location, generating a model of the zone where the fence post may be, and addressing the potential clashes more closely when they are identified. Their current challenge in how they model isolated civil objects in a practical manner is doing so in a fashion which does not require a ‘doctorate in macro programming’, therefore limiting it to a select few. The process also needs to be immune to inevitable design changes as the engineering model is optimised and amended throughout its design life cycle. Civil objects they need to include in their digital engineering model originate either inside or outside 12d. Inside 12d they have 3D features such as electrical objects and survey models; outside 12d they often have 2D features (generated by specialists in other packages) – e.g. signs and line marking or street lighting and traffic signal layouts. It can be pretty alarming that objects which appear insignificant on a two-dimensional drawing actually occupy a large amount of 3D space through which they’re trying to thread proposed utilities.

The civil object workflow is not limited to existing and proposed utilities, and can be used for other civil objects such as a very large chunk of concrete that may be needed for anchoring wire rope safety barrier systems. Bearing in mind that the reason they’re creating these civil objects in the first place is primarily for space-proofing, an allowance needs to be made for such a large block of concrete. What makes this object different from, say, a light post, is firstly that the holding symbol needs to be applied to the end of the model of the wire rope safety barrier string and secondly that the orientation of the holding symbol needs to match that of the string terminal.

The Solution

To achieve this aim, the AECOM team organised to create a custom macro in 12d to achieve this…enter Sam Cech of Tatras Consulting in New Zealand! The resulting wire rope safety barrier snippet produces a result very similar to the guardrail snippet, plus it adds terminal information attributes to the marker string which is then used to place the holding symbol. When the civil object chain is run, the trimesh terminal objects take up space in the federated model for the BIM team to work with.

Sam’s macro is also used to place civil object holding symbols for other directional objects such as light poles and traffic signals with mast arms. In theory, if the focus is purely on space proofing and clash detection, it is primarily the post and footing that are important; the rest is aesthetics. They do, however, want to make viewing the federated model an intuitive experience to allow for easy visual identification of civil objects, and fortunately setting the orientation to these objects is easy to automate. For the Surveying team at TMR, for instance, the mast arms for traffic signals and light poles are represented by two points running from the lantern to the base of the pole, and by placing a holding symbol at the end of the string and running the civil object chain you get lights that are correctly orientated with a process that’s about the same amount of effort as applying a standard mapping file.

Steve originally thought they would need a drawing template based civil object chain to run on the drainage PPF plans to evolve their drainage network into what is needed for federated engineering models, but he started investigating the option of drainage trimeshes that are set in the drainage.4d file and – as with the other civil objects shown – it relies on a 3D library of drainage structures to cap off the top of the drainage model chambers, with up to 24 variations needed for each pit style to take into account lintel size, channel width, inflow configuration and orientation relative to the kerb. These have always been defined for hydraulic reasons but now also need to take into account the kerb type to include the kerb transitions in the trimesh (and ultimately in the federated model). The top structure of the gully pits and access chambers orientate themselves in the same way as the drainage plan PPF plots, including automatically adapting to the flow direction so no extra effort is required from the drainage designers because the drainage trimeshes update with a standard set pit details process. Steve was particularly impressed that the drainage trimesh also tilts itself to suit the road grade calculator and the setout string, so the final 3D orientation is actually very close to the real thing.

AECOM’s drainage designers have always modelled the existing drainage network, primarily for hydraulic reasons, but it’s now included in the federated model, and one of the processes designers typically had to do pre-BIM was to separate the drainage model into the kind of categories or states that are referred to in the modelling of utilities, partly because the various states can then be visually identified or even manipulated visually in the federated engineering model. Engineers and ‘BIM folk’ become concerned if they see a drainage structure in the middle of the road on a design, even if it is one that’s flagged for removal, so it may be necessary to temporarily hide objects such as these. It is possible to do this in 12d Model by incorporating and identifying the pit and pipe names and filtering for these in the drainage trimesh model – i.e. splitting them into submodels.

The Result

The final plan integration of these model drainage structures into AECOM’s models is adapting the road designs to leave gully pit shaped holes in their design surfaces and other trimeshes. Steve ‘tried to be sneaky’ by including a boundary string in the drainage pit trimesh definition which could then potentially be used with a 12d Model 14 trimesh cookie cutter, but unfortunately 12d was ‘too smart for that’ and ignored it when reading into the drainage trimeshes! His team can, however, adjust their road strings to suit a drainage object with a bunch of fiddly MTF modifiers, tucking these away inside snippets to avoid alarming those poor engineers and BIM designers. It is even possible to create a null string containing the TIN boundary attribute to automatically cut a hole in any TIN the boundary is actually included in.