Design-time texture preview and Addressables loading

So when I am making a game, I would ideally want to see a texture in the editor. In this case it is this crossed out texture. And when in play I want this texture to be loaded through Addressables. (Or in this demo's case, I don't even want the crossed out texture in the build at all)

But when I use Addressables.LoadSceneAsync, because the scene provider do not have direct dependency to this texture's resource key, the normal Unity scene loading would load the connected design-time texture to the memory before I could make it load through Addressables.

So how can I have both texture visible at design then have it passed through the Addressables loading system when loading the scene containing it? Do I have to leave everything blank before build to not cause them to be loaded by normal flow?

The only thing that I figured out is Sprite that has a SpriteAtlas, which I could drag it to SpriteRenderer or Image at preview time without worry. Thanks to checking don't include in build on the atlas, at runtime the texture is white on scene load. Then I could use SpriteAtlasManager to provide the atlas with Addressables.LoadAsset<SpriteAtlas>, and the texture resolves itself from white texture when Addressables is done with the load. Now, I could manually release the atlas handle when out of the scene. But this doesn't work with Sprite without atlas, or texture connected to material since they don't have callbacks on requesting the texture.

Unity Technologies

There are a lot of ways to solve this. The ideal as I see it is to extend the demo to support prefabs as the "addressable unit" instead of textures. At build time creating high and low res prefabs (pointing to high and low res textures). That's a bit more work, so we haven't gotten around to making it as a sample, but that would be the ideal.

Beyond that, there are a handful of ways editor scripts could be used to either display a texture in the editor, or to remove a linked texture at build time.

This sample is meant as a jumping off point for people to create what they need. Things get significantly more complex (and often product-specific) from here.

Oops...

"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.