What I mean different is inefficient when the game runs.
sprite sheet:
put multiple files in one texture file, and import it to unity, I only import one texture.
sprite packer:
import multiple files in unity, then use the sprite packer to pack it into one texture.
So what is the difference between them? which one is better for sprite animation?
thank you!
In terms of frame rate you will have little to no effect. However in terms of memory, you may see an effect because the sprite packer will be able to deal better with animations that have flexible size.
With sprite sheets, Im assuming you mean atlases that are made up of fixed sized cells. There is no problem with this approach, unless your animation varies dramatically in size, making it necessary to increase the overall cell size to cover the area of the largest animation frame. You would end up having huge amounts of 'empty' and thus wasted space. This is bad since on mobile memory will be your problem.
In general sprite sheets are ok for animations that fit into an efficient cell size, like animated characters:
With the unity sprite packer you wont have this problem, since it will 'pack' the wasted empty space together and create an optimal atlas, hence the name 'packer'.
You can see that in the documentation:
The explosion (or whatever it is) is clearly using optimal space. In a sprite sheet, you would be having to create cells the size of the largest explosion.
In terms of programming ease, using sprite packer you may have to add a bit of code to correct for the original sprite size, so the animation will run smoothly at the 'anchor point'. With sprite sheets, you avoid this by having the fixed cell size.
Related
I created a 2D sprite animation using the 2d animation package and the 2D Ik package. My character is one sprite sheet (PBS file). In the PBS file all the spites (eyes, mouth, etc, - character is basically a square with a face) are arranged and bones are attached. Then I animated the character's idle animation in Unity.
The animation is complex and is a total of 1028 frames (about 17 seconds).
The scene is almost empty otherwise. There are a few sprites with colliders and rigid bodies for simple platforms. There is a background image which is 1024 px. x 1024 px.
In play mode the FPS drops down to around 30 FPS (and under).
I have another scene without the animation but with a HUGE number of assets (for a 2D scene hundreds of sprites and many of them constantly in motion). This scene runs at 210++ FPS consistently.
Why does this one animation kill the FPS? I'm just getting started with creating animation for all the characters. If I add similar animations to NPCs in the scene (enemies) then this thing will probably not function at all.
Any suggestions are appreciated.
For anyone having the same issue, make sure you have Burst and Collections packages installed (via the Package manager), it extremely improves the performance of 2D Animation.
So I spent a couple of days this week and created sprite sheet animations to replace the skeletal animation I made in Unity. As I suspected, the performance is light years ahead. I have MORE animations now and some of them are as long as 270 frames. Yet I consistently see greater than 220 FPS. It's too bad that unity's 2D animattion package is so slow. To accomplish the same animation I was looking for, I ended up rigging and animating my character in Blender 2.8 using Andreas Esau's COA Tool (Cut-Out-Animation Tools) Add-On.
COA Tools is an awesome tool but I wish it could export a rendered sprite sheet to Unity. I ended up exporting each frame as a separate image and using TexturePacker to make the 2048px square sprite sheets I needed. Once I got the sprite Sheets into unity I was able to quickly set up animation clips and test it out.
As I said, the sprite sheets are far and away better than animation created directly in Unity.
If you bothered to read all the comments on my original post, I will say that there are a lot of scripts running and a lot of computation happening. It is there in the profiler for sure. But this was definately not the main culprit for taking down the FPS. It was absolutely the animations.
Looking at your profiler screenshot, SpriteSkin.LateUpdate() takes a large chunk of your frame time. To reduce the amount of time CPU spends on deformation, you can limit the number of vertices in that are used for each Sprite Part - you can adjust it in the Skinning Editor with Edit Geometry tool. Basically, the less the amount of vertices the better the performance.
Also, make sure that each Sprite Skin component has the Enable Batching option enabled. This will enable Burst and Collections packages to speed up calculations. For more details, checkout this 2D Animation documentation.
Recently, Unity a free ebook was released that covers in details best practices and how to prepare art for 2D animation. You can find it here.
In current Unity,
For use in Unity.UI as conventional UI ..
for any "Sprite (2D and UI)", in fact it always defaults to having "Generate Mip Maps" turned ON. Every time you drop an image in, you have to turn that "off" and apply.
As noted in the comments, these days you can actually use world space UI canvasses, and indeed advanced users may indeed have (say) "buttons that float over the head of Zelda and they are in the far distance". However if you're a everyday Unity user adding a button, just turn it off :)
In Unity, "sprites" can still be positioned in 3D space. For example, on a world space canvas. Furthermore, mipmaps are used when the sprite is scaled. This is because the mipmap sampling is determined by the texel size rather than the distance.
If a sprite is flat and perfectly scaled then there is no reason to use mipmaps. This would likely apply to your icon example.
I suspect that it is enabled by default for 2D games where sprites will often not be perfectly scaled. To clarify, a sprite does not need to be on a canvas. Sprites can exist as their own GameObject with a Sprite Renderer (not on a canvas.) When this is the case, scaling the camera view will change the sprite's size on the screen resulting in mipmapping due to the texel size changing. This results in making the sprite always perfectly scaled challenging without a canvas.
I making a 2d game and I am having some very random problems... My sprites are not displaying as they should be. Below is a screen shot of what I see when I run my game. This bug is present in the game window and the scene window, both when the game is running and not running. And the glitch is not because of the tiles being offset (The background is made up of tiles), if you look closely the player sprite is also glitched up. I have tried restarting unity and my computer, one of which has worked. I have been having this problem ever since i started using tilesets (using one PNG image and cropping out smaller sprites by setting the sprite mode to multiple, instad of using just one PNG image where there is only one sprite and the sprite mode is singular). How do I fix this? (BTW I am using Oryx's lo-fi fantasy and sci-fi sprites at www.oryxdesignlab.com)
This happend when your atlas is not sliced correctly. When you making 2D game there are several important things about sprites.
Set Filter Mode to Point
Set Fromat to 16 bit or TrueColor (in special cases)
Make sure that your atlas is sliced properly.
Edit:
Adjust "Max Size" - make sure is value represents number equal or bigger than spritesheet size
The best way in sliceing atlas in Sprite Editor is NOT to use automatic. I got glithes like that in my project too and those steps can eliminate them.
Have a look at your Sprite in the Sprite Editor. I think you can get to it by double clicking.
Your sprites will have sort of boxes around them to identify each individual sprite (if you set your texture to multiple). One of these boxes will not have sliced correctly, and will have overlapped into another sprite, hence why you're seeing what looks like the arm of another sprite in your picture :)
I'm making a 2d board-game-style game in Unity 5, and I have a prefab made up of a couple of sprites which represents a game piece. I want some text in my prefab that I can update as the game progresses.
If i try to add text, it requires a canvas, but when I create a canvas, an extraordinarily enormous canvas is created, that looks to be at least 1000x times bigger than by camera area. If I try to place this canvas inside my prefab, my prefab is now made of an enormously huge canvas, and my tiny sprite images. This makes the prefab impossible to position, or calculate sizing or animate, or anything else I want to do.
How can I add text to a prefab, and make the text contained within the size of my prefab spites?
Here's what I have tried so far:
if I set the canvas for the text to "Render Mode: World Space" I'm able to make it's rect tranform smaller. However, if I get it as small as my sprites, the text becomes an unreadably blurry mess. I guess this happens because my sprites are literally at least 1000x smaller than the canvas, so when I zoom in enough to even see the sprites, the text has been zoomed into oblivion. My sprites are so much smaller than the canvas, that if I am zoomed out to see the full canvas, my sprites are not even visible.
I'm able to kind of make things work if I recreate my prefab using UI Images instead of sprites. This way, the UI Images, and the text are both UI elements contained in the enormous canvas, so the size disparity doesn't exist. However, I don't know what the pitfalls are going to be trying to build an entire game out of ui images instead of sprites. Do I get all the state capabilities of sprites?
The canvas Unity generates that is 1000x bigger is used for GUI related objects that are not meant to directly interact with the game world like the score or buttons. In order to have moving text, try using 3DText. Have the text face the camera so that the text appears to be 2D. You can find this option in the menu under
GameObject => 3D Object => 3D Text.
From what I understand, all you need to do is parent this GameObject to your prefab and do some script magic at runtime.
For high fidelity text, either decrease the character size or increase the font size or do both.
Note: A larger character size reduces fidelity, but will take less processing power.
Source: Unity 5.2.0f3
In Cocos2d v0.99 there's a class named CCSpriteFrameCache. I can load all the sprite frames
[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:#"images.plist"];
and then I can use those loaded frames
CCSprite *sprite=[CCSprite spriteWithSpriteFrameName:#"img01.png"];
Now my question is: Do we create a big sprite sheet that will hold every single image that we're going to use for animations? I mean, I thought I'd have several sprite sheets for different animation objects. If this question is answered NO,so that I load each sprite differently, then my second question is how do I refer to a frame in a specific sprite sheet?
Now my question is: Do we create a big sprite sheet that will hold every single image that we're going to use for animations?
yes, or you can have multiple sprite sheets if you have many different frame images...
I mean, I thought I'd have several sprite sheets for different animation objects.
It depends on the size of the resulting sprite sheet. In principle it is convenient to organize the different frames of the same animation within the same sheet, but if your frames occupy, e.g., 600x600, your sprite sheet will occupy the same memory as a 1024x1024 sheet, so you are better off adding some more frames to that same sheet, even if it belogs to a different animation. In general, you can play with the sheet size, as long as both dimensions are a power of 2, you will not have inefficiencies as to memory occupation and you can organize your frames into different sheets if that makes sense to you.
If this question is answered NO,so that I load each sprite differently, then my second question is how do I refer to a frame in a specific sprite sheet?
by the original filename that was composed into the sprite sheet...
hope it helps...
If possible, cram as much images into as few texture atlases as possible. The determining factor is quite often z ordering. If you have two atlases and two sprite batch nodes, then each sprite batch node can only render their sprites on their z order, while the sprites in the other batch node are either always in front or behind.
You do not need to know which texture atlas (sprite sheet) a sprite frame came from. Just reference it by name. If you need to know which texture the frame refers to, check the sprite frame's texture property and compare it with the texture property of the sprite batch node.