Wednesday, August 30, 2006

Barriers to model exchange why is it so difficult to send data from one CAD system to another

Wouldn't it be nice if we all used the same MCAD application--and that it had all of the bells and whistles found in each application available today? Everyone could send each other 3D models without worrying about losing data. Everyone could collaborate using the original master model. Everyone could benefit from each other's design intent. Wouldn't that be nice?

Ok, you can wake up now! If you're one of those rare individuals who exchanges 3D data only with partners that have your same system, you can go back to sleep. For the rest of us, this month's topic, model exchange, is one I enjoy talking about because it causes so much aggravation for MCAD operators and administrators. I don't like to see us aggravated, but I do like to take every opportunity to point out the problem and dig for solutions.

Q: Why has there been such a problem moving 3D CAD data from one system to another?

A: I think it's a question of differing objectives on the part of the people who create and use 3D data. For example, industrial designers are typically consumed with issues such as design aesthetics or ergonomics and have little or no concern for production and part manufacturability. Industrial designers are artists intent on creating beautiful, marketable products, and as artists don't want to be concerned with issues such as tolerances.

The downstream moldmaker faces different challenges. Moldmakers must take a 3D part and create a whole new set of 3D models. Their core objectives revolve around creating efficient molds that produce thousands of parts that are in tolerance.

While the moldmaker worries about draft, core and cavity separation, and parting lines, a CNC programmer is more worried about being able to manufacture the resulting 3D parts. Often, manufacturing models lack suitable features for automatic tool selection, or 3D models don't meet tolerance standards.

Q: What are some of the difficulties that developers have overcome (or addressed) in recent years?

A: To meet the needs of end-to-end customers (designers, moldmakers, and CNC programmers alike), application developers have taken a proactive stance by developing extensive suites of healing tools for working with 3D models. This enables all users to work with and heal imprecise data.

The hybrid-modeling environment is one way that users can overcome some of the difficulties in model exchange. Typically, solid modelers require a closed solid to perform most 3D functions such as moldmaking and manufacturing. Hybrid modelers let you work with open solids, thereby dramatically increasing their flexibility and efficiency.

Another important translation development is ongoing improvements in data recognition and fault tolerance. Although geometry can be automatically healed as it is read in, that occurs only after the data format is repaired.

Q: What are current model translation trends from the perspective of CAD software developers?

A: There seems to be a movement to direct translation. Customers are shackled to a CAD system if they can't convert their part libraries to another system with a high degree of accuracy. This conversion involves geometric accuracy. Users want full feature transfers, undo and redo, history, annotations, and so on. With a direct translator, the customer has the best chance of converting data.

Q: What are the challenges yet to be overcome?

A: The industry needs better tools to translate features, design history, and intent. A few developers are attempting to fill the gap, but there's still a long way to go.

Q: What nontraditional methods are being used to exchange 3D modeling data?

A: There seems to be an active resurgence and interest in reverse engineering. We've experienced growing interest in our ScanShape tools, especially from companies that want to recreate 3D digital models from parts that weren't designed using CAD technology. An additional reverse-engineering trend is the high-tech world of 3D printing using yet another neutral file format, STL.