Whew! I had to take a break from Parcels in AutoCAD Civil 3D. To do an in depth series of posts on the Site Parcel is in a good and useful thing. I learned a lot. I trust your eyes maybe open wider. The practical daily reality of Civil 3D’s interconnected Dynamic Model is powerful.
I always seek to find new and better ways to try and…
Tell the Story of How AutoCAD Civil 3D Works
Long time CAD users are faced with a daunting new reality when they hit model-based software. The simple world of basic CAD primitives is replaced by things that appear to look like primitives, but functionally dance together to different rhythms. When I train people in AutoCAD Civil 3D, I’m constantly faced with the stumbling blocks this presents to trainees.
Features
In the posts found here I constantly refer to Civil 3D things often found in the Toolspace>>Propector and Settings tabs as “Features”. A “Feature” is a technical programming term that refers to a collection of OOP objects that communicate with one another. In some places Civil 3D internally refers to its Features that way. In places in the interface and Help files it does not. The words “entity”, “primitive”, “object”, “component” and “feature” get mixed up when we attempt to simplify and/or generalize about the specific too much.
Collections
I also often refer to many Features also as “collectors”. Truthfully, all Civil 3D things are technically collections and almost all are really collections of collections. Oh My! Again it’s an OOP (object oriented programming) thing. Big Whoopi.
To be too technical about such things can and often does get in the way or the more important points of human understanding and practical application. Inside Civil 3D…
If you Name it, it’s a Bucket.
The buckets (that are Features) almost all gather specific kinds of data into smaller mini buckets. 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. Sometimes the contents of other buckets may have Style too.
Features Collect Data
Well Duh! This makes more sense when we talk about Surface Features. 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 problem of surface model construction. The Civil 3D Surface Feature is purposefully made to appear to be familiar - like the classic LDT surface model software. Is it? Not really.
Buckets on the Surface
The Civil 3D Toolspace>> Prospector>>Surfaces>>Named Surface>>Definition branch has these input mini-buckets neatly displayed for us – the What. The properties and current conditions that are applied to the surface model are really another separate mini-bucket – the How. There is a Edit stack bucket that allows us to add a When order to the What. Why? - Because a What bucket order matters. The current surface Model is the resolved results or output bucket.
We may perceive that we Name the output bucket because that is what we do all the work to get. The Model is what gets shared in a data shortcut. That reinforces the perception. The same Name for a Surface Model is a convenient after-effect. Both Grading Groups and Corridor Features produce surface Models with discrete output surface Names we do control.
We do not get to name many internal buckets of Surface Features, but notice you 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.
Do other Features have similar mini-buckets?
We could talk about the Alignment Feature (which has grown to be a more complex Feature than a Surface) in exactly the same way – by What, How, When, and Model buckets. Lately, I talked about the Site Parcel’s many buckets in a long series of posts. I did not use the word “Bucket”. I mostly used the “collector’ word.
The primary benefit to us of the Types Buckets in Buckets approach is a better and more formal Structure to the data and therefore a better potential QAQC process, if we care to play along.
The scary things is you can almost ignore the whole idea and muddle on through with your work as though almost none of this multiple buckets in buckets thing exists. However, not matter what, we must deal with the What, How, When, and Model buckets in the Features. We gotta name them.
What can the Civil 3D Name templates do to you and for you next time.
PS The absence of pictures in these two posts is intentional.