Shared texture when multiple entities use the same video as material map

[dmarcos]

If multiple entities share the same video as material map. Only one texture is created and shared across all materials. It's not possible to configure each material independently like for example setting different texture offsets.

We can change how this works in multiple ways. We could generate separate hashes for each texture and create multiple textures if the material data differs. this wouldn't work as expected if all materials sharing the same video map start with the same material values and then change. Changing the material values will result in changes on the shared texture.

We could completely forgo caching video textures. Shared video materials are unusual vs. shared texture images. This is the simplest solution. We would increase resource usage when a single video is used in different materials but not common in practice.

An example to play with:

https://glitch.com/edit/#!/zippy-bush-quill?path=index.html%3A43%3A37

Can see that if both entities share same video element cannot set texture offsets independently since they modify the same shared texture.

This is something we have to address but not sure yet about the best solution.

[mrxz]

Uploading the same texture multiple times should always be avoided, especially in the case of video textures. While the use-case of having a single video with various segments/regions might be uncommon, displaying the same video texture several times in a scene is probably a lot more common (e.g. TV screens).

The current texture handling and caching in A-Frame has quite a few problems. When using the same image it's easy to end up with multiple unnecessary copies/uploads (e.g. when only using different UV offsets). At the same time textures can get shared when their initial properties match, but won't get "unshared" when changing these properties on an instance. This can result in both unintended changes across all usages, or changes not taking effect (see #1372, #5120).

It's clear that the material system predates many of the improvements made in Three.js. Luckily this means the solution is relatively simple. Instead of caching Textures, A-Frame should focus on caching Sources and let Three.js determine when textures should be uploaded and copied.

[dmarcos]

We definitively should revisit old design / assumptions