About "Include in Build" behaviour

I'm trying to use a Sprite Atlas feature in Unity2017.1.0f1.
I need to download Sprite Atlas assets via Asset Bundle at runtime and not to be included in a built app binary (In other word, I don't use Resources).

So I have some questions:

1. "Include in Build" means "A built app binary contains a packed sprite atlas"?
2. If I need to use Asset Bundle, should I uncheck the "Include in Build" option?
3. In such case, should I always do "late binding" written in the following document?
(I have a prefab that has a uGUI Image that refers a packed sprite in an Asset Bundle. The packed sprite atlas is also in the Asset Bundle. In this situation, even If I instantiate the prefab, the sprite doesn't be shown on screen)
https://docs.unity3d.com/2017.1/Documentation/Manual/SpriteAtlas.html
4. When will a SpriteAtlasManager.atlasRequested callback be triggered? Can I control a timing of it?
5. Where is a packing tag (the 1st parameter of a SpriteAtlasManager.atlasRequested callback) from? It's a filename of a .spriteatlas asset?

 

Thank you for a quick response. It's so helpful for me.

Things what do I want to do:

- Make an Asset Bundle that contains a prefab that has a uGUI Image that refers a sprite.
- Download the Asset Bundle at runtime.
- Instantiate the prefab in the Asset Bundle and display the sprite on screen.
- Don't contain both the prefab and the sprite in a build app binary (to reduce app size)

According to your answers, I should do:

- Uncheck the "Include in Build" option (to reduce app size)
- Load a Sprite Atlas from the Asset Bundle
- Get a Sprite via SpriteAtlas.GetSprites() and set it into Image.sprite

because there are no way to resolve sprite atlas reference from uGUI Image.
My understand is correct?

If so, there are feature requests to make Sprite Atlas better:

- Late binding supports uGUI Image.
- Split "Include in Build" option into "Include in Build" and "Use Late Binding" options.
There is possible situation that "I don't want to include an atlas in a binary but I don't need late binding feature".
If both a sprite atlas and components that refers the sprite was included in a same Asset Bundle, It would be better that a loaded component references the sprite without late binding. Because the component knows where the sprite is. (Of course, it's in the same Asset Bundle)

 

I attached a simple tiny project for reproducing my situation.
This project has been made in Unity2017.1.0f1 / macOS / iOS Platform.

The project has a Scenes/Game.unity scene.
An attached component Scripts/InstantiateFromAssetBundle.cs on Canvas will load an uGUI Image from an Asset Bundle and instantiate it. I've expected a sprite was shown on screen but it wasn't.

Assets in the Asset Bundles are placed on "Asset Bundle Assets" folder and the Asset Bundle was built by Asset Bundle Manager.

I faced this problem when I play this project on Editor and Local Asset Bundle Server mode.
I didn't check that this problem will happen on device / other platforms.

 

Like you say, I created a prefab with Canvas. But the problem still occur.
Please review an attached project.

 

I reported a bug via Unity Bug Reporter in Editor.
Thank you for reviewing.

 

Thank you for update.
Hope soon the issue will be fixed.

 

As this one seems to be the only current alive thread on the Sprite Packer, I have a couple of doubts here. A premise, we worked till now with TexturePacker for atlases management.

The first one is almost the same as @beinteractive had involving a bundle and a prefab (in my case it's sprites, but same problem). It's also a bit unclear to me if i need to provide with the asset bundle tag only the sprite atlas or also the single sprites (and in that case will there be a duplication?).
I also add that as a vital feature one should be able to use the sprites from inspector, otherwise the workflow becomes hellish if i need to assign each sprite from the code.

The second one is related to size. The size of the atlas seems to be bound to the largest of the packed sprites. In TexturePacker, after producing a sheet, we had a chance to change the whole sheet, resizing each single sprite in the process. Here it does seem to work only if you first reduce the size of each involved sprite. Beside, having tried with a sheet with lots of small elements (a waving flag), it happened the following : The flags were still in a very large format because i forgot to reduce them (so approx 30 frames each was 512x512). I give the packing command into a 1024 atlas, and without any worning, a lot of them were left outside the atlas.

Is it possible to give the atlas some control over the final size ( i saw variant but in my case using the variant seems a bit overkill) and/or at least a warning that all the elements couldn't fit in as required? I think it's pretty easy to lose a sprite along the way without noticing because of that.

Cheers,
H

 

@Kuan I've been trying to get UGUI SpriteAtlas and Asset Bundles to play nicely together and have a question about Include In Build intended behaviour.

I would think that checking include in build would make it so that the atlas does NOT get duplicated in every bundle that references a sprite from it but that is not what's happening. Is it expected that checking include in build will duplicate the atlas in every asset bundle that is dependent on it or is this a bug?

 

@Kuan thanks for the speedy response!

I can tell it is being duplicated in each bundle because of the size. And to re-iterate this is only if I have the "include in build" boolean set to true. I'll work on getting a simple repro project to send in with the bug.

So is that confirmation that late binding is not supported for UGUI? And will it be supported in the future?

 

Following on from drHogan's question about size - I am packing a sprite atlas and seeing that the Max Size settings for the individual sprites being packed do not appear to be respected by the atlas packer. For instance I've set a 256x256 icon down to 128x128 to save space on the icon itself, but when I do the atlas pack, it has taken the file size of 256x256 and packed it at that full size instead. Is this something I'm not doing correctly? An intended functionality? I would have thought that we'd be able to fine tune individual sprite sizes and other settings as per normal for any unpacked sprite, and then have those changes applied as such into the packed atlas.

 

Did some experimenting and late binding can work on Images in bundled prefabs that reference bundled SpriteAtlases if you instantiate the prefab, deactivate the object so you can't see the broken Images, handle the atlas request which comes in on frame end*, and then reactivate the object next frame (presumably because now it has all the info to actually build the canvas correctly). Tested in Editor and on Android.

Not really acceptable for us but if anyone else is stuck in a real bind, this good 'ole "turn it off and on again" trick may help.

It's a shame because it seems like a nice system but I don't think reworking our pipeline to use GetSprites is worth it so we're likely sticking with the Legacy Packer for a while.

* Sadly even yield return WaitForEndOfFrame doesn't wait long enough. Atlas request still comes in later.

 

I'd like to confirm that I'm having an issue with 'include-in-build' sprite atlases also being duplicated into other asset bundles. This can be confirmed by both the asset bundle size and the log output of what's included in the bundle.

I also tried bundling my sprite atlases into their own asset bundle (still with include-in-build) and other asset bundles will still duplicate them. This has been a trick I use with regular texture to prevent duplication by using a 'common' asset bundle with them already included, and therefore other asset bundles should know not to duplicate.

The legacy sprite atlas system does not have this issue, and my project is going to have to continue using the legacy system.

Any update on the status of this?

 

i found a violence way ,
BroadcastMessage("SetAllDirty", SendMessageOptions.DontRequireReceiver);
in next frame........

 

@Kuan any word on when UGUI will support late binding?

 

thanks for answering my questions

 

I don't want to seem rude, but I just spend an entire day, trying to figure out why my code was not working on late binding and UI image. Until I came across this post.

So basically it's been a year since the release of this new feature, and this bug has still not been fixed ? Not even 1 mention about Late binding and GUI not working in the docs.

Honestly, as a paying user, sometimes how Unity handles thing seems less then professional. I don't even get how such a simple bug was not spotted during Unity QA....

 

So what's the resoult?

 

Hi, i am working with SpriteAtlas and AssetBundles, i have a lots of sprites that don't use all at the same time, i see unity load all in memory and is consuming 800mb of ram... so i decide to split on assetbundles and load the sprites i need and unload when i don't need them.
I'm using the sprite atlas manager, and it works great, but if i unload the assetbundle and later load it again it never relink with the sprites.
there is a way to load and unload spriteAtlas without losing the references to the atlas?
Best Regards

 

We are also experiencing some issues with sprite atlases. When using the memory profiler we can see that all sprite atlases referenced in a scene get loaded but when switching scenes they don't get unloaded even after calling Resources.UnloadUnusedAssets().

Scenes are switched using SceneManager.LoadSceneAsync(sceneName, LoadSceneMode.Single) and we are waiting for the end of frame after the async operation is done to call Resources.UnloadUnusedAssets().

When the sprites are not part of the atlas we can see in the memory profiler that they are properly loaded/unloaded.

All sprites are drag and drop references in the inspector, no asset bundles or sprite atlas API used. No sprite is assigned to more than 1 sprite atlas. Most sprites are assigned to UGUI Image components. Happens in the Editor and also on iOS devices.

We are currently testing using Unity version 2018.2.11f1 for Mac.

 

​

"SpriteAtlasManager.atlasRequested" will not be called if the Sprite included in the SpriteAtlas is attached to the SpriteRenderer and its Prefab is loaded from the AssetBundle and Instatiate is done.
.spriteatlas, .prefab, .png All are included in one AssetBundle.
I have a component that performs late binding in Prefab and I set reference of spriteatlas in inspector.

When placing it from the beginning in the Scene and playing it, I confirm that it binds correctly.

In this case, can you tell me how "SpriteAtlasManager.atlasRequested" will be called?

I am using Unity 2018.2.6.
I am sorry for my poor English.

 

Is this problem fixed now?

 

It's never been fixed as least for me, all sprites included in the build together with the big texture generated by the SpriteAtlas ... Never works, 2018.2.x, 2019.x or I'm I missing something? @ColossalPaul

 

Could you please submit a bug-report as described in this document:
https://unity3d.com/unity/qa/bug-reporting

It's important that you report these issues together with a reproduction project if you want them to get fixed. If you don't do it, it might be a long time until someone else reports them or until Unity Technologies find them.

After you submitted the bug-report, you receive a confirmation email with a bug-report Case number. You can post this Case number here (in this forum thread) for Unity staff to pick up, in case they see it.

 

Late binding for UI seems to work in the latest unity, but before a requested atlas is loaded image shows some garbage from other atlases like atlas for text or other atlases included in build.

While atlas is being loaded:

After:


Is it intended for some weird reason or a bug?

 

Yes regarding this, if you are async loading the atlas unity will show an empty image in place of the sprite. When the atlas request is called you really want to return it immediately. Setup your code to immediately have it available. (Download it before the game starts, or load the bundle containing it immediately at startup)

 

I know this thread is old and it is 2020 June, but I also want to know if how this "include in build" option plays with Addressable.

 

"I know this thread is old and it is 2023 March, but I also want to know if how this "include in build" option plays with Addressable."

 

Please don’t necro an old thread. Its against the forum rules. If you need to ask a question, please make a new thread.