Weighing the Value of Import vs. Open

Let’s consider the user interface for 3D modeling systems. Aside from the fact that we’re still using a floppy disk as the icon (a format that, I think we can safely say, is dead), there are a few curiosities associated with Opening, Saving and Importing data files.

I think we’re all aware of what that skeuomorphic Save icon actually does. You edit the current session, you want to store your work so far, so you hit save. Job done. The file is written to disk and it’s all safe and sound. But when you consider the opposite direction (when you’re bringing data into your modeling system), the story isn’t quite as clear cut.

Let’s look at what happens when you use File Open. Essentially, this loads in native data files, chock full of the latest and greatest iteration of your geometry. It’ll rip through the construction history (assuming you’re using traditional history based modeling), reconstruct the geometry, build up the part in question and present it neatly and tidily on screen — ready for action.

If you’re loading an assembly, it loads the assembly file, then works through any parts that are referenced, rebuilding those and again, bringing it all together on screen. If you’re using lightweight assembly tools, it’ll load the graphics of the parts, the assembly structure and, again, show you what you’ve got. Then, when you need to edit specific parts, the system looks back for the construction history and pulls the full data in.

But when you use File Import, something altogether less coordinated and structured happens.

File Import, when stripped back, gives you tools to locate a third party set of geometry (think, IGES, STEP or native files from another system). You dig through your file structure, locate the file and hit OK. Then, the system parses that file. It uses data translation technology to read through the format, find the references it needs and starts to build the geometry. Typically, this is done in an unintelligent manner.

[Ed – another issue is having to repair converted geometry – a recent study showed that 49% of today’s engineers spend at least 4 hours a week fixing imported geometry.]

It’s not reading the construction history and rebuilding the part (as it would with a native model), but rather, converting it into a geometric model that will be held in your 3D modeling session. No intelligence, not much in the way of feature edibility but certainly an accurate representation of that part or assembly. Then you get to the point where you’re happy and you hit Save.

That process, at that very point in time, splits the connection between the original data (from your client, from your customer or supplier) and recreates it in an unintelligent native data file. As soon as you import, you’re doubling your data footprint. But it gets worse.

Now consider complex assemblies where you have a mix of native parts and imported geometry. You could have multiple imports in a single assembly, all of which have been referenced in some way. That could be inter part references that build features up to, for example, an actuator model imported from your supplier’s CAD system. Or, it could be that you have a sub-assembly that has multiple imported geometries within it.

None of these imported entities have any link back to the originating data. If there are changes made at any point, you’re, essentially, starting from scratch. A supplier releases a high performing product that you want to integrate into your part. Someone else in your organization specifies a lower cost product in one of those sub assemblies. Or the spec changes from the customer. All of these mean that you end up with a new data file to import again. That, my friends, as I’m sure you’re all aware, is a real pain.

A better way would to be to combine the two. Use File Open as you would with native data, but have it not only import and translate that geometry into a native format that’s usable, but also one that retains the links to that originating, imported geometry. That way, change requirements can be found, references updated and hopefully, geometry updated in the blink of an eye.

Surely that sounds like a more intelligent way to work?