1330 introduced a new texture system that deletes the CPU memory once the data is copied to the GPU. However, this introduces problems for feature ID texture + property texture property picking, which depended on image.pixelData to remain on the CPU.
1367 was a band-aid fix for such scenarios, by copying any textures that happen to be used by the material. But we should have a more robust solution, because this can potentially create too many copies. For instance, two property texture properties can sample the same texture, just at different channels.
One idea I had is to just move the deletion of the textures after every single texture in the model has been processed. During creation, we can just mark if a CPU texture should be deleted, then do a final pass over all the textures in a model. This feels most safe, though I don't know if that undoes or interferes with any of the work that #1330 did.
@kring also suggested:
the "best" solution here is to have even metadata textures be on the CPU or the GPU, but not both (i.e., have only one copy of each texture in memory ever), even if that requires a GPU read-back in some cases.
So a future solution could be to keep the memory on the GPU, but add code that can read-back from the GPU and sample the texture.
1330 introduced a new texture system that deletes the CPU memory once the data is copied to the GPU. However, this introduces problems for feature ID texture + property texture property picking, which depended on
image.pixelDatato remain on the CPU.1367 was a band-aid fix for such scenarios, by copying any textures that happen to be used by the material. But we should have a more robust solution, because this can potentially create too many copies. For instance, two property texture properties can sample the same texture, just at different channels.
One idea I had is to just move the deletion of the textures after every single texture in the model has been processed. During creation, we can just mark if a CPU texture should be deleted, then do a final pass over all the textures in a model. This feels most safe, though I don't know if that undoes or interferes with any of the work that #1330 did.
@kring also suggested:
So a future solution could be to keep the memory on the GPU, but add code that can read-back from the GPU and sample the texture.