Draco compression increases vertex count about gltf-transform HOT 4 CLOSED

The v4 alpha has a new bit of information in the inspect() report, breaking out different ways of calculating a 'vertex count'. Interesting to note here that the number of vertices drawn are the same (i.e. same number of triangles), but the number in the vertex buffer is slightly larger.

Not sure I've found the right names for these yet, but:

before

after

¹ Expected number of vertices processed by the vertex shader for one render
pass, without considering the vertex cache.

² Expected number of vertices uploaded to GPU, assuming each Accessor
is uploaded only once. Actual number uploaded may be higher,
dependent on the implementation and vertex buffer layout.

³ Expected number of vertices uploaded to GPU, assuming each Primitive
is uploaded once, duplicating vertex attributes shared among Primitives.

If I switch from the 'edgebreaker' method to the 'sequential' method, the count does not increase, so I guess this must have something to do with how Draco is re-indexing the vertex stream for edgebreaker compression.

I have cases where applying draco compression increases the vertex count both for relatively lowpoly meshes as well as highpoly meshes.

In other cases has this been on the order of "a couple extra vertices", "+X% vertices", "+XX% vertices", etc.?

from gltf-transform.

Possibly related threads:

• CesiumGS/gltf-pipeline#630
• google/draco#326
• google/draco#363

from gltf-transform.

Small increase in vertex count appears to be an occasional effect of edgebreaker compression. Unsure if that's intended, but there seems to be nothing glTF Transform can do to prevent it.

from gltf-transform.