I wanted to have a scrolling background in one of my ui screen. So I forked your project Tutorial Animated Textures and got it to work in here: project
But then I wanted to temporarily disable the entity and later enable it again. And once I do that, the scrolling doesn’t work anymore. You can easily reproduce it by just disabling the entity in the editor and enabling it again, while watching the launcher in the other tab.
This apparently is only an issue if the material is used in an element. It is working fine for the other material, which is displayed in world space. Does someone know what I need to do? Does this problem relate to me cloning the material before animating it? That’s the only change I added to the script…
So after digging a bit into the engine we found this function in the image element:
1 onEnable() {
2 var asset;
3 if (this._materialAsset) {
4 asset = this._system.app.assets.get(this._materialAsset);
5 if (asset && asset.resource !== this._material) {
6 this._bindMaterialAsset(asset);
7 }
8 }
9
10 // ... similar code for using a texture or sprite
11
12 this._element.addModelToLayers(this._renderable.model);
13 }
So whenever the element is enabled again, it looks for the material in the linked asset and binds it. This was the cause for our issue, because we cloned the material before updating it. So the cloned material got updated correctly, but once we re-enabled the element, the original material got bound and displayed again. So our solution was to remove the asset reference after cloning it.
Why does the material need to be taken from the resource again? In line 5 why is it checking if the asset.resource is different from this._material and then using the asset, instead of the current material?
The developer that wrote this is no longer on the team so can’t really say but yes, it does look very odd.
Could easily be a bug TBH. I’m afraid I don’t have a good answer for this.
Can you log an issue for this on the engine repo please. I guess the workaround here would be to clone the material into another asset or null this._materialAsset when the material is cloned
The second recomendation of this._materialAsset = null is our current solution.
Creating an Asset to store the Material in when I’m only needing the Material seems like it should be an unnecessary step. Like you said, it would only be a workaround.
I will file an issue, also to maybe get more clarity on this topic.
