Skip to content

Conversation

@jakra-mb
Copy link

Adds a way to serialize out a buffer declaration with a buffer size, without writing the actual buffer content. Needed for writing files that use the EXT_meshopt_compression extension.

This is only a proposal and frankly I have no idea how to make the interface for this functionality nice. It works, but I wouldn't mind if the final interface looks entirely different.

The problem is the following: When someone wants to write files that use the EXT_meshopt_compression extension, this is currently not possible with tinygltf.

The reason is, that for the extension to work, you need to write out 2 buffers. Buffer 0 with the actual compressed data, but also buffer 1. Buffer 1 is a dummy placeholder, whose sole purpose is to have a valid size, ie the size of the uncompressed data. Now buffer views will point to that buffer 1 with their uncompressed offsets and sizes, and thus validation code will determine that these offsets and sizes are correct. For this, buffer 1 does not need to actually exist, it just needs to have the correct size.

The extension then adds additional information about the actual byte offsets into the compressed buffer 0. This is described in some more detail here: https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Vendor/EXT_meshopt_compression/README.md#fallback-buffers

Currently tinygltf always writes all buffers to file. So if I create buffer 1 with the proper size, it will write those bytes out, which then doesn't compress the file, but rather increases its size.

If you have a better suggestion for how to support this, please let me know. If you don't want to support this use case, that's also fine, then I'll have to continue to use a custom fork.

Adds a way to serialize out a buffer declaration with a buffer size, without writing the actual buffer content.
Needed for writing files that use the EXT_meshopt_compression extension
@syoyo
Copy link
Owner

syoyo commented Jan 15, 2026

Please include the minimal logic(pseudo code) of your proposal.

@jakra-mb
Copy link
Author

Please include the minimal logic(pseudo code) of your proposal.

Not sure what you mean, the code in this PR is the minimal, working code.

@syoyo
Copy link
Owner

syoyo commented Jan 16, 2026

Standalone description of the logic.
its not a working code, since unit tests missed.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds support for placeholder buffers to enable serialization of glTF files using the EXT_meshopt_compression extension. The extension requires a fallback buffer that exists in the JSON with only a byteLength property (representing uncompressed data size) but no actual binary content or URI.

Changes:

  • Added placeholderByteLength field to the Buffer struct to store the size for placeholder buffers
  • Added SerializeGltfBufferPlaceholder function to serialize buffers with only byteLength (and optional metadata)
  • Updated buffer serialization logic in both WriteGltfSceneToStream and WriteGltfSceneToFile to detect and handle placeholder buffers

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@jakra-mb
Copy link
Author

I've added tests for both GLTF and GLB outputs and made the comments a bit clearer.
The tests also verify that buffer name, extras and extensions are correctly written.

The pseudo code logic is:

if (buffer.placeholderByteLength > 0 && buffer.data.empty()) {
  write buffer with "byteLength" = placeholderByteLength
  DONT write buffer content
}
else {
  write buffer normal (with content)
}

@jakra-mb jakra-mb changed the title Proposal: Placeholder buffer support Placeholder buffer support Jan 20, 2026
@syoyo
Copy link
Owner

syoyo commented Jan 20, 2026

Thanks! Let me give time to review the PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants