Data translation is a critical technology and can be the source of many frustrations. As with many other important technologies, the better it works, the less visible it becomes. When we move a file from an external CAD system to our favorite design system, we are asking a complex algorithm to extract geometric data from a file and then translate it into a different proprietary file format. Most of the time the algorithm will successfully accomplish this little magic and the entire process goes almost completely unnoticed. Unless you get your software directly from Harry Potter, a software engineer has done all the hard work required for the magic to happen. If you get your translation software from TransMagic, the person behind the scenes creating and tuning the algorithms is Craig Dennis, TransMagic's CTO. With Craig's interview I'm trying to unveil some of that hidden magic and get Craig's take on the most common problems encountered in data translation.
Craig, can you tell us a bit about yourself and your professional activities?
I felt the pain with 3D and data exchange from the beginning of my career
My educational background is in Industrial Design and Mechanical Engineering. My career started as a Tool & Die Designer 17 years ago at a large machine shop doing tooling for the plastics packaging industry. I graduated to doing design engineering for the same industry. My CAD experience has always been in 3D starting with CADKEY, then SDRC I-DEAS and Pro/ENGINEER (although I actually learned to draw and perform projections on an actual drawing board! in college).
I felt the pain with 3D and data exchange from the beginning of my career. In those days all we had were IGES and STEP and really mainly just IGES. I’ve personally seen hundreds of thousands of dollars wasted in tooling that had been cut to the IGES surfaces resulting from faulty translation and this was in the plastics packaging industry. The waste in Automotive, Aerospace, Heavy Equipment, PowerGen, and on and on due to data translation issues is simply astronomical.
My career then transitioned to the software engineering world and I worked for a 3D software component supplier, Spatial, where I was an Application Engineer. I educated prospects and customers in the proper usage and implementation of the ACIS kernel using the C++ programming language. This leap from the trenches of the manufacturing industry to the manufacturing software industry rewarded me with a well rounded knowledge of the manufacturing industry needs as they pertain to the software provider. The single most lasting impression I had from those years was that data exchange was an even bigger issue than I realized as an end user.
In 2001 I became CTO and partner at TransMagic, Inc. with the goal of capitalizing on my unique broad-scope perspective of the manufacturing industry and applying my lessons and knowledge to perfecting 3D data exchange.
Data translation and data visualization are two markets with a certain overlap. Do you consider them as separate or do you believe they require different products and different approaches?
I consider [visualization & translation] separate technologies that belong together
I consider them separate technologies that belong together. In fact that was the exact premise of our first product at TransMagic, back in the days of “black box” CAD translators that output geometry you didn’t know was faulty until you tried to open it your CAD system. Who wouldn’t want to see their file before and after translation to do a quick visual validation if nothing else? In this way 3D visualization and data visualization address a similar need. The big difference comes when you need to perform downstream engineering operations on the translated data. For that you need real geometry, not triangles. There is a lot of important geometric information that is unavailable in triangulated models.
For the same reason, geometric data translation, validation and repair can only work on true geometry. In fact, this is a very difficult and intensive science unto itself. In geometric data translation highly sophisticated and specialized geometric algorithms are needed to properly map surface geometry from one format to another for the purposes of downstream manufacturing. In pure visualization these algorithms are simply not required.
Data translation applications will typically persist the 3D math data in memory (RAM) where it’s always accessible for highly precise calculations. As a result data translation apps will have a leg up on pure visualization apps in the areas of precise measurements, mass properties calculations and procedural-based polygon output such as used in high precision STL output.
In many software areas data translation is now considered a solved problem. Not so for CAD applications. What are the reasons moving data from one system to another is still a big issue?
At TransMagic, the problem of 3D data translation is largely solved
The reasons are multi-fold and each CAD vendor can likely cite one of these areas, if not publicly then internally, as the cause:
First, is the “single source” phenomenon where an engineering software provider develops applications (or add-ons) for the CAD, CAM & CAE specialties. For these companies it is in their best interest to interoperate seamlessly between their own apps so they can provide their customers with a complete software solution. As such, it is clearly NOT in the best interest of these software firms to offer seamless interoperability with their competitors engineering apps and thus lose potential revenue.
Second, is the complexity of 3D data exchange: Many engineering app developers are specialists in their own engineering space. Most of their development resources go to refining that specialty. 3D data exchange is a science and specialty unto itself. Sure, a sphere is a sphere, and a plane is a plane, but that view is overly simplistic. There are a myriad of geometric surface types and the mathematics for each differ greatly. Likewise, the technology behind each modeling kernel differs significantly. An engineering application developer might be an expert at their 3D modeling technology but they are typically not experts at all of them nor do they have the bandwidth to dedicate to the pursuit of perfecting 3D data translation.
Third, is version compatibility: Unlike some electronic formats, 3D geometric formats can and do change, constantly. Simply keeping up with these formats is a resource intensive pursuit.
Finally, 3D data translation is not a commodity. At TransMagic, Inc. (and I would wager many of our industry contemporaries would agree), the problem of 3D data translation is largely solved. The 3D interoperability market is getting more mature. TransMagic and our contemporaries have spent the better part of the last two decades perfecting this task. The proliferation of 3D data is very mature. The difference we’re seeing now is, companies want to include all manufacturing data in the same file with the 3D model. There is no commodity solution yet that ties all the different CAD systems and data types together. In the end, I believe it comes down to niche markets and qualities like ease, automation and affordability.
The 3D data translation needs of the engineering software community cannot be adequately addressed solely by the engineering software developers themselves. Instead a specialist software developer has emerged to address this need: The 3D Data Translation Expert…and the need for high quality 3D data translation has been met. It’s our mission to get the word out.
STL is consolidating its role as a key technology of every design and product development process. What user's problems and issues is your recent new product STL PRO addressing?
STL PRO addresses the common problems of getting good quality STL files by enabling the end user to receive multiple native CAD formats from customers vs. receiving STL files themselves
We have always offered STL output since our first release. Our STL PRO is a special package to address the specific needs of the Rapid Prototype (RP) market while keeping costs down. STL PRO addresses the common problems of getting good quality STL files by enabling the end user to receive multiple native CAD formats from customers vs. receiving STL files themselves. This approach eliminates the other main issue we routinely heard from RP users and that is: low quality STL files coming from their customer’s CAD systems. While most CAD systems can output STL files, their resolution is typically very limited. In many cases the highest resolution STL file from a CAD system is barely usable for a rough draft by most RP bureaus.
The STL PRO approach: Obtain native CAD files from your prospects and use STL PRO to generate the STL output. This is also a welcome change to the RP bureau’s customers as well as they don’t have to go through the additional steps of generating multiple STL files for the RP bureau. In addition STL PRO’s STL output is infinitely refineable to produce draft quality all the way up to extreme precision STL files. Our STL File Settings and procedural-based STL triangle generation always provide a high quality STL file from a solid.
TransMagic seems to move from the standalone approach to a more integrated plug-in architecture. What are the benefits for the end user and the implications of these changes? Is Data Translation going to become a technology hidden from the end user and embedded into software systems?
For anyone who uses the product, this means that they will experience consistent results using any application that is “Powered by TransMagic”
TransMagic is developed with a sophisticated plug-in architecture that allows a high level of flexibility in terms of product offerings. The TransMagic GUI, Inventor Add-Ins, SolidWorks Add-Ins and other partner applications from companies such as VX CAD/CAM, Dimensional Control Systems & NGRAIN, can all use the same TransMagic translation core behind the scene. This approach is helpful for companies who choose not to re-create the wheel and become translation experts. For our customers this means they can buy best-in-class products and there is no code duplication with an optimized product offering. For anyone who uses the product, this means that they will experience consistent results using any application that is “Powered by TransMagic”.
Our product interface is fully documented and callable by any scripting or programming language. Most users are up and running with it inside of 10 minutes. It can easily be hooked up to a PLM system or custom in-house application to process jobs automatically. In fact, now, PTC Windchill users can add a plug-in to their PLM that outputs any format, not just a PRT file (Powered by TransMagic, of course).
Our new Auto Repair Wizard makes about 100 checks before it gives the green light meaning the geometry has been validated. We automatically detect and resolve most translation issues during translation with this Wizard. The end user no longer needs to have expertise in 3D Data Translation. In most cases it is as simple as File->Open\File->Save when using TransMagic or an application Powered by TransMagic.
Working on Data Translation and Visualization software means to work with a schedule that is mainly defined by the new releases of the major CAD systems. How do you manage a development process in such a constrained context?
When many new CAD versions are released, we’re ready to go live simultaneously
We employ the Agile development philosophy and approach. This entails fully implementing, testing, and documenting feature and fixes as they are completed. With this philosophy TransMagic is never more than two weeks away from being able to release products. However, our typical cycle of a release (or service pack) every three months usually dovetails pretty well with the new CAD version adoption rates.
Another unique methodology that TransMagic has adopted is licensing the “CAD engines” from the various CAD vendors directly. We are very CAD-neutral and try to encourage our customers to use native file formats where possible. We go directly to the source and license the CAD engine from the developer. This provides three primary benefits: quality, performance and current version support. When many new CAD versions are released, we’re ready to go live simultaneously.
What are the most common mistakes of end users when moving data from one system or format to a different one?
[while moving CAD data] the most common mistake is using an IGES file
The most common mistake is using an IGES file when you could have used a native file or any other format. Our philosophy is to use native CAD parts or assemblies and when they are processed through TransMagic it’s a “mapping” from one kernel to another vs. a typical translation scenario such as IGES or STEP. We can readily handle IGES or STEP files, of course but the difference is that most contemporary CAD kernels are actually very high quality including ACIS and Parasolid. By accurately mapping geometry from one kernel to another, the process of using TransMagic is as simple as File->Open/File->Save.
Another very common mistake is that most people underestimate the power of using ACIS and Parasolid files for interoperability. When properly implemented, these two CAD kernels provide a very robust geometry engine for hundreds of engineering applications. If your source and target applications have native ACIS or Parasolid inside, chances are those formats are going to give you the same results as a native CAD file. It’s a quantum leap from IGES and typically better than STEP.
If you were a CAD manager and had to choose a file format for the long term archival of your company strategic data, which file format would you choose, and why?
[for the long term archival] use every format possible
This is an important question. Our recommendation is: Use Every Format Possible. For example, if you have a 50+ year archive requirement, don’t wager your whole future on one format such as STEP or IGES. We advocate saving them into many formats. This way if one or more of the archive formats becomes obsolete, you still have back-ups including the native CAD files themselves. Storage is now pennies per megabyte and getting cheaper all the time. This is an area where our TransMagic COMMAND interface becomes particularly valuable especially when integrated into an existing PLM/PDM system. For every PLM/PDM trigger, such as a design revision, the PLM/PDM system can make one single call to TransMagic and simultaneously produce any or all formats we support. Good future bets for archival in addition to the native CAD format itself would be: ACIS, Parasolid, JT (w/B-Rep), STEP and even IGES Solids (MSBO). The reason I mention the native CAD format commonly is that unless the CAD system becomes defunct (which can happen), TransMagic will continue to support even the earliest versions of the CAD systems and the native format may still be the first and best format to access years from now.
I would like to thank Craig for taking the time to answer my questions. If you have any questions for Craig or for Novedge, please leave a comment below and we will be glad to answer.
Franco Folini
STL PRO Demo Video
Comments