One challenge rising in 3DCG product visualization consists off accurately converting a CAD file to its mesh based polygon version. While CAD software do use common graphic library API for real-time display in their viewport, their export function often lacks of consistency and produce undesired noise. When clean mesh topology is required, those issue ultimately lead to a “model from scratch” strategy which is costly and meaningless as the CAD file is only used as reference.

While this CAD to polygon issue goes silence in high-polygon production such as animation or illustration, it get worst when dealing with real-time project or mobile limited application. Game engine implementation or WebGL visualization heavily rely on UV mapping and clean optimized mesh topology. Yet this optimization step has to be “smart” in a way that mesh tesselation should make sense from a visual information point of view. In other words, polygon density should be “eye oriented” in its logic instead of being deduced from CAD nurbs topology. Thus, scale in polygon size should be consistent within a human eye, density should be constant. Challenge is how to reach this goal from a real life production CAD file.

The default way of doing should be to start from the native CAD software. Here is a first bottleneck as license in CAD application can not worst an occasional file conversion. We still have trial version but many of those rely on file i/o limitation. From there we can either export the data to a robust polygon format such as FBX, Collada or ultimately to OBJ. We can also export it to an other common CAD format with better export options like IGES or DXF. In that case, export settings should be setup to high or very-high with a preserved hierarchy. Converting to low-polygon would be then deduced using a polygon reduction filter based on this hierarchy. Yet, this is theory and real-life production is full of noise, surprisingly even when using the native CAD software.

Here is a real life case study we will focus on. We are developing our own WebGL based product solution and we will be using a sample file, starting from its CAD format, to benchmark the whole production pipeline. Here is the CAD to polygon steps and bottleneck.
The product is provided in a native Lattice XVL version 3 (.xv3) format and an exported Siemens Parasolid file (.x_t). Lattice Technology has a very proprietary product license and there is no way you can import a .xv3 file without a Lattice product. So our starting point is the Parasolid file. Note that if you have a Lattice Studio Pro license you would prefer using an IGES (.iges) export for future polygon convertion based on Rhinoceros 3D, or a DXF file is you own any Autodesk CAD family software.

Using Rhinoceros 3D and a IGES file allow you to generated different level of detail depending of the desired hierarchy. While this provide a useful control on the final generated mesh, it is time consuming and heavily rely on trial-and-error.

Okino Polytrans

^{© Okino}

We gave a try to the Okino Polytrans mesh generator software. Note that the Parasolid file generates errors in the generated mesh topology. Once generated we wish we could have the CAD file object hierarchy reproduced at a mesh group level. Instead mesh group were kind of randomly generated based on mesh density, thus leading to a messy hierarchy once imported in CG software.

nPower Power Translator Plugin

^{© IntegrityWare, Inc.}

Then we tried the nPower Power Translator plugin for 3DS Max. We tested three different settings “Default”, “High” and “Very High”. Note that float errors in vertices position appeared using this solution too, but only on a single group, which means the Parasolid file was somehow corrupted. Yet the CAD hierarchy was preserved, leading to the final mesh shown below. The vertices noise error were removed by hand.

We wish there is a state of the art production pipeline for CAD to low polygon modeling. From our experience, real life convertion are still based on trial and error mixed with noise handling on a case basis. At the end of the day it remains a hand crafted workload. The nPower solution is far the best and straight forward pipeline we have found so far, yet hand work is still necessary for low polygon mesh reduction.