SpriteAtlas thoughts

Hi there,


I really enjoy the new 2D features coming along in this preview!

But I have to say that the atlas packing itself needs some work. The principle is good and I like the more Unity style approach of having assets that represent atlas files. The invisible atlas process with the packing tags was good but also was unique and not the easiest to grasp.

Will the old system be deprecated? I think it would be better to do so.


I assume the SpriteAtlas inspector will still get some love and is not yet finished. But here are some things that I want to see:

1. Add a workflow where I only need one drag to add a new sprite, collection of sprites or directory of sprites. At the moment you have to always add an entry to the list and then you can drag new entries on it. A simple drop area that automatically adds a entry would be enough.
2. Display information about the preview texture: pixel size, file size, used space in %, etc.
3. Platform independent settings

How can I know which Atlas a SpriteRenderer in the scene is using? The SpriteRenderer should maybe have a adjusted field to display the currently used atlas. Since two atlas files can have the same sprite it is not clear.


Thank you for all the hard work. By the way, how many people are working on these features?


Robin

reference picture to the SpriteAtlas inspector I am referring to attached.

 

Thanks for the suggestions!
- There are no plans to deprecate the SpriteTag system at this time.
- Currently you can drag onto the "Objects for Packing" text and the entry will be automatically created. This is currently the default Unity behaviour. We're looking at making it better though.
- Yes the SpriteAtlas Inspector is still work in progress.
- Looking into the other suggestions.
- Currently the 2D team is 11, including QA and myself.

 

You are right. I overlooked that you can drag atlas elements on the label/header of the List 'Objects For Packing'. I was thinking more of something like the attached image.

Cool, I wish you great success

 

Hi Johaness and Paul,

I would also prefer bigger area for dragging things there. Should be placed above the array.

Also would be very handy to have some kind of sorting ( By Name, By Size , By any suggestions ? )

Also as I mentioned in our skype. Please think about to have possibility to set MaxSize for the atlas so that we can get smaller build if we need them. For example for desktop I will keep 4096 max size ( don't mix it with physical size of the atlas is max size like for texture ) but for mobile I will say 2048. So actually produced atlas texture should have completely same parameters exposed like normal texture so that we can set max size and other attributes.

Also can you share more info about that Master Atlas thinking. I would love to start to prepare our tool for that.

Question that comes up. How max size will be applied to Master Atlas? Seems like master atlas will be only dock for sub atlases for which we need to set max sizes individually!!!

This atlas asset is really great I look forward to have it in production. Please guys. Move forward. 9 slice and atlas asset first then the rest.

 

@Johaness_Reuben I haven't tried any preview builds but have you considered an Atlas exposed class with it's sprite list? it's a pain in the ***** not being able to resolve a sprite from code without dragging it to a script. The only choice is to having them on a Resources folder but that way it's not packed into an atlas and draw calls gets multiplied.

With old UI systems like NGUI you could resolve sprites from a atlas by a relative path: "myFolder/mySprite".

It's something that from 4.6 I have seen like a missing feature because of that internal magic atlas generation and management.

 

Simple question. When? ;-)

 

Another great feature would be linked atlases. It would be useful for two things... one example is using normal maps with sprites. Another example is having multiple skins for sprites that you could swap between.

The basic idea is to allow the same sprites to be used on multiple textures, and you should easily be able to swap which texture(s) are being used for a material. The atlases would all be packed with the same layout.

 

I appreciate your honest response. I don't think skin swapping is a "high-end 2D graphics" feature. I currently do it just by swapping sprites in late update, but it would be easier and more efficient if I could just swap the atlas once. Yes, normal maps are "high-end", but I think more people would use linked atlases for skin swapping.

 

Yeah, this response is a bit odd. Think about the current use-cases for sprite atlases:

Characters
Swapping Characters
Environmental / VFX treatments of game object and interactible objects

VFX animations

and so-on.

Having an easy to generate/replace atlas enables responsive, adaptive gameplay that is very common in 2d presentations.

 

I was hoping you would have algorithms sophisticated enough to handle different shapes. If you are talking about the mesh, maybe just require people use full rect? I'm sure you could figure it out. You would just have to set specific limitations and communicate them to the user.

Edit: Actually, I think you should require that the sprites be on a sprite sheet which we will refer to as the base texture, and require that the linked textures be the same size as the base texture. The linked textures would just be dragged onto the atlas asset maybe in a section called linked textures. You would just use all of the data from the sprites defined in the base texture, and since the linked textures would be packed into their own atlases, you could just swap between them.

This is not as easy as you make it sound. You would have to keep track of every sprite reference in the entire project, including animations. I don't even know if Unity allows you to modify sprite references in animation clips at runtime. And think of other things than Sprite Renderers that use sprites, like UI and tile maps.

