It seems like the issue you're experiencing with full-size textures still appearing in the build when using Spine with Addressables might be related to how Unity handles the inclusion of assets. One potential cause could be the Unity SpriteAtlas integration, which requires a single .png atlas texture to be generated and used in the Unity Editor. This texture is referenced by a material, which might lead to the unnecessary inclusion of the full-resolution atlas texture in your build, regardless of the "include in build" setting. You might want to check if the material references are correctly set up and if any unnecessary references are causing the full-size textures to be included.

Additionally, ensure that all required assets, such as the .atlas.txt and .json files, are correctly included in your addressable group. If the problem persists, consider reviewing your workflow to ensure that materials and textures are assigned and managed correctly, possibly by modifying the spine-unity code to handle materials on demand or by adjusting your addressable setup.

@UjeenPowers Sorry to hear you're having troubles. How exactly did you notice that the full-resolution textures are still included in the build?

Which Unity version are you using?
Also, which exact version of the spine-unity runtime are you using (name of the unitypackage, also listed in Assets/Spine/version.txt or in the Package Manager window)? Which version of the Spine Addressables Extensions and Spine On-Demand Loading Extensions packages (in the Package Manager window)?

The on-demand-loading scripts utilize the build pre-processor step to swap out the full-resolution textures with the low-resolution placeholders. Could you perhaps check (via setting a debug breakpoint or adding Debug.Log() statements to the code) whether the following code is executed:
EsotericSoftware/spine-runtimesblob/4.2/spine-unity/Assets/Spine/Editor/spine-unity/Editor/Utility/SpineBuildProcessor.cs#L152

If you still encounter the issues with the latest spine-unity and extension packages, could you please send us your minimal clean Unity project which still reproduces this issue? You can send it as a zip package to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context. Then we can have a look at it.

@UjeenPowers Thanks for the additional info and for sending the reproduction package. We will have a look at it and get back to you here on the forum once we've figured out what's going wrong.

@UjeenPowers This is indeed a bug related to blend mode materials not having their texture replaced alongside with the main material. We will let you know here on the forum once this issue is resolved. Thanks for reporting!

@UjeenPowers The above issue has just been fixed, see the issue ticket comments here:
EsotericSoftware/spine-runtimes1890
There is now an additional Skeleton Data Asset property at the AddressableTextureLoader asset which can be assigned to respect blend mode materials as well.

Please let us know if this resolves the issues on your end as well. Thanks again for reporting!

@UjeenPowers We won't be backporting this commit to the 4.1 branch, as we can't risk breaking existing 4.1 projects, sorry.

You could however quite easily integrate the commit into your 4.1 project, as the files GenericOnDemandTextureLoader.cs and GenericOnDemandTextureLoaderInspector.cs (both from the extension UPM package) can be copied as-is from the 4.2 branch. Only the single block of changes of the OnDemandTextureLoader.cs (of the spine-unity package) needs to be manually integrated then.

Please also note that we always recommend automating your exports via the Spine command line interface to be able to re-export all your Spine assets in a single run using the latest version. There are also official export scripts available which might save you writing your own.

@UjeenPowers Glad to hear, thanks for letting us know.