Does the MonoGame pipeline model processor add vertices?

I imported a fbx model to blender. It consists of one mesh with 12882 vertices (info from blender: at the top after selecting everything in edit mode it says 12882 verts). When accessing the model in MonoGame (the one ModelMeshPart in the Model) and looking up VertexBuffer.VertexCount I get a different number of 13366 vertices.

The model I used is available here: teapot.fbx

I’m on mobile, so I can’t check the file, but maybe it has to do with normals? Does the file have normals? Do you let MG generate normals?

The model has normals I guess, in blender they show up as expected. I copy the normals from the ModelMeshPart and also calculate them from the positions and I get the same values. I seems odd to me, that I get a different vertex count from the model than displayed in blender (I also opened the fbx model with visual studio 2012 and it displays the same vertex count number as blender).

Blender understands vertexs as a “real life vertex”. However 3d engines require vertex data to be sent to the GPU in order to render.

This means that if the same ‘blender’ vertex has different normals for each face that share that vertex, this vertex position must be “duplicated” because from the GPU standpoint, it’s a different vertex.

You can’t say a GPU “i want the vertex #3 with the normal #5”, so the vertex position is duplicated (but the normal is different)

To test it, just create a cube. Blender will say 8 vertices, MG will say 24. Now smooth the cube so that each normal is shared by each vertex. Blender will say 8 vertices, and MG will say 8 vertices too. (but the cube will not look like a cube)

Actually blender tells you that there are only 8 vertices, but he uses 24 to render too. =)

A teapot should have smooth normals shared by all vertices.
Maybe it’s an option on the OpenAsset that duplicates vertices even when they share common Position-Normal-TextureUV.

MeshBuilder has a method to find duplicate vertices.
Does the model importer make use of that? do we need some epsilon when it compares the position/normal values?

That does make sense. But just from looking at the normals in blender it seems to me, that the model has shared normals or smooth normals everywhere. When drawing the model, the normals I get in the effect / shader seem to be right (using the world normal as color output in the pixel shader). Copying the normals from the VertexBuffer (using the provided VertexCount of the VertexBuffer) and using them together with the positions I construct a VertexBuffer to visualize the normals similar to blender. Drawing the constructed normal VertexBuffer does show only some of the expected normals (comapred to the normals in blender). The nozzle / spout and the lid of the teapot have no normals and the handel only partly. Apart from that the normals look exactly like expected.

I’ve had a closed look at the teapot and yes, there should be no ‘sharp edges’. I’ve made a small test checking for duplicate vertexs, and found this:

(white vertexs are duplicated)

Differences seem to be in the texture coordinates:

https://pastebin.com/vQxt6isR

I don’t know who is responsible, blender or assimp. Anyways I don’t feel like it’s a bug.

1 Like

Good work :slight_smile:

Now could you maybe try to visualize the normals? By visualizing I mean to build a VertexBuffer with a LineList (start point: vertex position, endpoint: vertex position + vertex normal). Hopefully this works so I know I have a bug somewhere :slight_smile:

Edit: Nevermind, all normals are there… I mixed up some indices :dizzy_face: