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.
- 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.
Below is an Example of Extracting a Single Instance from a Product Structure