Official Feedback wanted : Sprite assets support

This seems great, although I do have one observation to share. We noticed that the desired workflow in our teams is for artists to create, put UI images into project and use them in UI directly. Then at some later time some developer would take a look on the created screen and its performance and decide if some of the used images should go into Atlas. At that point developer should be able to create an atlas and assign images to it without having to go through all the UI screens created with those images and correcting their paths to target the atlas. In other words there should be automatic redirection of old paths so they now target the atlas.

Of course the issue with that workflow is the case where you want to put the same image into multiple atlases and one atlas should be used on one screen but another atlas on another screen even if original image path is the same. I think this could be solved with some additional property like "PreferredAtlasName" on the controls and there are probably other solutions as well.

I think your Addressables are providing this kind of abstraction so that nothing needs to change at the place where assets are used when they are moved into or out of asset bundle (but I am not sure about that).

 

Since Addressables we're just mentioned. Any plans/existing workflows how ui Toolkit will work with Addressables (addressable sprites/sprite atlasses in this example)?

 

Is there a way to specify draw mode for the sprites?

 

Ahh, okay. Tiled mode specifically was what I was looking for.

 

So I have an actual sprite atlas, just a single image from which other sprites are generated and can be expanded in the project view. Using the old-style Canvas Renderer/Image, I could assign any of those sprites to the background image--however, with UIElements, I'm unable to drag and drop/assign any of the sprites, but I can assign the entire image/atlas, which... obviously isn't what I want. Is this intended or am I doing something wrong?

 

I did see that, but it's not really particularly useful for me--I don't wanna have to hand-edit UXML files or specify the sprites programmatically or worry about the names of the sprites/images at all, really. It seems that this somewhat defeats the purpose and ease of using the UI Builder in the first place. It would be really useful to be able to have the same drag-and-drop functionality as the older style UI, if possible.

 

hi, how to prevent a texture dynamically built to an atlas??

 

This feature is not working as expected. Tested with SpriteAtlas V1.
Unity 2021.1.24f1
UI Builder-1.0.0-preview18
UI Toolkit-1.0.0-preview18

I can assign a sprite from an atlas via the UI Builder.


This gives the following UXML code:

Code (csharp):

1. <ui:VisualElement name="Icon" class="unseen-collectiblelistentry__icon" style="background-image: url(&apos;/Assets/_LocationBasedXR/Textures/UI/Design-LocBased/Icons/Tours/x2/icon-tour-jurassic@2x.png#icon-tour-jurassic@2x&apos;);" />

"icon-tour-jurassic@2x" is part of an V1 sprite atlas and it displays fine in a runtime UI when rendering the UXML via an UIDocument.

I then try to assign a new icon to the VisualElement via the background property in C# like so:

Code (csharp):

1.  
2. icon.style.backgroundImage = data.Thumbnail.texture;
3.  

where "icon" is a reference to the VisualElement shown above.
This does not throw an error, but instead of the icon being displayed, the atlas texture is shown:


When I delete the atlas, the assignment of the new sprite works fine.

Question: Is assigning a sprite which is part of an atlas via C# supported and if so how can i do it?

 

data.Thumbnail

is of type Sprite and .texture is in fact the texture property of the Sprite. It is declared like this:

Code (csharp):

1.  
2. public Sprite Thumbnail {
3.     get { return thumbnail; }
4.     set { thumbnail = value;}
5. }
6.  

When I try to assign the Sprite rather than the texture like so

Code (csharp):

1. icon.style.backgroundImage = data.Thumbnail;

I get a compiler error

Code (csharp):

1. error CS0029: Cannot implicitly convert type 'UnityEngine.Sprite' to 'UnityEngine.UIElements.StyleBackground'

 

Hi mcoted3d,

Code (csharp):

1. icon.style.backgroundImage = new StyleBackground(data.Thumbnail);

works like a charm. Thanks for the hint.

While it works it should be mentioned that the documentation of the StyleBackground constructor does not list a constructor accepting sprites.
https://docs.unity3d.com/2021.1/Documentation/ScriptReference/UIElements.StyleBackground-ctor.html

Now that I know, I found that VS Code intellisense indeed shows a StyleBackground constructor using a Sprite. So I guess documentation needs to be updated.

 

I use 2021.1, specifically

• Unity 2021.1.24f1
• UI Builder-1.0.0-preview18
• UI Toolkit-1.0.0-preview18

and it works despite the missing documentation.

 

Hi @antoine-unity. Long time ago I asked about build sprite atlas at runtime feature. Is that feature still planned to implement?

 

Hello @antoine-unity.
Perhaps I'm doing something wrong, but the Pixels for Unit property in the sprite import settings are not affecting the sprites in the UI Toolkit.
Also would there be any support in the future for an individual "Pixels Per Unit Multiplier" property for the 9 scale sprites?

 

@mcoted3d Thank you for your reply, I will try to explain it better.

I have a button in UGUI with a background a sprite set with borders to be 9-slice scalable. This is in a normal Canvas with Screen Space - Overlay.
In the first image I am setting the Pixel Per Unit property to 100:

In this second image I am setting the Pixel Per Unit property to 200:

The difference between the 2 is the scale of the border. In some situations I would like to scale the border a bit down depending if the border is for a button or a panel.
As you can see, the Pixel Per Unit value is also affecting the UGUI.

