My approach so far, when exporting 2D character animation sprite sheets, has been to crop each animation cell as close to the pixels as manageable, leaving as little 'empty" air as possible in the exported in each sheet.
So for example the Idle animation sprite sheet cells might be 70x61 pixels
The Move sheet cells might be 86x73 pixels
The Attack cells might be 103x90 pixels
An annoying snag with this is that when I slice the sheets up in Unity, I have to manually adjust the pivot point for each animation to make sure the character position stays consistent when the character switches between animations.
I am considering a new approach instead, but I’m not sure if there are some potential hidden cons tied to it.
Using the same 3 animation examples above, the idea is to make all of them a fixed 128x96 pixels. This way, when slicing in Unity I can just set the pivot to center bottom for all 3 animations and never have to worry about them not lining up in game. But, obviously, this means there will be an excess of empty space (transparent pixels) and the sprite sheets will be overall larger file sizes.
Are there performance issues to the second approach? Besides increased file sizes, obviously.
Always start by using the profiler:
Window → Analysis → Profiler
Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.
Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.
https://discussions.unity.com/t/841163/2
Notes on optimizing UnityEngine.UI setups:
https://discussions.unity.com/t/846847/2
At a minimum you want to clearly understand what performance issues you are having:
- running too slowly?
- loading too slowly?
- using too much runtime memory?
- final bundle too large?
- too much network traffic?
- something else?
If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.
Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.
This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.