Do You Need Modeling Standards? (MCAD Modeling Column)

Simple guidelines can help ensure quality models and successful downstream applications.

Maybe I'm dating myself here, but I remember reading a lot of comic books as a kid. When I finished the exciting story (and was still disappointed because it was a multi-parter), I would usually leaf through the advertisements in the back. You know what I'm talking about — x-ray glasses (guaranteed to work) and Sea Monkeys. Nestled among those ads was a small black-and-white comic about this skinny guy who was doing his best to pick up a bikini-clad babe. He would do pretty well until some big muscular guy came up, kicked sand in his face, and took the girl. The skinny guy went out and bought an exercise book (the real reason for the ad) and punched out the bully, winning forever the affections of his paramour.

All three characters in the comic could use some improvement. If the bully had learned to play nice with others, the ad would have been unnecessary. The skinny guy could've gone along his merry way without fear or shame. Of course, if the skinny guy had acquired and maintained good physical and social skills beforehand, the situation might not have occurred in the first place. I guess the real winner of the story is the girl — who, it appears, just wanted the strongest guy. If she had cared for more than muscle, the whole story would've happened differently.

What's a Body To Do?

Do you see where I'm going with this? People seem to fall into doing whatever they are used to doing. They get comfortable with having things their way — so much so that they can become hard to work with.

How many times have you complained that one of your coworkers creates files that aren't up to snuff? You don't have the authority to tell that person how to model unless you're the boss. But if you have some form of corporate or departmental standards, everyone has to adhere to them. The downside of the equation is that those coworkers are going to expect you to follow the rules too. It goes both ways.

Most big companies have a CAD manager who will create and administer a set of standards for the company. The problem comes when employees don't adhere to those standards. Smaller companies, however, might not even have a CAD manager. In those situations, it's up to the designers to set their own standards. Of course, they don't need to be complex. Standards just need to state what you are putting where. And they need to be practiced.

Write It Down

It almost goes without saying that good modeling habits make for better cooperation. If designers model without regard for anything but themselves, they invariably will fall into some bad habits. When the next person comes along and wants to use those models, he or she will have a hard time. So what do you do? One solution is to establish written standards. Standards are a list of things you can expect to find in every file, every time. I know, no one likes to adhere to the letter of the law, but think about it for a bit. Things that are written down aren't forgotten as easily. They provide a concrete yardstick for measuring whether something is good or bad. Of course, they can be abused, but I'm going to assume for the sake of argument that won't happen.

Get together with a few of your coworkers and come up with some ideas for things you'd like to see enforced. If you have problems agreeing, then divide the ideas into two groups: Must Do and Would Be Nice. More than likely, none of the ideas is going to be downright horrible (although there are exceptions from time to time). The list you come up with may not seem like much, but it's a good start. If nothing else, you can print the list and give it to new employees.

I will warn you that the more people you get involved in this process, the longer it'll take. Instead of jumping right to a company-wide, all-encompassing list of standards, I would start with your own department, an area you should know well. Besides, when you bring up the subject of standards, people are going to ask several questions. They'll ask why they're needed. They'll want to know what it's going to cost or save (both in money and time). And they're going to ask if you plan to follow those suggestions yourself. If you can pull a sheet off your cubicle wall and hand it to them with the comment that you wouldn't suggest what you hadn't already worked out, you'll be well ahead of the game.

Another advantage of having written standards is that they can serve as orientation materials for new employees. Having a printed list of guidelines regarding how to set up a model will speed the training process, provide a reference for questions that come up in the future, and offer insight into how your office runs. Post your modeling standards at every workstation so they can be referenced easily.

Organize!

One of the best ways to make life easier is to organize. Organization is the very life's breath of modeling standards. Without proper organization, your models will quickly become quite a mess. You'd be surprised how many people ignore organization when modeling. For example, take layers. Do you give descriptive names for your layers (figure 1) that make it easier for others to see what is where in your files? No? Why not? This one little thing can be so helpful. If you are using a parametric modeler, do you name your features? Believe me, "Extrude 437" isn't terribly useful when you're trying to find a particular feature to edit in a coworker's drawing. By naming your features, you leave a road map for those who will work on your models in the future.

Figure 1. Every modeling program has a way to deal with its layers. Some use numbers, and others assign names. Most let users rename layers any way they want.

Here's another good question: Do you have to name every feature? If you did, the problem then would be the amount of time it would take. If there's a good reason for it, do it. If not, organize it in a different way. If you keep your features together with what they interact, you can get away with just naming your sketches (figure 2). In other words, if you keep your Extrude feature next to its Unite and you put the Blend on next, then by naming the Extrude "Upper Tab" it is going to be easier for someone else to find that feature and edit what's associated with it.

Figure 2. This feature tree shows how I ve named my sketches to be easily identified. If I wanted to go one step further, I could name each and every feature.

You can organize your models many ways. Think about how you build. Think about what you like. Think about what you dislike. Get creative. Go on, you can do it. No matter which approach you take, when you determine how to organize your models, you are building the foundation for your standards-writing process.

Downstream Success

One really important reason for standards is to create quality models that will stand up during downstream applications. By having models that are easy to understand and edit, you not only build in intelligence but do it in such a way that it will be easier to access. Anyone who uses the model downstream will have a head start in knowing where the things are supposed to be.

What kinds of downstream applications will benefit from quality modeling? Analysis is one. Finite-element analysis (FEA, figure 3) is a growing and important downstream application. Bad models undoubtedly will result in bad FEA. If you model sloppily, you'll end up with tiny imperfections — such as open gaps or leftover projections — that the FEA program will either explode on or have to fix. Your modeling program may have tolerances that are loose enough to allow a modeling error to stand out, but your FEA program may have tight enough tolerances that it chokes on the error. You also need good models for good simulation. A funky model will yield unexpected results. A model that has a modeling error usually will cause problems with all its uses.

Figure 3. A bad model will result in bad FEA. A good model, supported by consistent standards, will give you good results.

How about CAM (computer-aided machining)? If your models freak out, you're liable to have major problems. A sloppy model invariably will have unintended features — repairs done to cover up problems that you couldn't solve. When you go to a program's tool paths, the computer will see these features even if you want to ignore them.

The Answer Is Obvious

Modeling standards? Yes, you do need them. If you put good rules in place and adhere to them, you will have consistently good results and downstream success. And that's what you want, isn't it?