Rendering CAD Models (Part 2)

Filed under:CAD,Data Transfer,Learning — posted by jason on April 17, 2009 @ 12:50 am

In the previous segment I outlined the issues that we are faced with moving geometry from a CAD application to a rendering application. In this segment, I am going to cover the topics related to preparing your CAD models to be export ready for a rendering application.

CAD File Formats

Over the years the neutral CAD formats have evolved rather slowly because they are created via community panels so it inevitably can take some time to write a specification. Also, in that vein we have to realize that neutral formats are a specification and are still open to some interpretation by the implement developer. However, out the array of formats available for a CAD system to output I am listing the more popular and useful ones. These file formats are what we will use to formulate a meshed model by either using an intermediate program, or in some cases the rendering application itself.

  1. STEP – (.stp, .step) – comes in the variety of AP203/AP214. STEP is a b-rep format and therefore won’t be a file you can import to your rendering application.
  2. IGES – (.igs, .iges) – IGES has had a long history with the current specification version at 5.3.  IGES is a b-rep format which normally cannot be imported to a rendering application although Maya, XSI and 3DS Max have limited IGES support.
  3. VRML2 – (.wrl) – VRML2 (also known as VRML97) was supposed to be the web 3D format but didn’t go as far as some hoped. However, VRML2 is an attractive format because it can contain heirarchical information, vertex normals, surface colours and it is a triangulated format. Some rendering applications support direct import of VRML2, but I have found that in the vast majority of cases that some treatment is required prior to trying this because the CAD VRML2 export is engineered for visualization applications and not specifically rendering applications.
  4. Wavefront OBJ – (.obj) – Pioneered by Wavefront Technologies, the OBJ format is an open format adopted by many across the 3D industry. Despite its age, Wavefront OBJ is a tried and true format for rendering applications but has limited use within a CAD application since it is a mesh format. However many CAD applications can export to .obj but the problem more lies in the fact that it is a lazy export being that most functions of the Wavefront OBJ format are not utilized. That being said, OBJ is attractive because it supports vertex normals, uv coordinates and can transfer quad-vertex polygons (“quads”).
(Click here for a more detailed description of CAD B-Rep formats)

Vertex Normals

Simply put, the vertex normal is a normalized average of the neighbouring polygon normals that share a vertex. Having vertex normals calculated and carried over from NURBS models allows us the efficiency and precision of having the most accurate smoothing based on the mesh density. Therefore, fiddling with smoothing angles becomes unnecessary since the model inheritly has the information to produce a smoothed result.

Therefore, maintaining this information is critical when rendering CAD files but one also must be aware of the pitfall of editing these meshes in the rendering application. When an application interprets the vertex normals it usually will create a reference map that the application stores, so at rendering the application will review the vertex map to carry out any smoothing operations based on weighting you may have applied. The problem becomes evident if you start modifying the mesh and thus in turn disrupting the vertex map because the application can no longer associate the vertex from the map to the model. If you find you have to modify the mesh in your rendering application, you will want use a utility like PolyTrans to recalculate the vertex normals based on the existing mesh.

Coordinate Systems

Prior to exporting you must pay attention to your coordinate system, because you get only one. The coordinate system you apply to your exported models will result to the rendering application’s origin. If you are exporting discreet parts that have no relation to other parts then using the centre of gravity is typically acceptable, but if you are dealing with assemblies then the coordinate system used is extremely important.

Master Coordinate System (MCS)

Let’s imagine you have CAD assembly of a car. You are most certainly are not going open the top level assembly and click export. One methodology is to create a master coordinate system (MCS) that you can reference for all subassemblies or groupings of objects that you may export. When using a MCS you will find that all your parts come together in the rendering application in their proper position, which then brings us to the next problem concerning pivots and kinematics.

CAD Helper Objects

Let’s pretend you have followed my advise thus far and used a MCS and imported your objects to a rendering system, and we will continue with the analogy of the car. We have the body imported, and the wheels so it’s time to animate. The problem is, that you may have grouped all the wheels to a group for export and used a MCS which is logical except for the matter that when you grab a wheel to rotate it is now rotating amongst the MCS!!

This is where CAD “Helper Objects” come in because even if you try ungrouping your objects in the rendering application you will find that the MCS is still be referenced. CAD helper objects are going to be simplistic geometry that you will add to your groupings and assemblies to mark the key locations of the kinematic joints. The key to remember is to use simplistic objects like cubes or cylinders so that we can easily center pivots in the rendering application.

The steps are simple:

  1. Create your helper objects, the heirarchy isn’t so important but it can be advantageous to create the parent child relationships to your helper objects
  2. Export your groups using the MCS
  3. Import the models & form a heirarchy of your helper objects to each other, and then the models to each helper object
  4. Use the ‘center pivot to object’ command that you have available for your application
  5. Repeat #4 for each helper object

For forward kinematic type models what I’ve prescribed gives you a working rig. The next step for setting up the inverse kinematic rig would be to assign constraints to your helper objects, which then also can serve as your animation objects.

Until Next Time

That’s it for now, in the next segment I will cover a working example using Pro/ENGINEER and demonstrate the usage of simplified reps for grouping objects and using a master coordinate system.

If you have a specific query or would like a topic covered please leave a comment or email me : jason (at) cgpipeline (dot) com

zero comments so far »

Please won't you leave a comment, below? It'll put some text here!

Copy link for RSS feed for comments on this post or for TrackBack URI

Leave a comment

Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

(required)

(required)




image: detail of installation by Bronwyn Lace