Using 3D CAD Data Downstream

Wolfgang Geist, Conweb GmbH and David Prawel, Longview Advisors Inc.
 
As 3D CAD data finds more and more applications outside of design departments, many 3D data formats enter the game, besides the better known 3D CAD formats that use NURBS or Bezier surfaces. For many years, native data conversion using STEP, IGES or native converters was regarded as the corner stone of interoperability. In the last few years, feature and parametric translation has become more common, as these technologies have matured. But as greater demand for 3D data emerges in many downstream processes like maintenance, sales and marketing, or technical documentation, these native 3D CAD formats are not ideal, and are generally not used. Instead, users depend more and more on tessellated (polygonal) data representations. CAE computations, simulations, virtual reality sessions, digital mock-up (DMU), and general visualisation processes in service and planning are among almost countless applications that depend on a huge variety of different tessellated data formats. VRML is a very popular example. Once very popular a decade ago, it was virtually unused just a few years ago. But it is enjoying a huge upswing in many of these “new” 3D applications.

What is behind this demand?
Most downstream applications don´t need all the information which is contained in a 3D CAD model. For example, product visualisations do not require all the details of the interior of a part or an assembly. Carrying and sharing all this information results in poor performance of the graphical processes, so users don’t like to use these files unless absolutely necessary. Similarly, CAE computations require only abstractions of the geometric and topologic data and use meshed data formats. And crash simulations require special 3D data representations which cannot be used in CFD simulations, even for the same vehicle design. The same applies for virtual reality or DMU.

As a consequence, major CAD vendors provide a “dual” data world for their 3D CAD systems. CATIA V5 is complemented by CGR, or sometimes 3DXML, which are both tessellated data formats. These can provide good performance in the visualisation of large assemblies or in DMU analysis. Unigraphics has pushed the JT format for many years. Even though JT Open can use both NURBS data and tessellated data for the same object, most of the JT files found in actual use are using the tessellated format only. Another example is Maya, the image creation and animation software from Autodesk. Maya uses exact NURBS data for modelling and design, but tessellated data for downstream processes and image creation. Maya users can decide to switch to the tessellated data format and decouple design and animation creation at any time during the design and animation process.

And 3D formats have certainly proliferated. All 3D viewer products, for example AutoVue from Cimmetry, or Acrobat 3D from Adobe, are based on tessellated data formats which are more or less proprietary. The well-known STL format, also tessellated, has for decades played a key role in the rapid manufacturing and prototyping industry. But this simplicity afforded by these tessellated formats has created some additional challenges for downstream users.

A big challenge in using 3D CAD data downstream is understanding the characteristics, behaviour, and capabilities of a particular format used in a particular application. Due to slimmed-down tessellated data structures and the lack of topological and other information, these formats may not be well suited to certain down-stream processes. Users need to understand and match the format to the application. The visualization files can be changed and updated from the associated native 3D CAD models, but this has to be done manually, often with huge effort. As an example, a huge bottleneck which impedes the efficient use of 3D digital prototypes is the broken loop between the tessellated data formats in a virtual reality (VR) simulation and the associated 3D CAD model data. Design and shape changes that result from a VR session take too much time to be introduced into the CAD model, since it has to be done manually. Therefore, VR experts fear shape modifications, especially those requested by top management in a vehicle design review, because these changes often need a week or more to be updated into their associated 3D CAD models.

So what does this all mean for using 3D data across an enterprise?
Companies may want to establish two standard 3D data formats which are replicated automatically and available universally, so that users can find on a server both an actual 3D CAD data set as well as a set of accurate and updated tessellated data. MAN, a leading European truck manufacturer in Munich, Germany is using CATIA V5 for design. Through an automated process, CATIA V5 design data is converted every night into tessellated data in XVL format from Lattice (which is the basic format in 3DXML), which is then available to targeted users, e.g. technical illustration teams. Because XVL is a highly compressible format, product data size is not a concern. In another case, the Daimler Group has selected JT as a common 3D data format which is used for all processes which don´t require editing of any CAD data. Both companies have selected powerful and well accepted formats which can be used by many downstream software products.

A major mistake companies sometimes make is to use exotic formats, for example CSB (Cosmo Binary or SGI Open GL Optimizer). This format was in use at a time when Silicon Graphics created very specific data formats to boost their 3D graphics performance. This format is still in use in some VR applications. Companies should also avoid applications which are based on such exotic formats. since both maintenance from and dependency on a software vendor is sometimes a high risk proposition. Customers should look for data formats which have proliferated throughout a large user community, so that the chance for ongoing development is much higher. Unfortunately, there is no accepted standard format, as all vendors try to establish their own format as “the” industrial standard, for example, Dassault with 3DXML, Unigraphics with JT, Autodesk with DWG, Adobe with Acrobat 3D and the embedded special formats U3D and *.prc.

Another strategic criterion is the level of support provided by a particular 3D CAD product for outputting tessellated data formats. Huge problems in downstream simulations arise from poor control of tessellation levels and a poor division of assembly structures into separate data structures at non-ideal levels of tessellation. The effectiveness of DMU and other simulation tools in animating such models as huge stamping dies for example can be hugely diminished by missing variables to control the granularity of the tessellation process. In a customer project including the design and kinematic animation of a large stamping die, the performance of the animation tool was far from acceptable because it was not easy for the user to find the parameters in the 3D CAD system which could modify the level of detail in the output of the VRML data used by the animation software. In another case a customer wanted to send STL data to a light simulation software package for studying the LED lighting parameters inside a cooler. The CAD software generated 500 MB of STL data from a 3D CAD file of the cooler without any differentiation into sub-parts as they already existed in the CAD model. The light simulation software was not able to handle such a large file so additional programming efforts were needed to connect both worlds. Building this link between the CAD system and the simulation system cost much more than all installation and training costs combined!

A rather pragmatic approach is to select tessellated data formats which are derived from a dual 3D CAD/visualization format representation, as discussed above. In these cases, users can work with exact and modifiable 3D CAD models late in the design stage. Only in the last minute tessellated data can be generated. Using this approach, the risk of major, costly rework following additional design change requirements is minimized.

As it is with selecting the best 3D CAD system, it is also mandatory to have a master plan for the usage of 3D CAD data in downstream processes. Incompatible formats generate huge additional effort and associated cost in the migration of 3D data between both worlds, and can easily consume the otherwise huge benefits of using this data downstream.

For more information, contact Wolfgang Geist at wolfgang.geist@conweb.de, and/or David Prawel at dprawel@longviewadvisors.com. You can also visit the Conweb Web site at www.conweb.de or the Longview Advisors Web site at www.longviewadvisors.com, or the Longview Blog, 3D Ubiquity, at www.3dubiquity.com.