Civil 3D Production Buckets

Jump Kit

The Framework for Civil 3D
Get More

Templates Only

See The Framework Work
Get More

Become a Member

Master Civil 3D
Get More

Autodesk Civil Videos

Free Civil 3D Training
Get More

Framework Videos

Free Civil 3D Videos
Get More

The production mechanics of AutoCAD Civil 3D’s interconnected and project-based Dynamic Model is powerful. It can be overwhelming. Maybe we all aren’t so clear what that means at a practical and daily work level.

Long time CAD users are faced with a daunting certainty when they are confronted by Civil 3D. The simple world of basic CAD primitives is replaced by things that appear to look like ACAD 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 the trainees. We know what we know. That can get in the way of recognizing that we don’t know what we don’t know.

I always seek to find new and better ways to try and…

Tell the Story of How AutoCAD Civil 3D Works

The training concept of Buckets in Civil 3D that is outlined here makes sense to many people. This is a revised and updated version. I’ve covered the important topic before.

Features

I 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 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. Sadly, the words “entity”, “primitive”, “object”, “component” and “feature” get mixed up when we attempt to simplify and/or generalize about the specifics too much.

Collectors

I also often refer to Features also as collectors. That is intentional. Collection is a central part of what Civil 3D Features do.  Collection is a new behavior in model-based software for CAD users. All Features are technically collections and almost all are collections of collections. Again it’s an OOP (object oriented programming) thing. In the beginning and in basic user training this is too easy to pass over. The collective concept that Civil 3D is designed around is practically a big deal.

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…

It’s a Bucket if You Name It

The Buckets (they are Features) almost all gather specific kinds of data into smaller and more detailed mini-buckets.  We refer to this as the data behind. Whether you consider the Civil 3D diva male or female, you’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 show in the Toolspace.
  • The contents of other mini-buckets sometimes may have names and Style assignments too.
    That manifests itself on the annotative Label Styles side of Features.
    Code Set Styles are a classic and initially befuddling example in Corridors.

Non-linear Learning

How fast you learn Civil 3D is a non-linear function of how quickly you can learn to identify how to get to specific Buckets and the specific mini-buckets in the interface. This is a pattern recognition and physical habit of usage challenge. Yes. That can be painful and frustrating. Hint: Use the Toolspace (not the screen). Right click is your friend and wingman. The Civil 3D Focus Cycles post may help. It covers basic driver training for Civil 3D.

Features Collect Data

Obviously. Perhaps this buckets concept makes more sense if 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 serial 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. True. A surface is a surface but how we get there isn’t.
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. We all quickly discover that.

Buckets in 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 in another separate mini-bucket – the How – found in Build properties. There is an Edit stack bucket that allows us to add a When order to the What. Why? - Because in a Civil 3D What bucket order matters. The Model is the current resolved surface results or output bucket.

  • We perceive that we Name the output Model bucket because that is what we do all the work to get.
  • The Model is also what gets shared in a data shortcut. That reinforces the perception.
  • The same Name for the current resolved Surface Model is a convenient, programed after-effect.
  • There are multiple kinds of Surfaces with different mini-buckets.
  • Both Grading Groups and Corridors produce surface Models with discrete output surface Names that we can and do control.

We do not get to name many internal buckets of Surface Features, but notice you can and should 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?
  • In training we don’t seem to care.
    Basic training tends focus is on the how to do it not how to manage it.
  • In a real project these subtle name definitions make a huge difference to successfully managing the data behind.
  • The Name Templates are there for a good reason.
    Plan for and employ them.
    If not, prepare to rename a lot.
    So if you rename a lot you don't really have a plan.

Do Civil 3D Features have similar mini-bucket structures?

The Alignment Feature has grown to be a more complex Feature than a Surface. It has What, How, When, and Model buckets too. It is good practive to identify them. An Alignment has Buckets of child Features each with their own mini-buckets. There is an entire Book of Alignments about the Civil 3D Design Control Manager. In the past, I posted 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 to emphasize that new unexpected aspect of Parcels.

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 Faster and Better

The scary thing is you can almost ignore the whole idea and muddle on through with your work as though almost none of this structure to the data behind exists. However, not matter what, we must learn to find and deal with the What, How, When, and Model mini-buckets in the Features.

We certainly must name the Buckets. This post on Civil 3D and the Power of Names talks about the deeper ramifications and Adaptive Standards for Civil 3D. Can we employ…

Buckets in Our Civil 3D Templates?

Next time: What can Placeholder Features and the Civil 3D Name templates do to you and for you.

Get a Better Civil 3D - the Framework for Civil 3D