Importing "damaged" and "undamaged" versions of an FBX model gives different vertices count


I'm using Lightwave 9.5 with the standard FBX exporter.

I've got a model that I call 'Undamaged' which is an FBX model of a car and the same model but with some vertices moved to make it look damaged.

Exporting these to fbx and importing into Lightwave again confirms that the vertices match and the vertices indexes are the same (this point on the bonnet equals that boint on the smashed bonnet).

I'm trying to morph the meshes between the two states.

When I import them both I get different vertices counts (and obviously the vertices indexes don't match up anymore). I've tried turning off Recalculate normals, giving each model a 180 smoothing angle.

I have no idea, any helpers?

Any vertices in your model which fall on a smoothing seam or on a UV seam in your model will be duplicated when it comes to displaying in Unity. This is because UV and Normal information is stored and used on a per-vertex basis when the models are displayed by the graphics card.

For this reason - unless your model has completely smooth normals and no UV seams at all - you'll see a discrepancy between the number of vertices reported by your 3d modelling app, and the number of vertices reported by Unity when displaying the model.

Perhaps you could solve this by creating a vertex animation rather than two separate exports, and using one of the vertex animation workarounds to blend between the two states.

Maybe the verticies along a "torn" edge of the model became two after the seam was split. Lightwave may be too smart.

You would probably have to be very careful with your asset pipeline. Another option is to seperate the components that are going to be broken apart into different groups. The goal here would be to ensure that the damaged and undamaged models have the same set of mesh groups and each submesh would have identical vertex counts and identical topologies.

One issue I ran into with XSI exporting morph targets that sounds very similar to this… is that the FBX exporter tries to outsmart you by optimizing out vertexes which are on top of each other (zero area triangles is another way to say it). So in the 3D app, the blendshape operates fine, but then in Unity you get mismatched counts.

If you suspect that it is not an issue regarding split normals or split UVs (or differences regarding anything needing to be split into multiple verts on the exporter side due to Normals or UV borders)… you might want to look into whether either mesh has “zero area triangles”.

Zero Area Triangles are also sometimes referred to as Degenerate Triangles in some 3D packages, fyi–

hope that helps–

Dan Bernard
Owner / Creative Director
Stovepipe Interactive