-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Share textures across models in a limited but useful case #5051
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -2234,6 +2234,8 @@ define([ | |||
|
|||
/////////////////////////////////////////////////////////////////////////// | |||
|
|||
var resourcesCachedAcrossModels = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency with other cached resources, should this instead be stored somewhere like context.cache.modelTextureCache
?
Yes, I would like to review. Please give me a week or two. |
@hpinkos we'll want something like this. We could start with this and get it over the finish line when it is a priority. |
Thanks again for your contribution @kring! No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy? I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome. 🌍 🌎 🌏 |
@cesium-concierge stop |
I'm going to close this PR due to inactivity, but keep the branch around for when we want to revisit this. |
This PR shares textures across models in the limited case of textures that come from regular old images. Textures that come from arraybuffers (e.g. compressed textures. textures embedded in a binary glTF) or from images with really long URLs (e,g, data URIs) are not supported here because determining a suitable cache key would be tricky.
My use case is a 3D Tiles tileset with lots of overlap in the textures used by different tiles. The images are all external to the b3dm files. Before this PR, heaps of duplicate textures would be created and eventually WebGL context would be lost after exceeding GPU memory. After this PR, it works great.
It's safe to say we'll want to support sharing textures (and probably other resources) in more scenarios eventually, but this incremental improvement is pretty useful.
One possible criticism of this PR is that
loadImage
is still called even for textures that do not need to be created because they're already in the cache. I didn't think it was worth the extra complexity that would be necessary inparseTextures
to fix this, since the browser should already do a pretty good job of making this fast.