How to cache two different texture compression formats under same platform

Unity Engine
,
1

If you have two different platforms both running on android, but you need two different texture compression formats (DXT vs ASTC) is there any way to make unity cache both compression versions in the library folder?

As it is now we have to constantly reimport when switching build targets between standard Android devices and the MagicLeap2.
I was considering whether the accelerator would help, but if it works like the unity editor I guess it can’t differentiate between these two “sub” platforms either, and will just overwrite the cached textures whenever we change formats.

Maybe it’s worth setting up addressables to solve this issue?

2

Hi @TheVirtualMunk_1 ,

I’ll assume that you are setting this compression using an AssetPostprocessor, probably OnPresprocessTexture, and check your current build target and some global value to decide which compression you really want vs. what’s in the import settings.

If that supposition is right, then there is an easy way to force the AssetDatabase cache to work for you, what you are looking for is CustomDependencies.

The idea is that when switching between your two android targets, you’ll call the
RegisterCustomDependency method with a hash specific to each platform, and the same key.
During the import of the textures in your AssetPostprocessor, you’ll add a custom dependency to this same key, which will tell the AssetDatabase that your asset needs to be re-imported whenever this changes.
Ideally, the hash used in RegisterCustomDependency is the hash of the value you’re using during the import to figure out which compression you want.

By doing this, your texture will be cached accordingly to this custom dependency and switching platforms should restore the expected version from the cache instead of having to force a manual re-import every time.

3

Thanks for that information!
I’m using SuperUnityBuild to manage build targets, where after setting up the different distros I can press a button named “configure editor”, which does a lot under the hood, but it doesn’t look like it’s using the AssetPostProcessor.
From what I gather it simply just sets the EditorUserBuildSettings and player settings - more specifically for texture’s this seems to be the method;

private void SetTextureCompression(string key)
{
     EditorUserBuildSettings.androidBuildSubtarget = EnumValueFromKey<MobileTextureSubtarget>(key);
}

So it’s not really straight forward for me how to implement what you’ve referenced. I’ll give it a go, but if you have any additional information please let me know :slight_smile:
Thanks!

EDIT;
Further testing has shown that setting the texture compression in the build settings to “use player settings” and then changing the format in the player settings instead seems to keep the different formats in the cache - also after exiting Unity, coming back in, and then changing sub-platform. Haven’t tried building the different platforms yet though, so maybe that will trigger a reimport of textures.

4

From what I remember, the EditorBuildSettings for textures compression is compressing textures at build time and not at import time, which means it bypasses completely the AssetDatabase and thus re-import for each platform / sub-platform change…
The player settings global override for texture compression was made with dependency in mind and thus is working with the cache as expected.

I’m not sure what can be done to solve your issue. I’d say don’t use the global EditorUserBuildSettings for texture compressions, and try to go down the AssetPostprocessor route, but that may imply a lot of changes from the tool you’re using…
I you can change the tool to make it use the player settings override instead, it’d be a good first improvement, but like the other setting, it’s very global and thus limits some more refines settings you’d want to set for specific textures (if any).

5

So I changed it to only affect the playersettings texture format (using playersettings presets), but it looks like if I change the platform after a build, it will do a reimport of textures again.

Even if I can go the AssetPostprocessor route, how will this work if we set up an accelerator?

6

CustomDependencies and AssetPostprocessor dependencies are all supported by accelerator, so it should be fine, and probably better to go this route rather than any global setting for asset import.

1 Like