Vertex count in Vircadia is Odd

[SilverfishVR]

By odd, I mean it does not match what other model viewers reports. If it just retains to how the reporting works its really a minor issue, but if some model configurations actually causes double, quadruple or n times the vertices being processed it may be worth looking into.

It seems very odd to me that the vertex count is multiplied with the number of materials on that object. So if you look at 5 and 8, it indicates that you half the vertex count by just splitting the model into 2 objects, that does not sound right to me.

Once you move beyond simple cubes, it gets a lot worse, I tried optimizing a 100.000 vertices FBX model with 348 drawcalls (each part a separate object), after merging to one object it shows as 800.000 vertices in vircadia, but still around 100K in windows model viewer.

I made some more structured tests, these are all done with with flat shaded GLTF models, using FBX or smooth faces it will yield different results. 24 vertices for a cube may seem excessive but that is how glft works I think, one set of normal data pr. vertex, so sharp edges are effectively split.

I used the Windows 3D viewer for the tests below but the GLTF plugin for VS Code (which I generally trust the most) matches the stats.

#	GLB model	Windows 3D Viewer	Vircadia
1	1cube_1object_1material	24	24
2	1cube_1object_2materials(both materials used)	24	48
3	1cube_1object_2materials(only 1 material used)	24	24
4	2cubes_1object_1material	48	48
5	2cubes_1object_2materials(1 material on each cube)	48	96
6	2cubes_1object_2materials(both materials on both cubes)	48	96
7	2cubes_2objects_1material	48	48
8	2cubes_2objects_2materials(1 material on each cube)	48	48
9	2cubes_2objects_2materials(both materials on both cubes)	48	96

The following models are just to see how the absence of UV's and/or normal data affect vertex count. I really don't know what to make of this

#	GLB model	Windows 3D Viewer	Vircadia
10	1cube_1object_1material(no normal data or UV's)	8	36
11	1cube_1object_1material(no normal data)	14	36
12	1cube_1object_1material(no UVs)	24	24
13	1cube_1object_2materials(no normal data or UV's)	14	72
14	1cube_1object_2materials(no normal data)	17	72
15	1cube_1object_2materials(no UVs)	24	72

The test cubes used: http://silverfish-freestuff.s3.amazonaws.com/TestStuff/VertCountTest/V2/vertexCountTestCubes.json

[ksuprynowicz]

Can you check the triangle count? I think this is caused by reusing vertex buffers for different material calls, and shouldn't degrade performance.

[SilverfishVR]

I'm sure the graphics api can reveal that somehow, I will see if I can figure that out. The thing is that the create menu shows vertex count, texture size, and drawcalls. and those metrics is is really the best tool a creator has to gauge the performance impact of each entity, so if the vertex count is "wrong" maybe triangle count should be used instead.

[ksuprynowicz]

I agree that triangle count would be more reasonable metric.

[SilverfishVR]

I managed to get the triangle counts, and in the process I discovered that there are two "levels" in the graphics api where you can get the vertex count.

One is adding up the vertices for each mesh in the model, this gives the same, high, result as is shown by the create menu.

The other is adding up the vertices for each mesh part, in each mesh of the model. for my test cubes this gives the same result as as other engines so it seems to be the more correct way, however, some FBX models seem to report very low numbers, like half or 1/3 🤔 there seem to be a difference in how GLTF and FBX should be handled.

This is the script I made: http://silverfish-freestuff.s3.amazonaws.com/TestStuff/VertCountTest/V2/gettrianglecount2.js when you click on a model the stats are written to the log. My result for the test cubes: http://silverfish-freestuff.s3.amazonaws.com/TestStuff/VertCountTest/V2/meshReport.txt

[ctrlaltdavid]

It may be counting each vertex N times where N = the number of triangles that use that vertex? The vertex count should be what's useful to ender users (modellers) rather than perhaps reflect engine internals?

[stale[bot]]

Hello! Is this still an issue?