Nowadays, pretty much every item you see is designed using Computer Aided Design systems (CAD for short), from simple everyday items all the way up to very complex pieces of machinery and even plants and factories.

This is great, because these detail-rich 3D models can also be used for animation, photo-realistic rendering, and even for training and in virtual reality!

So, is it as easy as a one-button click?

Well no, not really. For starters, engineers and architects don’t model like artists or game designers.

Consider this: If you were to model a factory for a game or an animation, you would pretty much design a couple of boxes and pyramids, maybe some tubes, use a material to make it look good and be done with it. The key is to save resources for performance purposes.

If you were to design the same factory to create the drawings to actually build it, you would have to create everything, every single pipe, beam, nut, bolt, cable, everything! That’s a lot of items!

And even though CAD systems manufacturers are getting better at providing embedded rendering and animating solutions, this is not the primary use for these systems, and for anything more than concept renders or very basic animations, a dedicated CGI package like Maya, 3DsMax or Blender is required.

This is the main problem. The amount of data coming from CAD systems is so massive in some cases that even with the best machines money can buy today, performance is a big problem.

For small to small/medium size models, the transfer is fairly easy:

• First, you have to find an export format that your chosen CGI package can read (most of the time FBX works out of the box). If you can’t export to FBX from your CAD software, find another export format that Navisworks can read, load it in and export your FBX model file from Navisworks.

As an example, you can’t (as of the time of this writing) export to an FBX file directly fromAveva’s PDMS/E3D. The solution is to export the models to the native PDMS (.rvm) format, import the RVM file(s) into Navisworks and then export the model into an FBX file.

• You can now load it in your animation/rendering package and start working.
•  Some selective “Pruning” of the hierarchy might be required for performance and quality (in short, remove all the stuff you don’t need).

For larger models, the workflow is very similar, but model size and machine resources become more of a concern (especially memory):

• First, whenever you export a model, if possible try to avoid exporting un-necessary items in the first place. This will save you a lot of headaches and time down the line.
• Once the model has been exported to FBX, extensive hierarchy “Pruning” (or Reducing) will most likely be required. Polygon count is of course a concern, but it doesn’t tell the whole story, far from it. As an example of this, say that you have a model with one mesh containing 1 million triangles. It would render fine, and viewport performance would be good. Now, say that you have the same model with 1 million triangles, but this time they’re distributed into 1 million meshes containing 1 triangle each. This would be pretty much un-workable. This is because the system now must look through 1 million items every time it tries to refresh the viewport.

“Pruning” the hierarchy tree consists in removing as many unnecessary hierarchy levels (or branches) as possible (whether you keep children polygons or not). In my experience, “Pruning” is the first area to have a look at if you want to improve rendering and/or viewport performance. So much so that at MachineSquad, we have developed software solutions and processes to help with the selective “Pruning”, even before loading the model into the animation package.

 CAD packages typically generate hundreds of thousands of nested geometry nodes. This is very subjective and hardware-dependant, but I’ve found that keeping the number under 5,000 items is a good balance between detail and performance (this approach certainly worked well on the 9 minutes long Clair Ridge oil platform 2016 animation, where I’ve managed to keep the total number of nodes at around 4500, and performance was still good, even with 350+ million polygons!) .

• If after “pruning” the model you still have performance issues, now is the time to start looking at polygon counts. As mentioned previously, all unnecessary data should be removed, and if possible, it should not even be imported in the first place. There are various algorithms that can be used to remove polygons, and some CGI packages have built-in functionalities for this (like MultiRes or Pro-Optimiser in 3DsMax). Please note that reducing polygons will also tend to lower the quality of your 3D meshes, and may introduce visible tessellation artefacts.
• If you have a lot of repeatable items (like tables, chairs, trees, etc…), you should consider using Geometry Instancing. This can usually be done in a variety of ways, one of which is through proxies (see MentalRay Proxies, VRay proxies).
• Using external references may help you save some time, especially if you have other people working with you on the same models.
• Finally, changing the viewport representation of some or all items to Bounding Box (only displays the volume box of items) will speedup your animation workflow, and may save some nasty crashes (especially if your model is stretching your GPU’s memory limit).

Sending your model to a game engine (for Virtual Reality or else) is usually done after this. Do your texturing, UV Mapping, animations and final model clean-up in your favorite CGI software, export the model as an FBX file and import it into Unity3D, UnrealEngine, LumberYard, Cry Engine, etc…

A further consideration is floating point precision:

This problem arises when transferring models that are far from the origin (0,0,0) from CAD software that typically use 64bit double precision “numbers” to animation packages or game engines typically using 32bit single precision “numbers”. The problem is that you can’t store the same number of “zeros” in the 32bit float, and if you are using global coordinates (long numbers) your precision can drop quite a lot, as numbers get rounded. If you have issues with “jittering” models or weird viewport issues, try to move your model closer to the origin, this will fix the problem and speedup general operations.

To conclude:

Every project is different and ideally you should know your model and what you want to use it for before starting to tackle the export, this will save you a lot of time and trouble.

If you are having problems with your export, have a rush job or just want to have a chat about your project, give us a shout! At MachineSquad we are 3D model specialists with over 10 years’ experience in Engineering Systems and 3D model design, animation and rendering, across various industries. We can also assist with your Virtual Reality projects.

Have Fun!