Civil Object Creation in 12d Model
Steve Hunter of AECOM spoke to our 2018 Technical Forum delegates in July about civil object creation in 12d Model software.
Steve said that at the time of the 2016 12d event, most of the designers he was working with 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. He said 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. The critical word in that last sentence is ‘design’, and it goes a long way to explain the major difference between the process that goes into developing a traditional Building Information Model (BIM) and a modern Digital Civil Engineering Model. Even the difference between the terms ‘Structural Drafter’ and ‘Civil Designer’ gives additional clues as to this difference.
Virtually all the workflows and driving forces behind generating a structural BIM revolve around progressively bolting on 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 at times.
In Steve’s opinion, a single majestic pass for a civil engineering design progressively adding on more and more detail to the original concept is likely to lead to delivering 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.
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 really, really 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!
Steve felt it was important at this juncture to highlight the main purposes of a federated linear engineering model. By far the most important is that of space-proofing – 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, you need to have all these objects created to the level of detail appropriate to their use in the digital engineering model. This leads to the debate about 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 you continue to work your way through the list of details that don’t contribute to the space-proofing function of this object, you eventually get 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 the 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 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’s 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.
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’re not representative of where they’ll 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 2D 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. 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 folk to play 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’d 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. You can currently 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 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.
Enter your details to view the full presentation here.