Unity will accept several file types for imported 3D models, but which one is the best, specifically when exported from Vectorworks? I take a closer look at the .fbx and .obj types, doing several rounds of test exports from Vectorworks and importing each into Unity.
Below is a list of how these two files types compared on various issues. In the end, .obj (with some modifications to the model before export) seemed to be the winning approach.
An ideal and optimized import has a low poly count, embedded materials, and one material slot per object in the Unity inspector.
An .fbx file imports into Unity without needing to be rotated. Meanwhile, .obj models import on their side, requiring you to rotate -90 on the X axis. It’s an extra step, but certainly not a dealbreaker.
When you import .fbx into Unity it preserves each individual object as it was in Vectorworks, so a group of objects will preserve their individual child objects.
Whereas an .obj export treats several Vectorworks objects as one combined mesh. With an .obj you can’t turn individual parts of the mesh on and off in Unity. The entire mesh is one object.
This isn’t the end of the world. It simply requires a little thought before exporting. If you want to be able to control aspects of the model separately in Unity, be sure to export them as separate .obj files.
In the context of this experiment, think of normals as the plane(s) of an object that get rendered in Unity. Let’s say you export a ceiling object (an extruded rectangle) for import into Unity. If the normals are not in the correct alignment, your ceiling will appear to be transparent. Zooming out to view the ceiling from above however will likely reveal that your material is in fact rendering, but only when viewed from one side.
Unfortunately, there have been several occasions when I’ve exported an .fbx model in Vectorworks and have had issues with misaligned normals in Unity.
If you must use .fbx, consider stopping over into Cinema 4D on the way. Here you can apply Display Tags to disable Backface Culling and manually reverse/align normals as needed to get your model ready to import into Unity (go to main nav > Mesh> Normals).
Luckily, exporting from Vectorworks as an .obj does not seem to cause any issues with normals, so YAY!
Materials import embedded with an .fbx file, no worries there:
However, for .obj the materials do not import embedded, so we need to manually link them in the Inspector using External Materials (Legacy):
Using a Vectorworks standard hotel chair model (below), I performed a few experiments modifying the object pre-export in Vectorworks. The goal was to see if there was a way I could prep a model before exporting to ensure ideal performance in Unity.
Here are the results
Generic Solid .fbx
It imported as 5 separate objects, three for metal, and two for chair cushions. 22 batches, 9k tris, 20.6 verts (way too high).
It imported with a crap ton of materials fields but only 2 batches, 1.7k tris, 5k verts. In general, .obj wins for low poly count.
It imported with 7 material fields for the metal and 8 for fabric. Still only 2 batches, 1.7k tris, 5k verts.
Generic Solids .obj
Converted the chair symbol into a group first. Then separated out into two material-based groups, one for metal and one for the cushions. Finally, converted the entire material group into a generic solid. It imported with two materials fields for the cushion .obj and two strangely divided material fields for the chair metal .obj object. Same batch & tri/vert count.
Converted Mesh Generic Solid .obj
Converting it to mesh and then converting to a generic solid ensured that the object would import with only one material field, same batch & tri/vert count.