Standardizing 3D Modeling Nomenclature (MCAD Modeling Column)

How can you get disparate modeling packages to work together more efficiently?

How many times have you had the opportunity to peruse and use multiple 3D modeling software packages? I do it all the time because I write reviews. Not everyone gets that chance. (I love what I do.) I have read various surveys that say that many users — the majority, in fact — use more than one package to do their jobs. I do that too in my day job. I use four different software packages. What specifically those programs are is immaterial. What is relevant is that they are different in many ways.

When I consult with people about what software they should buy, they will invariably ask me the same question: "If all 3D modeling packages do basically the same thing, how do you decide what to buy?" I say they should buy into a company, because very few software companies actually sell software — they license it. It's very much like a one-time rental fee, like some tools at an auto parts store. You buy the software, but it's never fully yours — it always belongs to the software company. Read the agreement if you don't believe me. But when users license software they are forever after going to be linked to that company for things such as support, upgrades, translators, and legacy. So when you acquire software it's actually a long-term investment.

The question about choosing between those similar but different programs is very relevant. My usual answer lies in capabilities and interface.

The Challenge

All users are different and have different needs and preferences. Likewise, they are going to do things somewhat differently. Each 3D modeling package is different because it's written by multiple programmers. It's fairly easy to find software that'll do the things you want to do, but it's a little more challenging to find one that does it the way you want. Software capabilities are the easiest thing to enumerate on a box or Web site. But the interface is just as important — sometimes more so. Until you actually get your hands on the software and start using it, you won't develop a really good feel for how it does what it does.

Free downloads and trial periods are a godsend to users, and they should make as many of them as they can. To better understand the intricacies of interfaces, you can look at two very popular 3D modelers: SolidWorks and NX. They both use the same modeling kernel — Parasolid. Each is really good at creating high-quality models. But there are vast differences in how they accomplish that task. SolidWorks has its own way of presenting choices to its users that will have them up and running fast. NX has enormous power to model just about anything, but it's not just user interfaces and capabilities that challenge users.

If you've ever had to transfer data from one software package to another, you know how interesting things can get. Interoperability — or sharing data — is vital in today's manufacturing industry. You just can't get along without it. When it comes to translators, everyone is oh-so concerned with errors. You can understand why. How would you feel to have worked on a design for a long time and have it totally botched by seemingly random translation errors? One of the underlying reasons for those errors is a basic dilemma that's not easy to fix. That guy in the movie Cool Hand Luke said it best: "What we have here is a failure to communicate." Take, for instance, the venerable and indispensable Blend command.

One software package wants to call the smooth and tangent transition from one face to another on a solid a blend (figure 1). Another modeler wants to call the same thing a round. When I was in drafting school and everything was done by manual CAD — that is, the drafting board — it was called a fillet (this term is still used but now generally refers only to a 2D object). All are measured by radii, so some software packages call them that.

Figure 1. Question: What is this? Answer: Whatever sounds best to you.

Which term is right? The simple answer is . . . they all are. In this age of near-total freedom, you pretty much can call stuff anything you want. No software police are out there, standing in heroic poses, ready to slap the cuffs on you for something like that. You can call them thingamabobs if you want, but whatever you call them, I'd make sure your users know what to expect.

You want another example? Okay, coming right up! When you want to empty out a solid body and maintain given wall thicknesses, what command do you look for (figure 2)? In one program, you'd be looking for a hollow, in another, a shell. There probably are others, but I've made my point. Because there is no industrywide consensus as to what to call these things, the software companies can do as they please, and the users have to deal with it.

Figure 2. Whether you call it a hollow or a shell, the function is the same.

So why is it important what the software calls its functions? Because when it comes time to import data, your program wants to see what it's looking for. Whoever writes the translating code will have to create a finite list of what a particular function can be called. If the originating software calls that function something that isn't on the list that the importing software is checking, there will be a problem. And even if they call their functions the same things, they need to include the same information. Huh? How many ways can you think of to define a given shape?

The Answers?

Someone once told me that anyone could look smart if he or she could identify a problem, but it was the true genius that could come up with the answers. I would have to admit that I'm certainly not at the top end of that list. I can see the problems, but solutions are a bit more daunting. How do you fix what essentially isn't broken, just inconvenient? Industry standards? Maybe, but who decides what will be done — some kind of standards committee? Again, maybe. How would you enforce it? It's human nature that nobody likes to be told what to do. How many times have you heard someone (usually some kid) yell, "You're not the boss of me!" How do you tell a software company to adhere to standards?

I know this sounds like a rant. Maybe it is, but I know many users who are deeply concerned about this subject. There are as many ways of doing things as there are people to do them. Who's right? Is there even a wrong side? I see a lot of programs incorporating the look and feel of their near competitors today. NX has icons that I first saw in SolidWorks (though Siemens would deny that's where it got them; see figures 3 and 4 for a comparison). NX even changed the name of the Hollow command to Shell in the latest version.

Figure 3. SolidWorks was the first program I saw using these icons.

I think it's practically inevitable that a certain amount of homogenization will creep into the market. But until something happens to make it attractive to cooperate in the naming of functions, I think we users will have to wade through the mess and find what we want.

Figure 4. NX has the same icons. Coincidence? I think not!

Mike Hudspeth, IDSA, is an industrial designer, artist, and author based in St. Louis, Missouri.