2
$\begingroup$

Yes, I know, use Mesh -> Clean up -> remove by distance. I did that, and in blender, it appears as if things are all fine and dandy, I made 3 cubes and made pyramids at the end, total vertex count is 18, makes sense to me. Export object as gltf, and I get... 84 vertices...

enter image description here

This is the GLTF report

enter image description here

gltf image, and my blender:

enter image description here

You can see in the bottom corner, 18 verts....

And for the final touch, here's the output from my tiny_gltf loader c++ program, which outputs vertices, and says the number of vertexes and indexes.

{NORMAL: 1}
{POSITION: 0}
{TEXCOORD_0: 2}
COUNT 84
INDCOUNT 96
(1, 1, -1)
(1, 1, -1)
(1, 1, -1)
(1, 1, -1)
(1, 1, -1)
(-1, -1, 1)
(-1, -1, 1)
(-1, -1, 1)
(-1, -1, 1)
(-1, -1, 1)
(-1, -1, 1)
(3, 1, -1)
(3, 1, -1)
(3, 1, -1)
(3, 1, -1)
(3, -1, -1)
(3, -1, -1)
(3, -1, -1)
(3, -1, -1)
(3, 1, 1)
(3, 1, 1)
(3, 1, 1)
(3, 1, 1)
(3, -1, 1)
(3, -1, 1)
(3, -1, 1)
(3, -1, 1)
(1, -1, -1)
(1, -1, -1)
(1, -1, -1)
(1, -1, -1)
(1, 1, 1)
(1, 1, 1)
(1, 1, 1)
(1, 1, 1)
(1, -1, 1)
(1, -1, 1)
(1, -1, 1)
(1, -1, 1)
(1, -1, 1)
(1, -1, 1)
(4, 0, -0)
(4, 0, -0)
(4, 0, -0)
(4, 0, -0)
(-3, 1, 1)
(-3, 1, 1)
(-3, 1, 1)
(-3, 1, 1)
(-3, 1, 1)
(-3, -1, 1)
(-3, -1, 1)
(-3, -1, 1)
(-3, -1, 1)
(-3, 1, -1)
(-3, 1, -1)
(-3, 1, -1)
(-3, 1, -1)
(-3, 1, -1)
(-3, -1, -1)
(-3, -1, -1)
(-3, -1, -1)
(-3, -1, -1)
(-3, -1, -1)
(-1, 1, 1)
(-1, 1, 1)
(-1, 1, 1)
(-1, 1, 1)
(-1, 1, 1)
(-1, 1, 1)
(-1, 1, -1)
(-1, 1, -1)
(-1, 1, -1)
(-1, 1, -1)
(-1, -1, -1)
(-1, -1, -1)
(-1, -1, -1)
(-1, -1, -1)
(-1, -1, -1)
(-1, -1, -1)
(-4, 0, 3.01992e-07)
(-4, 0, 3.01992e-07)
(-4, 0, 3.01992e-07)
(-4, 0, 3.01992e-07)

Look at all those duplicates! how do I stop blender from ruining my meshes on export?

This doesn't really answer my question, but I found a temporary work around by copying the vertices on the mesh and deleting the old one.

Q: Is this just a really bad bug or something?

$\endgroup$
3
  • $\begingroup$ something hidden in the outliner? $\endgroup$ Commented Dec 10, 2020 at 5:29
  • $\begingroup$ @AllenSimpson I undid what I just did, and there did seem to be like 5 duplicate collections... and 4 meshes... I was on the scene instead of blender file menu. Yet multiple times I removed duplicate vertices, and when I move the selected object, there's no objects underneath. So I don't understand how these random objects got left around. $\endgroup$
    – Krupip
    Commented Dec 10, 2020 at 5:49
  • 1
    $\begingroup$ Maybe this docs.blender.org/manual/en/2.80/addons/… $\endgroup$
    – lemon
    Commented Dec 10, 2020 at 7:03

1 Answer 1

6
$\begingroup$

It is incorrect to assume the number of glTF verts will equal the number of Blender verts. Each glTF vert has a unique normal for example, while each Blender vert can have a different normal for each poly it is in. Your model uses flat shading and you can see each vertex has multiple normals.

normals

To handle this there are "duplicate" glTF verts (that have the same position, but different normals). The same thing happens for all other "vertex per poly" data, like UVs.

"Duplicate" verts are inserted only when necessary, so turn off export of anything you don't need—normals, tangents, UVs, vertex colors, materials—to get a smaller glTF vert count.

$\endgroup$
1
  • $\begingroup$ This appears to be the issue (though there were 6 extra vertices unaccounted for when I just reran only re-nabling normals)! I didn't think about the normal aspect of this, indeed for indexing to properly work each normal would need to correspond to a duplicated vertex. $\endgroup$
    – Krupip
    Commented Dec 10, 2020 at 15:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .