Runtime overhead compared to what?
I've written the library to be as fast as possible (while still having readable code) and reduced memory allocations per frame to virtually zero.
However, if you have really a lot of animations you might have an impact on the CPU. The usual technique to solve this is caching computation results - like in the SnapshotAnimationDataProvider class. This drastically reduces CPU usage but uses more memory.
From my testing, the lib performs really well. The only slow down I noticed is on Android (with > 30 complex animations) and the Profiler pinpointed the ApplySpriterTransform method, or more precisely, various calls to Unity's API inside the method. Unfortunately, I don't know if there's another, more efficient way of achieving the same thing in Unity.
Regarding coroutines, I don't think it makes much sense to use them here since the overhead of calling Update is probably negligible compared to other processing. But if you get positive improvements, let me know and I'll be more than happy to update the lib.
IMPORTANT: BEFORE POSTING YOUR BUGS/ISSUES, PLEASE CHECK THE "KNOWN ISSUES" PARAGRAPH TO SEE IF I ALREADY KNOW ABOUT YOUR ISSUE. THE AMOUNT OF REPEATED REPORTS OF THINGS I ALREADY KNOW ABOUT IS GETTING KIND OF ANNOYING.
Old version: https://github.com/Dharengo/Spriter2Unity
Even older version (Unity 4.x compatible): https://github.com/bonus2113/Spriter2Unity
So I've decided to build an entirely new version of the importer from scratch. This enabled me to work with it way more easily. Hopefully other programmers will also find it much easier to work with now:
1) Import the above package into your Unity project. Just drag and drop it into your Project View.
2) Import your entire Spriter project folder (including the .scml file and all of the textures) into your Unity project.
3) The converter should automatically create a Prefab and an AnimatorController in the same folder that contains the .scml file.
4) When you make any changes to the .scml, the converter will attempt to modify existing assets if they exist.
5) If these updates cause any irregular behaviour, try deleting the Prefab and Controller and re-importing the .scml.
Differences from previous version:
-The textures' import settings are examined before building the prefab, and automatically set to the format that is needed to build the Spriter Entity.
-AnimationClips only contain curves for properties that actually change.
-When updating existing assets, priority goes to the AnimatorController that is actually connected to the prefab, in case you are using the same AnimatorController for multiple Spriter Entities.
-Body parts that have alternate textures (such as facial expressions) have an additional script component named "Sprite Swapper" on them which controls which sprite is displayed at any one time. You can manipulate this component at runtime to do fun things like give your characters alternate skins. For sprites that don't need a Sprite Swapper, you can just manipulate the Sprite Renderer.
-The root GameObject now holds an "Entity Renderer" which allows you to manipulate all of the children's Sprite Renderers simultaneously as if they were one sprite. Disabling the Entity Renderer will also disable all the Sprite Renderers, and enabling it will enable them again.
-Easily extensible, readable code.
(Currently) Unsupported Features & Future Ideas
-Automatically generate an Override Controller
-CharacterMap support (I don't have Spriter Pro myself though, and I know very little about this at this point in time)
-Dynamic Reparenting (changing the parent of a sprite during the animation will not be translated to Unity)
-Support for other Pro features (subentities, notably)
-Pivot points that are assigned on the canvas. Right now if you do this, your sprite will be misaligned when imported in Unity. I am planning on creating a fix for this on the next update, but not sure when that will be. For now, just set the default pivot point instead.
-On a related note, NOT setting any default pivot points at all will also cause irregular behavior.
-In some cases, the importer will endlessly loop. A workaround is manually setting your texture files to Sprite in the import settings. I have not figured out the cause for this but hopefully it'll be fixed in a future update.
-Bones that are added later during animations are perpetually disabled.
-The only supported curve types are smooth ones.
Warning: Only the basic features of Spriter are implemented. And most certainly none of the Pro features. That said, if you feel you're a pretty good coder, feel free to take a shot at implementing it yourself.
Warning: The tool as it is is very new. If you run into any unexpected behaviour, please tell me and I'll see if I can work out a fix.
-AnimationEvents are now preserved between reimports
-SpriteSwapper renamed to TextureController to avoid confusion
-Fixed a z-position issue with the SortingOrderUpdater
-Fixed an issue where flipped (negative-scaled) bones caused child sprites to appear out of place and in odd angles
-Added a toggle to the Entity Renderer that allows you to apply the .scml file's Z-index to the order-in-layer property of the Sprite Renderers
-Removed Spriter2UnityDX components from the Add Component menu, since they are automatically added or removed
-Fixed an issue where sprites appeared distorted when resizing bones
-Exceptions are wrapped up nicely and no longer abort the whole process
-Now adds AnimationClips to existing AnimatorStates if they exist
-Autosaves no longer trigger the importer
Fixes: -Fixed an issue where the Z-order would get messed up if body parts were moved during animation
Features: -Z-order can now be mutated by the animation
v1.0: Initial version
To keep it sane, you shouldn't aim to have the sound effects and colisions suported yet, thats very unity specific, what you should do is make sure the animations themselves are fully supported.
You guys need to have 'export to unity' as a builtin option, this is going to be your biggest userbase if you do.
These are some good links for the devs to look into:
I believe the spriter2unity implementation uses something similar to the last 2 links. I've tested it, not thoroughly though, and it seems to work ok so far.
I was one of the early supporters of spriter but I'm a bit undecided at the moment, maybe I'll buy puppet2d and use that instead.
I hope you guys come around and realize how important unity really is and include all sorts of unity specific features into spriter.
Alternatively you guys could contact unity themselves, and hook something up. They'll help you out.