I am here. You’ve missed me, eh? Well, I’ve put aside writing our two new books about the next release (an updated Mastering and a new title called Introducing), and my web training for just a few minutes to talk about something I’ve had on my mind for a long time.
The symptoms: Civil 3D had been working fine. You were modeling, building and shaping the land. Then BANG. Changing from one layout to another takes forever (such as 30 seconds or more). Regen times are slow. And plotting? Try sending a 20 sheet plan set to the plotter, go to the vending machine in the basement then back up to the 5th floor to chat up the receptionist for say, 3 hours (literally). Then your plot will appear. Or not.
Now, I need to note here that I am not talking about drawings that are full of junk and useless stuff and therefore a 1 acre site plan is a 20 meg file. I am talking about technically very well put together drawings that have been purged, cleaned and theoretically optimized. If you’d like some guidelines about what is meaningful drawing data vs. junk read my AU Paper on Large Surface Datasets.
What is happening here? Civil 3D object styles (like contours) and labels are regenerated for every view every time a regen is triggered- like changing layouts, splitting your screen, or plotting. If you have a lot of objects with detailed styles and/ or a lot of labels, that can add up to whole minutes for changes.
Why we are we just really seeing this now? Firms are finally using Civil 3D for production. We’ve had a few years to learn how to get our road models and our surfaces built, but we are finally taking advantage of those nifty dynamic labels. If we set up our drawings based on some old (or flawed) paradigms, we run into this ugly slowness. Most Civil 3D trainers wouldn’t have run into it because they don’t plot much, and certainly not whole sheet sets at a time.
It’s also been brought up with increasing frequency on the Autodesk Civil 3D discussion groups, such as: here, here, here, here, and here.
THE REGEN RULES
1. Your hardware isn’t going to help you.
2. The regen settings aren’t going to help you.
3. XREFing isn’t going to help you
4. Freezing layers isn’t going to help you (this one is up for debate)
5. Don’t stylize or label any more than you have to in any one drawing.
6. Keep viewports and layouts to a bare minimum in any one drawing.
7. Batch plotting and sheet set manager plotting might take awhile- no matter what you do.
1. Your hardware isn’t going to help you.
Of course you need the minimum spec. And you aren’t going to be able to work with 100 miles of road and a 1000 acre DEM done on a 0.5″ grid. But even small/normal datasets can run into this issue if the drawings are set up a certain way, and I don’t care if you add 40 gig of ram and a $4000 video card that is perfectly tuned. A 64 bit OS isn’t going to help you.
The labeling engine in the software is written in such a way that this regeneration happens no matter what you do, and throwing hardware Civil 3D is not going to do squat.
Still confused? Read my AU Paper on Large Surface Datasets, check out Nick and Dan’s AU class, and find another excuse to get your boss to buy you a water cooled, 64-bit screamer with 8 gig of ram.
2.The regen settings aren’t going to help you.
You can type LAYOUTREGENCTL in the command line until you are blue in the face. You can read the help file on LAYOUTREGENCTL until you actually understand what it says. You might change the setting and think that it has helped, only to discover 2 minutes later that it hasn’t. It isn’t going to help you here. You’ll just have to believe me. You won’t. You’ll try it. Then you’ll be back for rule #3.
**Something that does help is turing off objects in a viewport. However, you’d need to toggle back through everything before you plot.
3. XREFing isn’t going to help you
The most common cause of the most significant lags is a drawing organization model that many of us adopted early in the Civil 3D lifecycle because it was pretty close to the way we were currently working, and we could take advantage of some CAD management tools we were used to- like layer states, and sheet set manager. It was also a way we could avoid adopting Vault in the early days of Civil 3D 2007.
**Those of you that are feeling all proud because you use Vault/Data Shortcuts and don’t use the XREF method, hang on. If you use DREFs, but DREF big chunks and use your layouts to split things up, you could still be having problems.
Here is how it worked: we’d do most, if not all, of our modeling in one master base plan. We’d set up our styles to match our current forms of layer control and label in this model drawing. Then, we’d XREF this model into sheet drawings, where we would cut viewports and create layouts. While some people can get out of control with layouts, most people keep it around 5-10 layouts per drawing, with drawings broken up into “families” (all of the sanitary sheets in one, all of the grading sheets in another, etc.)
This causes problems because OBJECTS AND LABELS ARE REGENED ACROSS XREFs. It doesn’t matter if overlay or attach. It doesn’t matter what you do. Any model elements in the base plan will regenerate with every view change, every layout switch, plot.
Avoid XREFing like the plague. This means… you’re going to have to figure out something new. And you’re going to have to use data shortcuts or Vault to figure that out. Keep reading.
4. Freezing Layers isn’t going to help you
In my experience, even if you freeze every object and every label in your drawing, or that is XREFed in, you will still have lags. Maybe you’ve tried it and had different results. I can’t get a definitive answer on this one from the inside. You’ll have to mess with it, but I’ll bet it won’t make a difference. I did get some answers on this. Freezing the layer should help your performance, but if you have a big model or a lot of viewports, it may not make a perceptable difference. – DBP 3/25/08
So how do we fix this? How can we get our work done without waiting forever to switch between layouts? The next few rules may help.
5. Don’t stylize any more than you have to in one drawing.
I talk about this in my AU Paper on Large Surface Datasets with respect to large surfaces. Break up your drawings into meaningful model drawings where you create Civil 3D objects before pushing them into the Vault or using a datashortcut to pull bits and pieces into sheet drawings.
In those model drawings, put your styles on a diet. If you don’t need to see contours every 2 ft, make a style that shows a larger interval. If you don’t need to see your surface at all (i.e. you are using it as a daylight target and not much else), make a no-display style. Rethink the way you label. Are you still labeling that much just because it has to show up on a plan somewhere? Are you taking advantage of tooltips, quick profiles, and all of the other great things that Civil 3D has to offer? or are you just slapping 100s of labels in your model drawing because it was too much work in LDT to label something twice?
This
not
6. Keep viewports and layouts to a bare minimum in any one drawing.
This means: 1. You can’t have slow switching between tabs if you only have one tab in the drawing. It’s kind of like back in engineering school. It was easy to be the cutest girl in the room when you were the only girl in the room. It’s cheating, I know. But its what probably needs to be done. With sheet set manager to help with batch plotting, and Civil 3D styles to enforce layers, the damage should be minimal. But it is forcing us to change.
I hate this one. The CAD management power that we are abandoning with the multiple layout-per-drawing idea bothers me a lot. In Land Desktop, you could create that “family” drawing, apply a layer state in model space since all of the tabs would have similar layer appearance needs. That way, you’d only have to worry about layers once. You could almost “set it and forget it” if you set it up correctly.
So instead of XREFing or DREFing (data reference through shortcut or Vault) your ENTIRE set of alignments and profiles then using the sheets to cut the plan into chunks; DREF in only the roads that will show up on one plan, and make one sheet. So instead of one road plan with 10 layouts, you will have 10 plans. Get over it. I have. Use Sheet Set Manager to organize and make it easy to navigate between sheets.
7. Batch plotting and sheet set manager plotting might take awhile- no matter what you do.
The previous six rules have given you some ideas about how to control regeneration in individual drawings, but when you send all 10 of these drawings to the plotter, each layout will still be regenerated just the same if they were all in the same drawing. I don’t have a solution here. I’m open to suggestions. One idea that may help is making a DWF of the set, then plotting from the DWF. But that doesn’t help if you make any changes.
I make no claims that this is a perfect list. You still have work to do. You still have experiments to run. But if your regeneration time is unacceptable, try a few of these ideas. I’d love to hear if it helps.
***I recently wrote an update to this post that contains even more important information. Find it here: http://www.civil4d.com/2008/03/regen-rules-part-ii-more-under-the-hood/ ***DBP 3/25/08
Timely post. I just surfed over here while waiting for a regen with a switch from model to paperspace in a plan and profile sheet. The base grading drawing works fine….the plan sheet with 4 viewports is excruciating.
Thanks for the tips.
Dana, it seems all signs point to limiting labels to minimum.
Unfortunately I’m having a hard time wrapping my mind around this.
I’ve settled on somehow xref’ing labels only into the production drawing that needs them.
This is going to throw a wrench into an already complex dref/xref structure.
I’m going to have to play around with that.
I don’t want to get into the problem of labeling drefs twice, for instance, contours.
Let’s say I have an existing surface with 300 contour labels.
Those same 300 labels need to show up in all my plan view model spaces.
It seems I won’t gain speed by re-labeling drefs versus xref’ing becuase I’ll still have 300 labels. Whether they’re xref’d or manually recreated for each dref won’t matter.
So somehow I rely on drefs when I just need to show objects and xrefs when I want to duplicate labels in multiple dwg’s. I’ll have to re-work our typical project flowchart, but I can start to see this in action.
Any additional information you can offer would be great. Do ALL labels cause problems? Do you think profile views, bands, and profile labels also cause this slow down?
-Brad
Thanks Dana, good fodder for discussion. No_display styles are good for just about everything. Although 1 file, 1 sheet is heresy around these parts…
Can I just add this to the topic of “How to get rid of drawing crud that has to go!”
Step 1: PURGE
PURGE out all unnecessary blocks, layers, linetypes, materials, plot styles and text styles.
Step 2: -PURGE
Type -PURGE (or the shortcut -PU), then R for RegApps and don’t verify each name, or it’ll take forever. Note – I’ve had 1 drawing (rumored to be possessed by Beelzebub) that this did cause to fatal error, but everyone else loves it.
Begin the -PURGE process in the base files, or “X-” files, and especially any file from an outside source (before you x-ref them into other drawings), then work your way to the sheet files. RegApps come in with the x-ref like luggage and in-laws.
Step 3: -SCALELISTEDIT
Type -SCALELISTEDIT, then R (for Reset) and Y (for reset to default), then E (for exit). Make an ALIASEDIT for this command if it’s too long to type every time.
This should purge out all the XREF scales in your scale lists.
Step 4: AUDIT
Run an audit and fix errors after you’ve gotten rid of all of these other items.
Step 5: XREF
Get rid of any extra or unreferenced xref’s that are in your drawing that don’t need to be there.
I’ve cut more than 0.5 Meg out of most drawings by doing these.
God Speed, or at least faster speed.
While those things are important in general, they have nothing to do with this particular situation. You can have a very small drawing, a technically very clean drawing that contains a few heavily labeled and displayed Civil 3D objects and have 30 second to 2 minute regen times when switching from model space to a layout tab. Sometimes including a white screen semi-freeze or occasionally a fatal error for really intensive situations. If you can tolerate the switch between layout tabs, you are either a) creating references and labels in a way that minimizes the issue (kudos) or b) not pushing the software hard enough.
This is a topic that always causes debate – everybody has an opinion on what is the best thing to do. Autodesk has spelled it out pretty clearly that a good mixture of data refs and data refs should make things better. When this first started happening to us, we did some controlled hardware tests with a super-duper workstation we bought. See my blog here for results – http://civil3dbeatle.blogspot.com/2007/10/we-had-been-having-some-issues-with.html . For some reason nobody ever commented how funny the computer name was. Anyway, hardware was the last thing we tried and when that didn’t really work out we decided that we really needed to put more thought into how we organized our projects. So far so good with this approach and we haven’t had any major issues since we have put more emphasis on better data management. Good summary Dana and thanks for posting this on the discussion forums for all those folks to read.
Thanks, John. Yeah, I can’t get a definitive answer out of the ‘desk about what is happening under the hood here. All that I can confirm is that the entire model regens when views change, and the more visible elements, the longer it takes. They have their recommendations, but in all honesty, those recommendations are not made based on a lot of hard core production data. They are getting better- but they are often getting their information from the “public conversations”, such as this one.
Dana
Doing most of our large projects myself I generally always have all of the drawings as layouts in the one drawing. Which has resulted in drawings with typically 35 to 45 layouts. I have found switching layouts can be slow as you have discussed particularly when you want to review the drawings before the final print of the issue set.
To get around the issue I now save layerstate’s for each layout viewport as I have found when you apply the layout laystate while in modelspace you can apply the layerstate and type regen enter faster than you can switch layout tabs(even faster with a macro to do it). I know what you are thinking its quicker because the drawing setting scale is the same as the layout viewport scale. But try having a large drawing with two layouts at the same scale as the drawing setting scale. Now time how long it takes to jump between layouts then go to model space and restore one of the layout layerstates and regen. Now time how longer it takes to apply the other layout layerstate and type regen enter. I have just done in on a large job 20 mb 2 corridor 8 or so complex surfaces and it takes 10 seconds to jump layouts but only 6 seconds to restore the layerstate and type regen in modelspace. Definitely soon poor programming in the back ground at Autodesk. Run this scenerio by them and see if you can get some answers and improvements.
Regards
Justin Ralston
Senior Civil Engineer
Airey Consultants Limited
http://www.aireys.co.nz
Hi Dana. In my office’s experience, the more you can put on a “no display” style, the better it seems to perform. Our survey shots were our main culprit, which, we are (used to be) stored in our base dwg (non-design dwg), which is our “pretty picture” we xref into all of our sheets. Even when layers are frozen, they still have to be regen’d upon open/tab switching/sneezing, ect…, so we just put them on a no display style, so cad would not have to generate the text in the first place. I agree- I wish ‘Desk would put out a definative answer on this. But, like you have mentioned before about rethinking how you manage your data, that is what we have done and have not had any problems in the last handful of projects (all about 3 miles long roadways).
Good article Dana. All of the things you list help the problem, but why the heck can’t AutoDesk SOLVE the problem? In the grand scheme of things, a million point dataset, or humpteen labels sitting over 6 layouts isn’t THAT big of a deal. If we keep looking at how much better things are than they were with LDD, we still miss the fact that this has been a WIP for the past 5 years. They supposedly started from scratch with the Civil3D engine, and are just now realizing that they will need to start from scratch again to get it right? It seems to me that I spend more time trying to keep my data separated and in little chunks than I did just using the archaic LDD tools. At least everything fit nicely into one drawing for the most part. I’m just aggravated with the whole deal. As I get better and better at making this program work (thanks to a lot of reading what you guys write), I am having a hard time figuring out how I am going to teach other users all of these crazy workarounds. It has become a program of workarounds with nothing being straightforward unless you happen to be designing a 1 acre gas station or a straight (and I mean STRAIGHT) highway.
At least I learn alot from reading the NG’s and the Blogs. I’m pretty sure my less than anxious users will not do the same though.
Tim
I haven’t gotten around to trying this as I don’t have a suitable project set up to work with, but I wonder whether there would be any improvement in performance if the models were xref’d into paper space rather than using a viewport into model space. I don’t know the Autocad paradigm for regens in PS vs MS, but it may make a difference.
I went ahead and tried this with an old LDT drawing that didn’t have any C3D styles or labels applied. I made a drawing with XREF’s in the PS layouts and one with viewports in the layouts. It turns out that ACAD regens the viewports much faster than a clipped XREF in PS. Put that one in the “Don’t do this” archive (interestingly the XREF in PS approach is demonstrated in Sheet Set Manager tutorials).
As far as I have been told, or been able to figure out, the entire model and all labels regen with view changes, including profiles and profile views.
I thought that I had this great idea that I would update our hydrology narratives to work directly in Civil3D. That way, I could just use the things I learned from Dana at AU, and have a hydrology narrative that basically created itself as I picked things and input calculations from Hydraflow. The problem with that great idea is that in a large Hydro study I have 30-40 watersheds. This is going to add up to 15-20 layout pages and a whole lot of Civil3D labels.
My aggravation with this mess is that it is right on the edge of making my life easier, but I can’t get to where I need to be because no machine or graphics card on the planet is going to fix these problems. The drawing I created to do this takes 10 minutes to do a save. Not acceptable.
Even though I may be able to think up a lot of workarounds by putting things on “No display”, and doing the ole’ “switch-a-roo” for this or that, I am left knowing that trying to explain all the nuances to other users is just going to get a smile and a, “Now, how is this better?” It is good for me to figure out all of this and get a better understanding of the underlying workings of Civil3D, but how far away are we from a product that really works? And I mean works like an Excel type of program where things are just straight forward, type and go. It is still a “Power User” program, and the problem with that is that most offices only really have 1 or 2 “Power Users”, and everyone else just wants to come to work and not get a headache.
Tim
Did I miss something? (Highly possible…)
Xrefs = Bad; Drefs = also Bad.
Um, OK. So then, what is the recommended alternative if we need to share project data (which of course we do)? Just not using a lot of labels? But that doesn’t address the xref vs dref issue.
why are drefs bad? just dref in only what you need. The idea is that if you can label one alignment instead of 20 that you’ll be better off.
Oh – that is what I missed! I read the whole thing twice and misunderstood point 3 both times.
So I guess to clarify my misunderstanding, the info to take away is to break the design into smaller manageable files, then just dref those files accordingly per individual sheet; one per dwg file.
Makes sense to me.
The approach seems similar to my background (which was not civil) in working on an industrial facility: each discipline – arch, mech, elec, struc, I&C, HVAC, civil, fire control, etc. – creates their own individual dwgs, and everyone else just references in what they need to see to do their design, and the deliverable sheets then just reference in the relevant pieces for that sheet, based on that sheet’s location and sheet type.
We would often even break each facility into sub-quadrants and specific systems to further the ability to have multiple designers work on the same facility at one time, which is one thing you can’t do if everything is in one dwg file. It occasionally makes for a LOT of references, but that is what file naming conventions are for. And everyone always hated that the civil designers would just put everything into one big file, because it would really bog down anything else that touched it. Now I am that civil designer…
I got to say that I love your posts and your book Dana and with the current state of Civil 3D I believe you are entirely right about what needs to be done to eleviate regen problems. The first two large projects we completed had serious problems in this area. Hardware does help a bit but in the end it comes down to managing data in a way that Civil3D can handle better at the moment. What dissapoints me is the lack of Autodesk management to see the future with this product. We have new software as of now that has no parrallelism for multiple processors and is not capable of using a 64 bit OS. Throwing more hardware at the problem right now doesn’t make a difference because processors are mhz limited anymore… intel\amd are adding cores instead of mhz and Civil 3D will only and always use just 1 in it’s current state. Imagin if they used all four processors to regenerate labels and produce the regen in a quad core machine. Civil 3D is not a program that needs to be limited to one thread. Autodesk has totally missed the last ten years of computer development (Look at Adobe or others that are lightyears into multiple processor technology). Instead of coding better software they are making us use techniques that go back to post AutoCAD 2000. Makes me frustrated when we pay 6k a license… grrr.
i’ve gotten some feedback from the label developer that is helping me work up some additional recommendations. i have something to finish today, but if I get it done, i will post later.
I need to write this up formally, but the developer is telling me that freezing the layer that the label/object is on (either the label object layer or style layer) will break the “call” and make it so that frozen labels/objects do NOT regen upon view changes, etc. I still need to do some testing, but she said that we might see increased performance if we froze all objects outside of the extents of a viewport. For example, if you are only showing a profile view in a viewport, do dig into that vp and freeze all of your roads, surfaces, pipes, etc. that are outside of the view. That sounds icky to me unless we come up with some great layer management ideas or perhaps the use of named views.
While not directly on topic your comment about named views brings up a wish item that I think we Civil folks could really use, namely a way to create what I’ll call a viewport style wherein we could define a set of viewport settings and save them as a style that can be applied to multiple viewports and all viewports with a common style could be updated by modifying the style. It would sure help in this scenario and in civil design layouts in general. It didn’t get anywhere in the AUGI wish list but perhaps it would if more people promoted the concept.
Neil,
What exactly would be stored in your viewport style?
I ask because the only things I can think of to be stored would be scale, rotation (view twist/UCS), and layer settings. Since all of these are already available as stored settings (scale/rotation as a named viewport, layers as a layer state) what need would there be for a viewport style?
What am I missing?
How about Xref Clip for “Plan” sections of Plan and Profiles?
Josh, have you ever had to go through a bunch of layouts and turn off layers that showed up in a XREF after you configred your viewports? Maybe you had to do it more than once because you missed something. Then there is the new capabilities in ACAD 2008 to configure viewport layer settings independently. Think of how much easier it would be to just set up a style that has all those settings and apply it to the viewports that need to have the same settings, regard;ess of which layouot they are in. If something needs to be changed in all those viewports you would only have to modify the style and they would all be updated..no stepping though and waiting for re-gens. Far better than trying to do it with layer states. With ACAD 2008 you could also customize the linetypes and colors in addition to visibility so you could have a viewport style for Water network and one for P&P, grading, etc. Hopefully you get the idea.
There is definitely some potential for automation.
Thanks for the idea Neil.
Anyone else agree that this is a need??
[…] few weeks ago I wrote a post called REGEN Rules that presented some ideas for datasharing and layout creation that would (hopefully) mitigate the […]