The daily production mechanics of Autodesk Civil 3D’s interconnected and project-based Dynamic Model are indeed very powerful. These sometimes-convoluted mechanics can be downright overwhelming as well. We aren’t always so clear what that means at the very practical and daily work level.
We are all confronted with a daunting certainty in Civil 3D. The simple world of basic CAD primitives is replaced by things that appear to look like and seem to act like ACAD primitives, but functionally dance together to different rhythms.
This may become a stumbling block for all Civil 3D users. Put it this way:
“We know what we know.
We don’t know what we don’t know.”
Let’s try to find new and better ways to…
Tell the Story of How Autodesk Civil 3D Works
The important concept of Buckets in Civil 3D as outlined below makes sense to many people.
This post is a revised and updated version.
Features
Here we refer to Civil 3D things found in the Toolspace>>Propector and Settings tabs as Features.
A Feature is a technical programming term that refers to a collection of OOP (Object Oriented Programming) objects that communicate and interact with one another. In some places, Civil 3D internally refers to these Features that way. In many places in the Civil 3D interface and Help files it does not.
Sadly, the words entity, primitive, object, component and feature are too often employed interchangeably. OOP speak will tend to get mixed up when we attempt to simplify and/or generalize about the specifics too much.
Collectors
We also refer to Features as Collectors. That is intentional.
Collection is a central part of what Civil 3D Features do. Technically, all Civil 3D Features are Collections. Almost all Features are collections of collections. The ordered Collection is again a fundamental OOP concept. The collective concept that Civil 3D is designed around is practically a big deal. It is also way too easy to overlook and/or dismiss as obvious.
Let’s get simple. To be too technical about such things can and often does get in the way of the more important points of human understanding and practical application.
Inside Civil 3D…
If We Name It in Civil 3D - It’s a Bucket
The Buckets (they are Features) almost all gather specific kinds of data into smaller and more detailed mini-buckets. We often refer to this as the data behind in Civil 3D. It’s not always what we see on the screen in Civil 3D, but the data behind that matters.
Whether we consider the Civil 3D diva to be male or female, we’d better watch that.
There are What input buckets; How buckets; When (order) buckets; and a currently resolved Model bucket.
- The Model gets a Feature Style assigned to it most, but not, all of the time.
For example - a Site Parcel Feature sadly lacks a Style.
A Mapcheck is a Feature that has no Style and doesn’t even appear in the Toolspace. - The contents of other Feature mini-buckets sometimes have names and Style assignments too.
That manifests itself on the annotative Label Styles side of the Features.
Code Set Styles are another classic and initially befuddling example in a Corridor Feature.
Non-linear Learning
How fast we learn Civil 3D is a non-linear function of how quickly we can learn to identify how to get to specific Buckets and their specific mini-buckets within the interface.
This is a pattern recognition and physical habit of usage challenge.
Yes. The Learn and Burn can be painful and frustrating.
Hints: Employ the Toolspace (not the screen).
Right click is our friend and wingman.
The Cycle Our Focus Skill in Civil 3D post may help.
That important post covers the essential user training patterns for Civil 3D.
Features Collect Data
This Buckets concept may make more sense if we talk about Surface Features as an example. Most civil engineering and survey folks are familiar with the concept of multiple forms of potential data input (points, contours, breaklines, etc.) because of how classic DTM software approaches the serial problem of surface model construction.
The Civil 3D Surface Feature is purposefully made to appear to be familiar - like the classic DTM surface model software. Is it? Not exactly.
True. A surface is a surface but how we get there in Civil 3D isn’t quite the same.
The Civil 3D interface names are the same for common engineering and survey terms but what the Features are and how they work internally is different.
The Buckets in the Surface
The Civil 3D Toolspace>> Prospector>>Surfaces>>[Named Surface]>>Definition branch (the What) has the following input mini-buckets neatly displayed for us.
The properties and current conditions that are applied to the Surface Model are really in another separate mini-bucket – the How – These are found in the Surface’s Build properties.
There is an Edit stack bucket that allows us to add and modify the When order of the What.
Why? - Because in a Civil 3D Feature the What bucket order matters.
The Model is the current resolved Surface results – aka the output bucket. Note that for performance reasons, the current Model state may or may not be resolved.
- We perceive that we Name the output Model bucket because that is what we do all the work to produce.
- The Model is also what gets shared in a data shortcut (DREF). That reinforces our perception that the Model is the Surface, but it is not.
- The same Name for the current resolved Surface Model is a convenient, programed after-effect.
- There are multiple kinds or types of Surfaces with different collections of different mini-buckets.
- Both Grading Groups and Corridors produce surface Models with discrete output surface Names that we can and do need the manage and control.
We do not get to Name many of the internal buckets of Surface Features, but notice that we can and must Name the specific What inputs.
For many Civil 3D Features we must Name the specific What buckets or Civil 3D will do it automatically for you. Stop.
- Do you really want Civil 3D to Name it that?
- Beware. In training and in demos we often don’t seem to care.
Most training content tends to focus on the how to do it not how to manage it. - In an actual live project these subtle Name definitions make a huge difference to successfully managing the structure of the project’s data behind.
- The Name Templates in Civil 3D are there for a good reason.
Plan for and employ them. - Prepare to rename a lot.
Do Other Civil 3D Features have Similar Bucket Structures?
The Alignment Feature has grown to be a more complex Feature than a Surface. It has What, How, When, and Model buckets. An Alignment has Buckets of child Features (Profiles, Offset Alignments, Offset Profiles, Widenings, etc) each with their own collections of mini-buckets.
There is an entire Book of Alignments post series about the Civil 3D Alignment – The Civil 3D Design Control Manager. We also posted about the Site Parcel’s many buckets in a long series of posts. True. We did not use the word Bucket. We mostly employed the collector word to emphasize those aspects.
The primary benefit to us of the Types of Buckets in Buckets approach is a better and more formal Structure to the data behind. If we care to play along, a better potential QAQC and iterative engineering process will emerge.
We will…
Learn Civil 3D Quicker and Better
The scary thing is we can almost ignore the whole Bucket of Buckets idea and muddle on through with our work as though almost none of this Structure to the data behind exists. We end up with unwieldy drawings with lots of Features or, on the other hand, structured and managed collections of drawings with fewer and better managed Features.
No matter what, we must learn to find, edit, and manage the What, How, When, and Model mini-buckets in the many Civil 3D Features.
We certainly must Name the Buckets.
This post on Civil 3D and the Power of Names talks about the deeper ramifications.
Can we use…
Buckets in Our Templates?
Next time…What can the Civil 3D Name Templates and Placeholder Features do to us and for us?
Make Civil 3D Work Better
Get the Framework for Civil 3D
The Civil 3D Buckets
Updates, additions, and fixes to the posts in this series are on-going.