Back in the day Autodesk liked to talk up the Dynamic Model. Remember that? The fact that Civil 3D Features (or objects) communicate with one another so we do not have to worry so much about whether or not the stuff you see and print in Civil 3D is actually updated.
If a Civil 3D user changes a design Alignment and Profile, the entire roadway Corridor model and the resultant surface(s) update dynamically. Cool beans. Even the separate, but related, annotative Labels in plan, profile, and section update accordingly. The fundamentals of a Dynamic Model work!
The Dynamic Model is Better Than Magic
This is better than magic. It is a golden goose. Potentially, the functional dynamic nature of the model actually pays off in real-world contract dollars. This should be generated by significantly reduced man-hours invested in both the maintenance of civil engineering and survey data stuff in our projects and the reduced total amount of quality assurance and/or checking hours invested. We spend more time doing the iterative do instead of the busy work. Hoorah.
But if you don’t change what you bill for, you might be shafted. To loose the golden goose is pretty significant, but not the subject of this post.
Is this Dynamic Model in Civil 3D drawing-based or project-based?
This is a mission critical question. Almost all Civil 3D newbies get immediately sucked into a single dynamic model in a drawing trap. It only appears that a Dynamic Model is easier to pull-off and manage in a drawing. A single drawing model is easier to demo and teach, but does it work? Rarely.
In real world projects a single drawing project rarely, if ever, works. By that I mean you might be able to make it work, but you probably don’t want to. This is more than a complexity or file size problem. It is a logic and data management problem. The roots are built into the collective OOP (object oriented programming) rules behind the Civil 3D code and object model. But you, as a Civil 3D user, don’t care about that.
Ok. You might care about the important practical details, so read the A Civil 3D Managed Dynamic Model Works post.
I like to put the complexity, collective-logic problem another way…
All Civil 3D Models Tend to Become Spaghetti
Functionally, Civil 3D Reference logic cannot tolerate self-reference. Therefore, we must separate the Civil 3D Feature (dynamic objects) collections to manage them into a functional dynamic model in Civil 3D.
At the project scale a Dynamic Model depends on the systematic and managed and use of Civil 3D Feature-centric Data Shortcuts, or rather, their respective Data References (DREFs).
I always try to call this the Data Behind. I do this semantic dance intentionally so that we can identify, talk, and consequently act on the model differently. The Dynamic Model data is not what appears on the screen. That is always a momentary state. The model data is not what that is. Sort of confusing?
Civil 3D is actually more dependent on project structure, organization, and an ongoing project maintenance process. The whole kit and caboodle of the management problem of a Dynamic Model gets dumped into the Civil 3D user’s lap. We can manage to do something about that. Read the Civil 3D Project Startup series of posts that start with Civil 3D Survey Project Prototypes. Register; become a Member; and gain even more competency.
The problem drop onto Civil 3D users is one reason why everyone talks about workflows instead of dynamic models these days. What the model is and does is not as important to folks as how to get there.
A Workflow is a Trained Process Skill
The steps of how you get there in Civil 3D do matter. The steps and the process order must be learned to become an effective and productive Civil 3D skill. As the Civil 3D code changes, so do the nuances and potential capabilities that can arise out of the code.
You built parcel maps in Release 2016 in Civil 3D. Are parcel maps built the same in Civil 3D 2019.2? A more obvious example is probably a roadway or site grading Corridor. The build differences between Civil 3D 2016 and Civil 3D 2019.2 add up to a staggering difference in the many nuances and potential steps of the workflow. Yet, the trained introductory Corridor basics remain pretty much the same.
How about a visual example of these Functional Dynamics of the Model issues. The good news this is coupled with a neat trick involving Code Set Style capability in Civil 3D. We get to learn two useful lessons at the same time. Thanks to Jowenn Lua and his AKN page for the video.
Create 3D Block Markers on a Feature Line
Jowenn’s trick aptly illustrates that a corridor’s Code Set Style can do amazing stuff. After all, a Code Set Style sort of serves as an output Layer Manager for Corridors. Maybe a Code Set Style is more like a Layer State?
Code Set Styles do a lot to help us manage the collected specific and applied Styles in a corridor model just like a Layer State manages the very dynamic properties of a collection of layers.
Is Jowenn’s finished example corridor that is built with a dynamic Feature Line and now includes nifty and dynamic 3D block markers driven by the Point Codes and the Frequency of his corridor a thing we can maintain by itself? Certainly. Do you want to?
The Data Model Complexity Grows
Can we actually employ this trick to produce regular stationed light poles in a complex multi-baseline roadway corridor?
Typical Infraworks example models do this. The new Infraworks 2019.2 Civil Objects make crazy stuff possible.
In Civil 3D, we would have to maintain a separate Baseline and Region in the corridor to cope with the different applied Frequencies. Our Code Set Style is definitely going to be more specific to that task. To deal with rotations we may need different applied Marker Style versions. Can we get the proper rotations out of one Baseline and Regions or do we need separate Baselines, Regions, and related Point Codes for both sides of the road? We still have the classic Plan, Profile, Section view annotative problems too.
Autodesk might help a bunch by allowing Baselines and Regions to have types or classifications. I’d love to be able to load external standard property sets into a Region without all the manual mechanics required in the Corridor Property box today. Region creation and maintenance is a tedious hinderance to productivity.
Our projects probably shouldn’t wait for Autodesk to fix these things. We have project work to do today.
These are Locations and That Might Be the Point
Given we have our Corridor and the Feature Line(s) we could employ Corridor Station Labels to produce annotative Civil 3D point objects on demand in any project drawing (with replaceable on-demand 2D and/or 3D markers with rotations) without much trouble.
You get the point. If not, read the Corridor Station Label post series that start with Publish Better Civil 3D Corridor Designs. There are even videos to explain. What do you know? They work.
How dynamic you want your sexy model to be is something we must manage, or the Civil 3D diva manages us.
Release the Power Beyond the Code
Release 8 - the Framework for Civil 3D
Back to the Civil 3D Fundamentals Posts