Antoshidza
commented
3 months ago Yes, list of sprites is a good way to go, but it isn't as performant as use solid sprite sheet texture. It is possible to animate sprite by not shifting UV but instead picking corresponding UV from frame list. There are many things in sprite rendering workflow which may have several approaches, but in NSprites-Foundation I choose to implement minimal well optimized version of systems to give an example.
So in case you want to rewrite animation workflow to be able to animate frames which are not the part of the solid spritesheet OR are part of sprite sheet with dynamic offsets then you need to introduce blob array in animation blob asset which will store each frame UVs instead of calculating those UVs depending on frame index, texture size and frame count (how it works for now).
The benefits are:
- UV animation system code is much easier
- You're able to use any sequence of any sprites, just make sure sprites for same animation end up in same texture atlas The cons:
- You now need to store blob array for each animation
- Your authoring code now little bit more complex
I have a Unity 6 project with this setup...
... and I pulled ...
... into my project with success. Great work!
Just an FYI that I'm finding it challenging to take spritesheets I find online and use them well.
PROBLEM:
The common problem is that the animated asset appears to drift (in the x position) in the running game. I think this has to do with the incompatible dimensions of the original artwork compared with the
framecountvalues on theSpriteAnimationobject from your system.WORKAROUND:
Manually crop the source image and/or to add/remove deadspace between each sprite in the spritesheet.
SUGGESTION:
Embrace the output of the Unity Sprite-Editor. This could mean allowing your system to take a list of sprites (generated by the sprite editor) instead of ONLY accepting the sprite sheet. That way all the various workflows of the sprite editor (rows/columns vs automatic vs other...) can be taken advantage of.