As part of my application I implemented a texture editor that supports custom textures via CanvasTexture.
It works well and I am satisfied with it, but it would have helped a great deal to save custom properties to userData. However, it seems that userData is supported for objects derived from Object3D and Material, but not Texture.
I had a number of options other than using userData but I did not like them, so I chose to save the custom properties to the associated material’s userData, using the texture’s name as a key. While this is hacky, it seemed to be the least hacky alternative.
Has anyone else faced the same issue, or does anyone have a better solution to propose?
How about managing the additional data in a weak map on application level? You can use the texture object as the key and a new object that holds the data as the value.
The entry in the weak map will not prevent the GC from collecting the texture when it is not used anymore.
Thank you @Mugen87, this is an excellent solution.
What I appreciate is that your solution does not interfere with conversion of objects to GLTF format via toJSON() calls for storage and retrieval. I would simply have an additional “weak map” to be converted at application level, which is easily done.
My current solution also achieves that aim, but at the cost of creating a logical dependence between the texture and its associated material. This is not only a poor design principle, but makes it difficult to share texture resources between materials and objects in the scene.
What is your opinion about adding support for userData in texture objects going forward?
I too am running into a similar issue and would love to have an official ‘userData’ property on the Texture. Probably any object that has a dispose() wants to have a userData to help the user keep track of objects that aren’t garbage collected automagically.
.