NOVEDGE blog

Interview with Rafael del Molino, TDM Solutions CEO (RhinoGold)

Something must be right for jewelry design in Spain. Not only are several jewelry designers active in Spain, but Spain is also the source of some of the best and most popular software tools for jewelry design. Among those tools RhinoGold stands out as a reference point, setting standards both for features and customer support. The manufacturer of RhinoGold is TDM Solutions, a young company founded and led by Rafael del Molino. I interviewed Rafael to get a better idea of how RhinoGold is developed and sold all over the world.

Rafael, can you tell us a bit about yourself and your company?

TDM is working over 25 countries with more than 75 resellers

About myself. Since I was in the university, I was working in engineering stuff, specializing in the automobile industry. Sometime later, I found TDM Solutions to implement my CAD/CAM knowledge in companies. Since there, TDM Solutions has been an official distributor, training center and developers of Rhino-based applications.
Nowadays TDM is working over 25 countries with more than 75 resellers. Developer of design and manufacturing applications, enhancing RhinoGold, and other Rhino plug-in such as RhinoMold, RhinoNest and RhinoShoe.

What are the major reasons jewelry designers choose RhinoGold?

the designer finds confidence and security in our software and therefore chooses it

It is no secret that a product works in a combination of factors. First of all, without any doubt, we must offer a quality product. A product that truly meets the customer and helps/improves their work.
But, this is not the only requirement. This is not about selling a quality product and get the profits. We must provide a post-service. From TDM Solutions we provide personalized support by responding to their problems and concerns within 48 hours, via our forum, via e-mail, phone or connecting to our customer’s computer directly. In addition, we offer this service even before the customer buys the product, it means, when designer are using our 30-day evaluation version from our website.
Upon these basis, the designer /client finds confidence and security in our software and therefore chooses it.

What are the benefits for a company such as TDM to create software programs as plug-ins for Rhino rather than standalone applications?

our client can start working with our software even the first day

Rhino is a software with thousands and thousands of users, and for many areas. Creating plug-ins allows us to specify, and thus improve the possibilities of Rhino in each sector. Furthermore, the learning time of our software it’s shorter, understanding that the buyer already know (or want to know) how to use Rhino. Our client can start working with our software even the first day.
Nowadays, RhinoGold can be considered as a standalone software, having its own interface and allowing the designer to have only the jewelry tools.

Which new technologies from the Rhino platform (e.g. GrassHopper, T-Splines, etc.) will benefit TDM products and their users?

we have had some conversations to implement some of our products in other platforms

Well, right now, RhinoNest and GrassHopper are working together with a program called D.O.F., for architecture… very interesting. Furthermore, we have had some conversations to implement some of our products in other platforms, and we are working on it. So far, I cannot talk that much about that, we will see in the next months how it runs.

In your experience what are the major differences between the US and the European market for your products?

our customers are designers, so, they are different one from the other

honestly, our customers are designers, so, they are different one from the other. They are creative, doesn’t matter if it’s European or American or Asian. Maybe some prefer rings than bracelets, and others a specific pendant, but, all they need different tools, or at least, they use the tools in different ways.
Fortunately, RhinoGold offer such a vast variety of tools, so, so far, we have success in all the markets. Hopefully!

How do you involve and engage the jewelry designer community with the product development of new releases?

using RhinoGold, designers can spend more time in the creative part of the work

Goldsmiths must adapt to new technologies to be more efficient and effective on their business (for example, offering a better – faster and clearer – service to their customers). There are other sectors that some years ago nobody thought about the possibility to implement a software on the business, and now, those sectors cannot run without the software.
We firmly think that using RhinoGold, designers can spend more time in the creative part of the work (guessing it’s the preferred one) and do faster the tough ones.

What kind of feedback from your customers and beta testing do you value the most, and how do you incorporate that feedback back into new versions and products?

we are continuously improving our software

Any feedback is very welcomed. Everything helps to improve our software. We are continuously improving our software. For example, this week we have released a new Service for RhinoGold 2.0.
Also, we have RhinoGold labs. From our website and our Forum, users can give their opinion and post about their ideas. And, since the moment user posts it, our developer team starts working on these ideas. We have launched RhinoGold 2.0, but we already know and we are working on some new ideas for the next version.

I would like to thank Rafael for taking the time to answer my questions. If you have any questions for Rafael or for Novedge, please leave a comment below and we will be glad to answer.

Franco Folini

RhinoGold Training Video TDM Solutions products are available from Novedge

Interview with Craig Dennis, TransMagic CTO

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 TransMagic products are available from Novedge