Skip to content

Update getTextureByteLength to handle compressed textures and external textures.#1560

Open
castano wants to merge 5 commits intoNASA-AMMOS:masterfrom
Ludicon:memory-utils-improvements
Open

Update getTextureByteLength to handle compressed textures and external textures.#1560
castano wants to merge 5 commits intoNASA-AMMOS:masterfrom
Ludicon:memory-utils-improvements

Conversation

@castano
Copy link
Copy Markdown

@castano castano commented Apr 14, 2026

getTextureByteLength assumed the tex argument is a regular uncompressed texture backed by an image. When using compressed textures or external textures the code would throw an exception.

This PR extends it to handle CompressedTexture (summing the attached mip-chain buffers) and ExternalTexture (reading userData.byteLength), and returns UNKNOWN_TEXTURE_BYTE_LENGTH (0) when the size can't be determined (missing image, missing dimensions, or unknown format) instead of throwing.

Originally discussed in #1497; splitting out as a standalone fix with no Spark dependencies.

castano added 3 commits April 13, 2026 17:54
Extend getTextureByteLength and avoid throwing when the size cannot be
determined:

- CompressedTexture: sum the mip-chain buffers already attached to the
  texture.
- Unknown formats, missing images, or missing dimensions now return
  UNKNOWN_TEXTURE_BYTE_LENGTH (0) instead of raising.
- ExternalTexture without a userData.byteLength falls back to the same
  unknown-size sentinel rather than silently taking the generic path.
Copy link
Copy Markdown
Contributor

@gkjohnson gkjohnson left a comment

Choose a reason for hiding this comment

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

Thanks! I've made a couple comments - and we'll likely need to handle texture disposal correctly, too (see #1497 (comment))

Comment thread src/three/renderer/utils/MemoryUtils.js Outdated
Comment thread src/three/renderer/utils/MemoryUtils.js Outdated
@gkjohnson gkjohnson added this to the v0.4.25 milestone Apr 15, 2026
@castano
Copy link
Copy Markdown
Author

castano commented Apr 15, 2026

Just trying to be extra careful to handle unexpected texture objects, but I can remove that if you think there's no need to. The && Array.isArray( mipmaps ) && mipmaps.length > 0 could also go away too.

@gkjohnson
Copy link
Copy Markdown
Contributor

gkjohnson commented Apr 16, 2026

Thanks!

see #1497 (comment)

Disposal handling is that last step, I think. Let me know if there's anything I can help clarify on that.

Just trying to be extra careful to handle unexpected texture objects

I definitely understand the inclination but have found that in order to keep the code manageable, especially in javascript, it's best to assume that data is coming in well-shaped. Otherwise the amount of error handling and data checking will be a bit too much

@castano
Copy link
Copy Markdown
Author

castano commented Apr 16, 2026

Thanks. I think registering dispose event handlers from Spark's glTF loader might be the right approach, but I'm not sure whether that should live in the loader or be left to the application. What do you think? Either way, I think that's independent of this PR.

Here's a possible implementation: Ludicon/spark.js#31

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