People wave their hands and talk about "Model Based" software, "Model Based" design, and BIM. What do these words really mean where the rubber hits the road?

Maybe the answer is simple, but it sure appears that takes a while for people to get the unexpected consequences. 

Model-Based is Simple and Elegant

We build a "reasonably realistic" model of what we want BEFORE we attempt to actually construct it. The phrase "reasonably realistic" means "suitable" from my perspective, but that's the subject for another post.

Hopefully, our model building isn't too time-consuming. At first, learning the model-based structures and processes will unquestionably make our model building consume More project man-hours up front. If that doesn't change pretty quickly, you are probably doing some basic things "wrong" or at least incorrectly. If it keeps happening, please get some help and a change of perspective. It's really not supposed to be or work that way.

Hopefully, our model is good enough and the design software is also robust enough to actually help us construct, quality assure, and publish the model in multiple ways too.
All these three parts are essential and equally significant to our success. 
Our skill and experience, our understanding of the design discipline(s), standards, and real world systems, AND our Civil 3D usage skills all are put to the test thoroughout these processes.

More Ain't a Joke

The problem of More than one process going on at once isn't a joke. Simultaneous multiple processes confuse us personally and corporately. They upset our old school CAD workflows, and our habitual way of working (what always worked before) most of all. Personal task accountabilities get all mashed up and mixed together in new, and perhaps, unforeseen ways in the new environment.
The basic questions and answers to What, Where, When, and How simply are not the same anymore.
Those uncomfortable and overwhelming facts can and do produce negative expectations and More. Maybe we REALLY didn't want anything to change in the first place. But it did, it will, and it must. Complex socio-economical realities we don't and cannot control make that so.

We Can and Do Miss the Forest for the Trees

At the beating heart of "model-based" design is the core concept that the model and it's managed "data" will produce the published results we will require.
Yippee! The end of drudgery is on site!
Civil 3D actually can do this remarkably well today. But on a practical level, to many Civil 3D users and organizations it sometimes feels like Elvis left the building or never showed up at all.

The model building/publishing problem and the complexity of the output publishing processes can easily become a beast all by itself in these multi-process muddied waters. 

Here's why. Our decades of previous CAD experience teach us to go back and focus ALL the time on the details present in the "model" to solve the problem.  That makes sense because this focus was absolutely necessary when the CAD software was primitive based NOT Feature-based (model-based).  Put another way...
We won't and can't throw away our previous "investments" even when they may no longer apply or actually require some additional investment to again become even More useful.

Recently, I heard a telling example of this kind thinking , "All our details are in CTB format so we can't use STB or we have to "convert them all". They employ old school .shx font files in the details; have their own internal detail Layer scheme; historic hatch patterns, etc. Who doesn't? Converting all that to the any other standards will "take forever" and be a waste of resources that are currently "in short supply". So

"We'll have to keep doings things the same way."

Huh?

Aside from the fact that there are a number of ways to automate and/or systematize a conversion process for this kind of stuff, (they do own AutoCAD Map 3D and AutoCAD after all) there is another More significant issue.

Ask Another Question

"What are you publishing? Are you really handing over digital "drawings", your complete project models (Yes there can be More than One), or just submitting a dwg based plan set?"

To them their "project", the "drawings", the "model", and even their deliverables were all the same thing. To be honest, they probably DO know better, but that has been their world in LDT since the early nineties. By now they "know" Civil 3D is different, but they still can't quite break the old mold and reengineer the new machine they need. A some deep mental level Civil 3D was just replacing the old software. Changing how and what they were producing as work wasn't being questioned in any real depth by anyone except maybe some of their customers. These were just tired of converting the "old" dwgs to get backgrounds to use in their own deliverable plan sets.

The Critical Issue and Our focus must be

Make Publish on Demand Real

The model is the Model and that is all it is.

Good models don't and shouldn't care what they "look like" in a Feature (data) based world. The model and its data structure(s) should be stable, but remain malleable, flexible, and able to be validated first and foremost. Civil 3D is NOT perfect at this without some informed user hand holding, a known structure, and some organizational maintenance and publishing processes in place. 

From a historical perspective CAD looked like it could do Publish on Demand. People promised it (and continue to promise it) today. Technically, CAD by itself could NOT perform because of its fundamental CAD primitive only definitions. CAD is like stacking concrete blocks on the ground by themselves and saying or thinking you've constructed a retaining wall. 

Ordered pictures of parts by themselves do not make systems. However, the old school CAD "device" did allow us to create an acceptable illusion of the real world system(s).

Please note that you have to work on the PARTS and their careful arrangement in detail to make the end published illusion work.

Maybe it is still called "AutoCAD" Civil 3D for a reason?

NOT

We know Civil 3D employs Feature (model-based) "representations to display and annotate the data buried in a Model's Features. Yes, if you explode the Features you'll get simple CAD primitives. Dumbing down to CAD into any format is not rocket science today, but that is only practically useful if you view the acts as a linear publishing one way output process. That means that the "Export to" process REALLY is a separate and discrete process triggered by a known event and performed from a known checklist.

All forms publish and reporting processes in Civil 3D need to be seen and dealt with this way. It maximizes the use of your real world resources to do this. The More you can move and concentrate publish details into a one-way OUTPUT process the faster it works, the easier it is to maintain, and the cheaper it becomes to perform. That is basic process engineering and mechanics 101.

Work the Same and Publish on Demand or NOT

Publish on Demand (POD) is something you must work on ALL the time in your project. You will and MUST fail and then learn and improve to get better at it.

How Do You Do That? 

The specifics and details of the output POD process must NOT get mixed up with the model building, QA process, etc either. This is HARD to do because of our detail centric CAD experince is focused on what we see NOW or in other words - the CURRENT state of MY drawing.

STOP

In a model-based world, ALL publishing ALWAYS happens from an OUTPUT drawing specifically built and designed to help us perform the specifics of our Publish On Demand process.

That means there WILL be More than One Publish On Demand drawing doesn't it?

That also means that our all important MODEL should eventually become the replaceable and almost disposable object in our project structures.

That is what "Model-Based", "Feature-based", and/or "Data based" really means.

BIM IT

Now if we want to talk about BIM in a substantive way, we must introduce continuous feedback loops into those external publish processes too. 
We must have those basic loop structures and methods already in our internal processes to get to functional Publish on Demand and do our internal QA well anyway.

Can you say, "How would you like your ______ today?"

InstantOn Basic and the Jump Platform exists to help you focus on that More Important Work. That happens to be what you get paid for.

Flip the Mindset

Recently, I've gotten a number of requests from people who want help getting their Civil 3D Feature based drawings smacked down to "dumb" AutoCAD and other CAD or GIS formats. This includes the still too common problem of getting your Civil 3D stuff back to LDT.

Think Smart Before You Dumb Down

Before I say anything about Dumb Down to ACAD at all, you need to consider a few other important things first.

If you send them a drawing or any digital CAD format, they can change it no matter what you do. This can be bad news. Secondly, you may also give them far More than they want or really need.

Ask what they REALLY need. ALWAYS ask what they need it for. Meet the need.

The data exchange problem can be a HUGE "unseen" man-hour issue in a project. That topic is certainly worth another post or two.

DWF or PDF IMAGE. Why not just send them an image to plot? DWF images work and they may include Layer ON/OFF control. PDF is dumber than DWF - really, but at least people think they know what they are getting.

PROXYGRAPHIC IMAGE also works for people in the same AutoCAD drawing format release cycle (e.g. AutoCAD 2010 dwg format). The end user can't change anything (good news) but they can externally reference your file, layer control it, and plot it. Unfortunately, many end users don't understand the PROXYGRAHPICS rules and how it works at all. Educate yourself and then be prepared to educate them.

Civil 3D Object Enablers - If the end customer employs AutoCAD based software in the same release as your version of Civil 3D, they can install and employ Autodesk’s free object enablers. Civil 3D files in native format can be delivered to the end user. Object enablers also allow some simple and very basic graphic control of Civil 3D Features and annotation.

As a producer, you should also recognize that only ONE Autodesk application object enabler can be installed on your end user's computer. Your end user cannot install two different versions of the Civil 3D object enablers on the same machine. Arrrgh!

LANDXML and/or Survey LandXML works to transport the Civil 3D data which may be kinder than a DUMB CAD drawing anyway. You don't control what things look like, but they get the information if that is what they are paying for. This method works for a lot of surveying firms collecting data for design teams.

"We NEVER Take Back Deliverable Drawings We Send Out"

Every firm should seriously consider this SIMPLE but effective rule. This DOES mean exactly what it says. Markups are NOT what you send out. Returned Markups should NEVER include what you sent because they NEVER have to. You have EXACTLY what you sent.

Here's a brief summary of the basic DUMB IT DOWN methods with some comments, realities and some tips as a place to start.

From Many Make One

This is the simple unspoken truth about Civil 3D to dumb CAD.

Civil 3D has complex multiple collections of objects called Features. Features are even connected to other related Features. The "Dynamic Model" has to be taken apart and published into many discrete CAD objects collected differently into the old-school Layer management system we know so well.

If you must produce editable content, you will make multiple "export" drawings, process them, and combine them into ONE DUMB CAD file.

AutoCAD Civil 3D 2010+ has a number of commands you can employ to produce raw AutoCAD dwg files. The command methods are available in the Civil 3D interface in a variety of ways – Ribbon, Command Line, etc.

All of these methods produce "representations" of Civil 3D Feature data with the intention of preserving the graphic arrangement and basic visibility of the Feature components and automatically generated Feature annotation. 

You should NOT employ these commands without thoughtful preparation of the displayed contents of the Civil 3D Feature data. 
"Export to" Styles and Sets in :Export to templates" can do a LOT to help you.
Simply pushing the SaveAS button will often produce unacceptable results from an end-user's editing perspective most of the time.

