As I was sitting here trying to come up with a topic for this post, I was thinking that while I have a million things going on, none of them are post-worthy in and of themselves, and I'm sure nobody wants to read a general post about being busy. Then I had an epiphany, there is something bigger going on that ties it all together.
3D InterOp is going through a paradigm shift.
The longstanding objective of InterOp has been to convert CAD data from 1 format to another while retaining the highest quality. The interface was originally designed with this very simple objective in mind -- give the user a small, clean interface, independent of input or output format.
This all works pretty well, the interface is certainly easy to use. When we added the CGM modeler though, it presented us with some new challenges. Being newly componentized, CGM doesn't have all of the somewhat clunky add-ons that we've put into ACIS to support additional types of incoming data, for instance product structure and PMI. We were faced with a question, do we add these in the same way as we've done in the past so that we can translate all data into 1 format, even when it isn't very clean? The question was particularly relevant because we knew we'd be adding graphical data soon, which didn't have anywhere to go in either ACIS or CGM.
This is where we come to our paradigm shift. We found ourselves asking how people will really use the data and how do we modify the interface with this in mind?
For geometry, this part always came for free. You convert files into a modeler, which then provides a full range of APIs for doing something with the new data - query it, change it, whatever you want. As long as the data is usable by the modeler, InterOp's job is done.
So we had mostly avoided this question, but faced with adding new types of data to both CGM and ACIS, we had to truly address it. Even if we add all new data, like graphical data, into the modeler, we have to make sure there are APIs that allow the user to get it back out and use it. That starts to make things very complicated.
We decided to go for a cleaner approach that was very focused on making sure people had a targeted way of using every type of incoming data. Through this examination, we came to a few key realizations:
- The objective of 3D InterOp is not simply to convert from one format to another, but rather to query the source document for different "containers" of data, converting only when necessary.
- Rather than one size fits all, the interfaces for reading such containers should vary with their complexity and downstream use.
- If the data is very simple, then a direct API is a great way to access the data, so, for instance, we've added new APIs for extracting product structure and graphical data in memory. This means that applications can put the data directly into their internal representation without any file interaction, saving steps and time. Here the interface is a little more involved because the user is exposed to more.
- If the data is more complex, the obvious case being geometry, then you need to put it into something that knows how to represent it and that offers tools for operating on it (the modeler). So here, InterOp's primary responsibility is getting the data into the modeler in the way it expects so it is ready for downstream usage. The user interface for this is very simple because all the work goes on behind the scenes.
- There will also be meta data that connects all the different containers together, e.g. attributes and PMI. We're working on figuring out this part.
This is a really cool way of looking at things because it allows us to expand the InterOp interface to handle new data in a concise and flexible way. That's the big picture - which means that in my smaller picture, helping to roll this all out to our customers, there is certainly a lot going on.
Below is an Example of Extracting a Single Instance from a Product Structure
No Comments Yet
Let us know what you think