This behaviour can be done in a different way, if we want to change only individual images, and not all which are using this sprite, by increasing the Pixels Per Unit Multiplayer property in the Image component. To look the same as above we would increase from 1 (default value) to 2.

This result is somewhat also possible in UI Toolkit, but with a hack. We can change the scale down of the whole button to 0.5 by changing the transform values, and double the fontsize and paddings. Clearly this is not desirable.

Ideally we would have the Pixel Per Unit property changing the scale of the sprite directly in the UI Toolkit as well OR have another property for the background similar to Pixels Per Unit Multiplayer.

Please let me know if this is clear now. Thanks!

 

EDIT: Found the solution!
In order to use the packages (preview) version of UI Toolkit that contains the Sprite feature in 2020, you have to explicitly reference the UITK package in the asmdef files that use the code. If you don't do that, Unity will try to compile those asmdef's with the builtin (version 2) of UITK instead on startup.

This is for sure a bug, but I'm not sure if there's any chance it'll get fixed since it's a bug with using a preview version that I'm pretty sure goes away if we update to 2021.

Original Post:
We're running Unity 2020, using UI Toolkit preview, and use this feature in some spots.

It worked fine in 2020.3.11f1, using 1.0.0-preview.14. I now updated to 2020.3.23f1 (latest). We're running into a bug, both with 1.0.0-preview.14 and -preview.18.

What's happening now is that when we start Unity, Unity tries to compile our code using what seems like the built in version of UI Toolkit. This means that we fail to compile on code like

new StyleBackground(sprite)

, and are prompted to enter safe mode. If we force a recompile by adding an arbitrary space somewhere, Unity compiles and works again, but this isn't viable to do every time we open the project, and I don't want to ask our artists to do that!

I seem to remember that I ran into this bug a while ago, but I cannot remember what we did in order to fix it!

Any advice? We don't want to update to 2021 quite yet, but I've got some crashes in 2020.3.11 that's supposed to be fixed in later 2020.3 versions. Dropping the code that uses the sprite feature is also not viable - we've got some important windows that need to draw sprites, and rewriting that is probably going to be more work than the 2021 upgrade

 

Encountered issue in Unity 2021.2.4 that I cannot set sprite in UI Builder if the file is in Resources folder. In that case the builder allows setting it as sprite then changes the type to texture when I save or navigate away.

Is it the expected behaviour?

 

Hey Antoine, please see my bug report here:

https://forum.unity.com/threads/bug...i-toolkit-creating-abnormal-behavior.1235770/

The 9-slicing does not seem to work properly at least in this version I am using (2021.2.9f1).

Any help? Thanks as always.

 

Hi,

I was wondering if someone from Unity could explain how the Dynamic Atlas works.
I imagine it creates a dynamic atlas at runtime where it packs all the sprites that are currently used but I'm not sure if the Sprite Atlas Asset has any affect on it.

Does UI Toolkit still create a Dynamic Atlas if all my Sprites are already in a Sprite Atlas Asset?

Thank you.

 

Thanks for the explanation mcoted3d.

One last question, is there any advantage in using the Dynamic Atlas over the Sprite Atlas Asset when it comes to performance?

It seems that the Sprite Atlas Asset would be the preferred way when I know exactly when, where and what sprites/textures will be needed and used.

Thank you.

 

@mcoted3d @antoine-unity : This features is broken in Unity 2022.2.0b13: all sprites are rendered solid white when they are part of an SpriteAtlas. Sprites are rendered again as expected once SpriteAtlas is deleted. Bug report:
CASE IN-21747

 

It is indeed fixed, but not working as expected: I am getting a view into the packed SpriteAtlastexture, instead of the sprite. From left to right in the attached picture: (1) what I get (2) what it should be (3) relevant portion of AtlasTexture:


I imported individual png (texture importer settings: Sprite (2D and UI), packed them into an SpriteAtlasV2, and get the Sprite in the UI Manager like this:

Code (CSharp):

1. svg.style.backgroundImage = new StyleBackground(pointAtlas.GetSprite("BOYLAT14"));

Outside of UIElements this way of acessing the sprites from the SpriteAtlas works as expected.

 

Is your triangle sprite mesh type is Full Rect and you use tight packing with your sprite atlas?
Change your sprite mesh type to tight or don't use tight packing with your sprite atlas, may fix this problem.

 

Your suggestions work, however I believe it's still a bug of 2022.2.0b15, as there is no such issue in 2021.3.12f1. The picture in the first post of this very thread here does not look like that in 2022.2.0b15. Will wait if @mcoted3d has an idea in this thread here, if not I can submit the very project from post number 1 as bug report.

BTW here detailed setting that make the issue go away: (1) changing mesh type from tight to full rect. Or (2) removing "tight packing" option of atlas. Bot options I like to avoid as it blows up the texture size significantly for my >600 sprites.

 

Try to open the package from the first post of this very thread here in Unity 2022.2.0b15 and 2021.3 and you will see the difference: In 2022 some sprites (e.g. the AxeDouble) show fragments from other sprites, no such issues in 2021.3. See upper right corner:

No, misunderstanding: In that package (and in my project) sprites have Mesh Type "tight", the atlas is packed "tight", and the VisualElement loading the sprite as background has scale mode "stretch-to-fill".

BTW: the minimal project I submitted under CASE IN-21747 is nothing else but the package from the first post, so you can use that for reproduction in case that is easier with your internal QA logistics.

 

Hello there, how do you install this in version 2020.3.37f1 ?