I agree you should be doing things that are hard to do, which is why I recommend doing this. There is no good built-in way to do it, and swapping atlases is the perfect solution. Why would a swapping system not be universal? It should just swap a texture.

I think people would also like to use this for swapping tile sets. I told @keely I didn't think he needed to implement a tileset swapping system because I figured swapping atlases was a no-brainer and would be included.

2D Toolkit, which I'm pretty sure is made by one guy, has this feature. It doesn't seem like using Unity's built-in features should be a downgrade.

 

This is a cool feature, but when I try to use a sprite that was packed into a atlas VARIANT which was scaled down by 0.5, by directly using a sprite reference from my Assets folder the sprite is not rendered properly (I see the entire atlas texture being rendered instead of just that sprite), trying with the MASTER atlas worked as intended.

Next I tried to get the sprite from the Atlas Asset directly, but it gives the same result, with the MASTER atlas it worked, but on the VARIANT atlas the entire atlas is rendered instead of just the sprite.

For the master atlas, I unchecked "Include In Build"
For the variant atlas, I checked "Include In Build"
I have checked to make sure I linked up the variant with the master atlas properly.

I am on the OSX platform, developing for the iOS target platform.

Is this a bug?

Oh, I am on the Unity 2017.1.0f3 btw, the released version

 

@ldhongen1990
Could you file a bug and we'll check it out. Thanks.

 

The new sprite atlas seems like a great improvement on the packing tags. I didn't use the previous method because I really needed the read/write option, so I'm really glad to see it included. Am I right in thinking that this atlas doesn't exist as an image file anywhere that can be edited? The ability to edit the entire atlas (for example, change a colour throughout all sprites) would come in really handy.

One thing I can't get my head around is how to access the sprite uvs from a new sprite atlas. I'm used to accessing the sprite uvs from an atlas by using the sprite's pivot and figuring out the correct uv from there, but with this new system I don't seem to be getting the right results. I have Tight Packing, Allow Rotation and Compression off. Is there something I'm missing? I'm using the 2017 beta .2.0b4

 

Will there be ETC1 Compression with split Alpha Channel support in the Sprite Atlas?

 

@Romano
That's the correct, it is not an image file. The colour change example, are you thinking of doing this at edit-time or run-time?
On getting the UV's. Could you elaborate a little more on why and how you're using it. We'd like to understand more on your use-case.

@vzlomvl Unfortunately Sprite Atlas will not be supporting ETC1 Compression with split Alpha Channel. You will need to use Sprite Packer instead.

 

@Johaness_Reuben Edit time - this is relatively easy to do in something like photoshop with a png sprite atlas. And useful for changing the colour of a character's clothing throughout an animation.

@Johaness_Reuben In my game I need to figure out if the user has clicked on a transparent pixel of a sprite. I've been getting the offset between the user's click point and the transform position, and then translating that into uv coordinates to get where the user has clicked on the sprite. Using GetPixel I can find out if the user has clicked on a transparent pixel. This method works on any other sprite atlas I use, but not with the new Unity one. Is this something that can be worked around or is there a bug?

Thanks!

 

Sprite Atlas is definitely a step in the right direction, congratulations on releasing it!
But is there any chance for an API that will allow to actually create atlases programmatically, not just define them as sets of sprites? Full control over the atlases - how many textures to create, where exactly on the atlas texture will the sprites be, their rotation etc. As it is now, both Sprite Packer and Sprite Atlas are black boxes - you throw sprites into them, and you get an atlas, but that's it, there isn't any control over how the atlas will turn out to be.
If there was an API that allowed full control over atlases, it would be easy to implement linked atlases (among other things) without it being a built-in feature. I'm already doing this in my project, but it is an insanely hacky solution that could break easily.
Just give us, users, the tools and we will implement that in no time

 

@Romano We need to investigate further if its a bug. Could you file a bug report? Thanks.

 

I very much dispute that. I'm using normal mapped 2D sprites for a mobile space shooter, and they work brilliantly on a Nexus 7 2013 which is far from a high-end device. The problem is Unity has such a backwards concept of sprites that combining sprites and normal maps is a disaster. I'm sure if it was easy to do anything more with sprites than just flat-shaded, devs would use those abilities, and it's not lock supporting some valuable features is much work.

Update the sprite material to include a normal-mapped option/variant, and improve the sprite atlasing to allow for associated sprite-sheets. Hell, give us the option to export a spritesheet and manually align the normals texturesif we must. Presently I can't use the sprite atlasing at all.

Having gone to the effort to upgrade to 2017 to use the new, more efficient Sprite Atlas methods, disappointment doesn't begin to describe it. I'm left still needing to roll my own resource library and burn through draw-cycles. Hopefully I can find something in the Asset Store that'll help.