WebGPU + Draco + KHR_mesh_quantization

[samevision]

Description

I am not able to load models that use KHR_mesh_quantization with WebGPU.

Solution

Same behavior as WebGL2.

Alternatives

No.

Additional context

No response

[Mugen87]

Do you mind sharing a glb asset that uses this extension?

[donmccurdy]

three.js includes a WebGPU example that requires KHR_mesh_quantization, which works (on my device at least). See:

• https://threejs.org/examples/?q=gltf%20compress#webgpu_loader_gltf_compressed

The key feature in this extension is support for 8-bit and 16-bit integer types in vertex attributes, like int8, int16, uint8, and uint16 (normalized or non-normalized).

• WebGPURenderer: Improve vertex format support and revisions. #25924

If there's an issue, I think a minimal reproducible example and device details would be needed to investigate.

[samevision]

Hi, here is the model: https://www.transfernow.net/dl/20250929GtONrnZm

I used: gltf transform's quantize({ quantizePosition: 12, quantizeNormal: 8, quantizeTexcoord: 8 })

I receive this warning if I load the model: "Vertex buffer arrayStride (3) is not a multiple of 4."

[Mugen87]

I can reproduce the issue:

[samevision]

I was able to load the model successfully but the performance is terrible:

if (attr.itemSize === 2) {
    const arr = new Float32Array(attr.count * 2)

    for (let i = 0; i < attr.count; i++) {
        arr[i * 2 + 0] = attr.getX(i)
        arr[i * 2 + 1] = attr.getY(i)
    }

    object.geometry.setAttribute(name, new BufferAttribute(arr, 2, false))

} else if (attr.itemSize === 3) {
    const arr = new Float32Array(attr.count * 4)

    for (let i = 0; i < attr.count; i++) {
        arr[i * 4 + 0] = attr.getX(i)
        arr[i * 4 + 1] = attr.getY(i)
        arr[i * 4 + 2] = attr.getZ(i)
        arr[i * 4 + 3] = (name === 'position') ? 1 : 0
    }

    object.geometry.setAttribute(name, new BufferAttribute(arr, 4, false))
}

[donmccurdy]

Hmm, the combination of Draco (KHR_draco_mesh_compression) + quantization (KHR_mesh_quantization) complicates this considerably. If I remove Draco compression from the model but keep the quantization, it works in WebGPURenderer fine, so I'm going to rename this issue to mention Draco.

The combination of the two is tricky because (1) the glTF Validator cannot check Draco-compressed data to confirm it is valid, (2) quantized vertex attributes should have WebGPU-compatible alignment+padding in glTF, but I don't know if the Draco decoder includes that, and (3) I don't fully understand the correct use of the Draco encoder (in glTF Transform) and decoder (in THREE.GLTFLoader) for this case.

I may need to investigate this one further; in the meantime I would suggest using Draco only, or Meshopt+quantization, instead.

[donmccurdy]

Related discussion with @gkjohnson on the same topic:

• How to use smaller bit precision for attributes when using DRACO compression? donmccurdy/glTF-Transform#1687

[samevision]

The idea was similar to the one of @gkjohnson. I want to combine both benefits of Draco and Quantization - reduced file size and reduce VRAM. It would be really nice to use it that way.

[donmccurdy]

Here's starting from a simple example like the duck.glb file already in this repository, here's a reproduction and the cause:

gltf-transform quantize duck.glb duck+quant.glb --quantize-position 8

gltf-transform draco duck+quant.glb duck+quant+draco.glb --quantize-position 8

Note, I'm passing --quantize-position 8 to both commands above. They do not have to match, but using a higher precision for the draco command would mean storing data at higher precision than it requires.

The quantize command quantizes geometry and applies no other compression. Quantization requires updates to node and joint transforms, applying the inverse of the transforms made to the vertex data. The output is still stored in normal glTF accessors, which are byte-aligned according to glTF requirements and would be compatible with WebGPU as-is.

The draco command moves geometry out of glTF accessors into a more opaque block of compressed binary payload. The Draco decoder appears happy to decompress the binary payload into any format, regardless of the quantization used, but doesn't appear to support padding for data alignment. Unless the Draco decoder has an option I've missed, we'd have to copy the vertex data and add padding as @samevision describes above. We could do this in a Web Worker (where the decoding runs already) but it's less than ideal from a performance perspective.

GLTFLoader has the final say as to which attribute types (f32, u8, u16, ...) we decode the data into. Currently it uses the glTF accessors to make that determination. If the user has only run the draco command above, then the accessors still contain float32 accessors and GLTFLoader will decode into float32 attributes. If the user runs quantize then draco, the accessors will declare smaller types, and GLTFLoader will decode into smaller accessors (without padding).

Decoding into quantized attributes when the glTF accessors do not use quantized types is very nontrivial. GLTFLoader would then have responsibility for rewriting node transforms, animation, joint inverse bind matrices, thickness of volumetric materials, etc. So when draco is used alone, without prior quantization, I think we need to continue to decode into float32.

---

Options:

• (a) Request that the Draco decoders add support for padded and/or interleaved output
• (b) Implement automatic alignment in THREE.DRACOLoader, at some performance cost
• (c) Use Meshopt+Quantization+Gzip, which retains required padding and byte-alignment from the glTF accessors, and will decode much more quickly than options (a) or (b).

[donmccurdy]

Proposal: Let's implement (b) above, with the following steps.

1. If GLTFLoader sees quantized accessors in the source .gltf/.glb file, it will request quantized attributes of the same types from DRACOLoader (no change here)
2. DRACOLoader will pad accessors on the same Web Workers used for decompressing, to parallelize the process and avoid blocking the main thread (new)
3. Back on the main thread, DRACOLoader will construct InterleavedBufferAttribute objects (rather than BufferAttribute objects with position: vec4 / normal: vec4 / ...) and add them to the resulting BufferGeometry (new)

It'd be nice if the Draco decoder supported this out of the box — and we'd simply replace step (2) if they did — but I think we can come within ~1.5x of WASM's performance just by optimizing the loop and operating on the typed array data directly.