Why do  they need to edit what you are sending them?

Typically, even “simple” Points export will involve the production to two separate drawings containing different “parts” of the Civil 3D data that is displayed. For example: LDT end users expect LDT Point data in attributed blocks and the annotation objects - block symbols and text labels at Point locations all on different layers. AutoCAD users typically expect either AutoCAD point objects at elevations and similar symbols and annotative Point data again sorted "ByLayer". Civil 3D can pump out both easily.

Line work output and annotative output from surfaces, parcels, and other Civil 3D Features will simply add additional publish drawings to your final export process.

Now the DUMB IT DOWN commands... 

SaveAs

The AutoCAD SAVEAS command is a superset of the Civil 3D "Export to" command. The Options of the SAVEAS command are hidden away in this Windows standard dialog box under Tools in the SaveAs dialog box menu. Tricky...

BEWARE! Employing SAVEAS and changing the Tools>>Options automatically saves those changes to your CURRENT AutoCAD Windows profile. In other words, Civil 3D will save the next drawing file with these same Options (back to R14) in place until you change and use them again. Arrrgh!

Export to

"Export to" versions of the SAVEAS command that appear in Civil 3D menus or in the Ribbon encapsulate Options changes of the SAVEAS command into simple choices in lists.
There are Command line versions of the "Export to" commands available (see the Civil 3D help files).

Practically the "Export to" command will produce a picture of your Civil 3D data. Whether this is acceptable to the end user in terms of CAD Standards and AutoCAD object editing capability is subjective.

DGN Export

AutoCAD Civil 3D 2011 includes a DGNEXPORT command. This is one of those hidden wonders of 2011 that many people may have missed. The command is a subset of the AutoCAD Map 3D MapExport command. It will produce files in Microstation DGN V.7 and V.8 file formats. The DGNEXPORT command also produces attached external referenced drawings as DGN attachments too.

In general, the command will produce a reasonably good “picture” in DGN of the current state of your Civil 3D drawing. 

The DGNEXPORT command by itself may or may not produce acceptable DGN results from the end user's CAD standards or editing perspective for exactly the same reason that SaveAS AutoCAD.

Both DGNEXPORT commands require a DGN seed file (either 2D or 3D) in the “right” format. Usually, you will also have to tune the DGN export settings (stored in an ini file) to produce optimal results. Text tuning, Linetype, and Colors may also be optimized in the external Mapping Setting file.

Block to Cell rename AutoCAD scripts and a Layer to Level translation scripts or mapping setting tables also improve the acceptability of the DGNEXPORT results significantly.

Since AutoCAD Civil 3D is based on AutoCAD Map 3D, you also have the full MapExport command available which will output DGN file formats. MapExport employs the same ini file format as the DGNEXPORT command. MapExport will also produce files in a number of other formats (see the Map 3D help files for details). Map 3D also includes a BULK export capability to convert folders of drawings to other formats en mass. Therefore, BULK export is something to look into if you have entire project plan sets to punch out to DGN all the time.

It's my experience that publishing out to ACAD first and then out to DGN (unless they just need the picture) works as a better method to produce acceptable editable results.

Practice Makes Dumb More Perfect

You wouldn't wait until deliverable day to plot your Sheet Set for the first time would you? Dumb it Down is only another publish process. In a few passes you can become a wiz at it. You can save yourself and your organization a ton of man-hours too. That might be a good reason to keep you around. I'm just saying,  "More is Possible".

A few days ago I posted about the use of Light and Dark Backgrounds in Civil 3D.

This following interesting factoids about color publishing of exhibits and the other ACAD palette particulars came as a comment to that post. But comments to blogs do not always get always get read.

Another note: the default profile for Civil 3D 2011 employs a really interested background color in the light of the following information. Things change for reasons unknown. It helps to watch your back, revise your habits, or pull out your hair.

More on Color and Background in Civil 3D

Here is the full comment from Michael Partenheimer (Mike also reviewed the Jump in the AEC Edge last year!). 

Plan on plotting a color exhibit? Do you use a WYSIWYG color plot system? Then the Light Meat/Dark Meat background will present a challenge. That's because your WYSIWYG system is actually WYSIWTSSWKWAG (what you see isn't what they see so who knows what anyone gets!)

When your Model Space background is set to BLACK (or near black), it uses the dark background palette. The threshold appears to be 30,30,30 as the darkest background with the “light background” palette. A setting of 29,29,29 switches to the “dark background” palette.

So… For uniform color exhibits, all project users have to set their AutoCAD configuration to one or the other; either a “dark background” (0,0,0 through 29,29,29) or to a “light background” (30,30,30 and above).

It looks like the personal preference “I prefer black” can’t be permitted in a unform color "WYSIWYG" plot environment.

Need I say More!
A lucid (enlightening) comment!
Thank you for this Mike - TT