Draco compression increases vertex count

[marwie]

Describe the bug
Hi, I'm not sure if this should be reported here or elsewhere and I'm geneally unsure why it happens in the first place but I have cases where applying draco compression increases the vertex count both for relatively lowpoly meshes as well as highpoly meshes.

To Reproduce
Steps to reproduce the behavior:

1. Open zip and run gltf-transform draco sphere.glb sphere.draco.glb
2. See vertex count changed from 515 to 519

Expected behavior
Vertex count doesn't change / doesn't increase

Versions:

• Version: 3.10.1
• Environment: node 20

Additional context

λ gltf-transform draco sphere.glb sphere.draco.glb --verbose
debug: dedup: Merged 0 of 6 accessors.
debug: dedup: Complete.
debug: weld: Complete.
debug: unpartition: Complete.
debug: [KHR_draco_mesh_compression] Compression options: {"method":1,"encodeSpeed":5,"decodeSpeed":5,"quantizationBits":{"POSITION":14,"NORMAL":10,"COLOR":8,"TEX_COORD":12,"GENERIC":12},"quantizationVolume":"mesh"}
debug: [KHR_draco_mesh_compression] Compressed 1 primitives.
info: sphere.glb (359.42 KB) → sphere.draco.glb (331.08 KB)

draco vertex count.zip

Before

After

[donmccurdy]

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

renderVertexCount¹	gpuVertexCount²	gpuNaiveVertexCount³
2,304	515	515

after

renderVertexCount¹	gpuVertexCount²	gpuNaiveVertexCount³
2,304	519	519

¹ 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.?

[donmccurdy]

Possibly related threads:

• Draco compression probably breaks CESIUM_primitive_outline extension CesiumGS/gltf-pipeline#630
• Vertex count varies google/draco#326
• Is the order of vertices in the Draco output reproducible? google/draco#363

[donmccurdy]

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.

[donmccurdy]

Ouch, this small increase in vertex count can cause the compressed mesh to overflow the max size of the index array type. Tracking in:

• Draco compression may produce an UNSIGNED_SHORT index buffer with vertex count > 65535 #1370