Data translation is a critical technology, but it can also be a source of frustration. As with many other essential 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 sophisticated 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 accomplish this little magic, and the entire process goes almost entirely 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.
The Interview
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 moved into 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 on tooling cut to IGES surfaces due to faulty translation 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 software engineering, and I worked for a 3D software component supplier, Spatial, as an Application Engineer. I educated prospects and customers on the proper use and implementation of the ACIS kernel in C++. This leap from the trenches of manufacturing to the manufacturing software industry rewarded me with a well-rounded understanding of manufacturing’s needs as they relate to software providers. 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 on the manufacturing industry and applying my lessons and knowledge to perfect 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 in 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, specialized geometric algorithms are needed to properly map surface geometry from one format to another for downstream manufacturing. In purely visual terms, 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 areas such as precise measurements, mass property calculations, and procedural-based polygon output, 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, there 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 interests of these software firms to offer seamless interoperability with their competitors’ engineering apps, thereby losing potential revenue.
- Second, there 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 in their 3D modeling technology, but they are typically not experts in all of them, nor do they have the bandwidth to dedicate to 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 that companies want to include all manufacturing data in the same file with the 3D model. There is no commodity solution 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 in every design and product development process. What user 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 problem of obtaining high-quality STL files by enabling end users to receive multiple native CAD formats from customers, rather than receiving STL files directly. This approach eliminates the other main issue we routinely hear from RP users: low-quality STL files coming from their customers’ 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 for the RP bureau’s customers, as they no longer have to go through the additional steps of generating multiple STL files. In addition, STL PRO’s STL output is infinitely refineable, producing draft-quality all the way up to extreme-precision STL files. Our STL File Settings and procedural-based STL triangle generation consistently produce high-quality STL files from a solid.
TransMagic seems to be moving from a 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 built on a sophisticated plug-in architecture that enables a high level of flexibility in its 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, and NGRAIN can all use the same TransMagic translation core behind the scenes. This approach is helpful for companies that 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 within 10 minutes. It can easily be integrated with a PLM system or a custom in-house application to process jobs automatically. In fact, PTC Windchill users can now add a plug-in to their PLM that outputs to 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 working with a schedule largely 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 features and fixes as they are completed. With this philosophy, TransMagic is never more than 2 weeks away from releasing products. However, our typical release (or service pack) cycle every three months usually aligns pretty well with the adoption rates of new CAD versions.
Another unique methodology that TransMagic has adopted is licensing the “CAD engines” directly from the various CAD vendors. 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 support for the current version. 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, rather than 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 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 support ACIS or Parasolid natively, chances are those formats will yield the same results as a native CAD file. It’s a quantum leap from IGES and is 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’s 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 a single format, such as STEP or IGES. We advocate saving them in many formats. This way, if one or more of the archive formats become obsolete, you still have backups, including the native CAD files. 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 a 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 is that, unless the CAD system becomes defunct (which can happen), TransMagic will continue to support even the earliest versions of the CAD system, 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.
