Technology Solutions to Simplify 3D Application Development
|
Search |
|
|
|
 |
|||
|
InteroperabilityPosts containing interoperability 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:
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 
Posted: July 6th, 2012 |
I recently found a really interesting technical article describing the difference between semantic and visual PMI. First some background . . . For the first few years that Spatial 3D InterOp offered PMI, there was one topic that really confused me: semantic PMI. What did the term semantic mean when applied to dimensioning? Actually my lack of understanding went deeper than that, what was the big deal about dimensioning and PMI anyway? (I'm no ME) -- I had to do some catch up to understand what on earth a geomtol was and why it was important. Prior to then, I thought PMI was just +/- some tolerance on the length of an edge, right? So I learned that it is more complicated than that and that there wasn't even a standard way of representing PMI. In fact, not only wasn't there a standard, but there wasn't even a common ideology on the structure. There have historically been two competing ideologies: semantic and graphical. Spatial started offering semantic initially to meet the automation needs of our CAM and measurement customers, while graphical PMI was more popular at the time. In more recent years, these two ideologies are starting to merge together, as we'll show in upcoming releases (sorry for the marketing, hard to talk about this topic without discussing our product line). So about the article . . . As Fischer nicely explains, "semantic data captures the meaning" whereas graphical is presented "for human consumption." In computer science terms, you get a class structure in memory which represents the PMI , providing access to its specifics, such as geometric tolerance type or magnitude through a class method or property - this enables automatic creation of machine paths and test plans. The article also discusses some of the inherent difficulties with semantic PMI, which we struggle with too, by the way, stemming from the lack of a common standard. An example of this that we've seen is in ProE/Creo, which allows you to put tolerances on driving dimensions. Driving dimensions are the various dimensions defining the features which ultimately result in the final solid, but they may not necessarily be dimensions that are meaningful to the final solid. See the example below in which I've created a geomtol between the solid and a construction plane. Ok, this is a very simple example of a feature, but the significant point is still illustrated: unless you understand the relationship between that plane and the solid (i.e. the feature, i.e. ProE's "secret sauce"), that dimension and geomtol are meaningless. This is an inherently different style of tolerancing than what is used in either UG/NX or V5, which makes standardizing the data between them difficult.
Anyway, to make a long story short, in my quest to understand a topic that confused me, I found out that there is general confusion and inconsistency on the topic . . . but people are working on it.
Posted: February 9th, 2012 |
Tags:
From: MARKSON Howie Seems like we all have enough ideas to write an interesting blog. I have a great idea what our first post should be. Let's get started! From: ALPINE John As we just announced CGM, why not have Gregg start out and talk about what’s different in CGM than ACIS from a technical standpoint? From: SLOAN John From: TATTERSON Kevin I’m sure I could come up with stuff. I don’t know much about blogging, but from what I can tell, a blog entry doesn’t necessarily have to bring closure – it just has to put an opinion on a subject to get people thinking. And it can’t take more than a couple minutes to read – the best ones are relatively short. I’d put something crazy out there like “people or process – which matters most?” Stir the conventional wisdom pot a bit. What does John think? From: OETTING Gregg I’ll bet Kevin has an opinion on this Blog. He has an opinion on everything. From: KENNY Stefanie Anyway, I like this idea. From me personally, I’d like to discuss Interoperability and some of the difficulties surrounding it. I’d also like to draw on my QA background to talk about testing and how modern ideas on testing from other domains, like web application development, can be applied to CAD and 3D. We could even go further with this idea and discuss a range of software practices and tools and how they apply to the engineering software domain, for instance, what have been some of our successes (and failures) in applying Agile processes. What are you thinking for the first entry? I think it should be quite profound… set the tone for the rest of the blog, hint at topics to come and perhaps discuss one particular topic of utmost importance, including some ground-breaking insights. You know… show how Really Smart we are. Hmm, I’m coming up a little short on ground-breaking insights today, so I think Gregg should do the first one. From: MARKSON Howie It seems like we should start a really cool blog. Everyone else is doing it and we certainly are at least as interesting as everyone else. Maybe more so, if you consider we live in Colorado. Plus we know a lot about developing engineering software and we talk with other developers, our customers, everyday. So what do you think? Anybody have any suggestions on what we could talk about in our blog?
Posted: November 9th, 2010 |
|
|
|
