Dengar

https://github.com/Dharengo/Spriter2UnityDX/raw/master/Packages/Spriter2UnityDX.unitypackageTry again, I think you'll be pleasantly surprised. As I said, the issue had nothing to do with whether or not the sprites are connected to any bones. It was a parenting mismatch. Basically I wasn't very thorough in caching the transforms. I thought I was using identifiers that were unique, but they actually weren't. I updated the code to use (hopefully) truly unique identifiers. As for the resizing issue. That's Unity getting derpy with negative Scale values. I need to think about how to handle the math. Maybe I can search the original S2U for inspiration.

Are there any wishes you have for the converter in order to finally make the switch? Is there still any unexpected behaviour? Also, would you say about the tool's extensibility? I haven't really written any of the comments because I was focused on making it work, but if I was to provide some comments here and there, would you say the code is easy to work with?

I am sorry. For some reason it did not get pushed to the online repository. Download it again, it should be the correct version now.

I didn't DO anything with the alpha channel. I just removed unused sprites from the equation, so the alpha mutations are actually visible now. As for your problem. I'm not sure what to tell you. I cannot replicate it. I even deleted the prefab and reimported the .scml file, and I'm not getting the problem you describe. EDIT: After deleting your whole project and reimporting it all, I was able to replicate the problem. I was acidentally setting the sprite MODE instead of the sprite ALIGNMENT. https://github.com/Dharengo/Spriter2UnityDX/raw/master/Packages/Spriter2UnityDX.unitypackage This version shouldn't do this anymore. However, I don't think it will fix the current state of your textures. You can do two things: Manually: Go to each texture, set the Sprite Mode to "Single" and the pivot to "Custom". That should fix it. Automatically: Make sure to have the textures (without the associated meta files) somewhere outside your Unity project. Then delete the textures from your project, then re-add them. Then re-import the .scml file.

https://github.com/Dharengo/Spriter2UnityDX/raw/master/Packages/Spriter2UnityDX.unitypackage Yet another update. You're going to love this one. Now only shows the body parts that are actually used in the current animation, and hides the ones that aren't. Please tell me if your "alpha issue" is still a thing. Because now that the screen is less cluttered with unused body parts, I can actually see some alpha activity. I'm fairly sure I haven't worked out all of the issues yet but we're getting there now.

Oh no I fixed that a long time ago. Position x/y values are 100 times smaller in Unity than they are in Spriter. Likewise, Spriter's rotation uses euler angles whereas Unity uses quaternions. Also, animation time in Unity is measured in seconds whereas in Spriter it's measured in milliseconds. EDIT: https://github.com/Dharengo/Spriter2UnityDX/raw/master/Packages/Spriter2UnityDX.unitypackage Sorry for the delay. I had work this afternoon so no time to work on it. For the time being, no longer disables any of the parts. This means that there might be an excess of sprites at certain times. Anyway, try it out. Import package, re-import your .scml. Note that it might take a few seconds to modify all the different Sprite assets, but once it's done, all the sprites should be where they belong. Also it only needs to go through this process once unless you change the pivots again. I also did some thinking about your "alpha issue" and I'm starting to believe that this might not have anything to do with the alpha directly, but rather the way the animations are "completed". I'll look into this some more later. There also seem to be some issues with the sprite swapper, but I think for now I should actually be focusing on dealing with different animations using less/more sprites.

lol, I tried to import your .scml file and all of the sprite's locations are completely out of alignment. I wonder why that is. O_o The alpha channel VALUES actually do change. It's just that for some inexplicable reason the texture remains visible. This is going to take some time to figure out but I will eventually. EDIT: Ohhhhhh.... There is now one thing I get! I haven't solved the alpha problem yet, but I do have a hunch about why all your sprites are out of alignment. My importer does not actually take irregular pivots into account. :o In my own testing scenarios, all of the textures just had the pivots in the center. This requires some thinking. I believe this is fixable. Maybe I can use the same mechanic that sets the texture import type to sprite to set the pivot.

As for your "boneless sprite" problem, I'm not sure why it does that, although I probably know WHEN it does it. It's part of something that I originally thought of when thinking about "Sprites that aren't present on the first frame of the first animation.". I'll turn that feature off for now during the next update because I probably will be taking a different approach. As for your alpha thing, I really don't understand what's up. It works fine on my end. If you've tried various things and the problem still persists, would you mind sharing your scml file so I can take a look?

https://github.com/Dharengo/Spriter2UnityDX/raw/master/Packages/Spriter2UnityDX.unitypackage Introducing: The Sprite Swapper. As I mentioned above, it is a Script Component that is added to a child Sprite object whenever it's necessary. If a particular body part only ever has one texture, there is no need for it. If you want to swap the sprite at runtime, just use a script to change it directly on the object's SpriteRenderer. If the animation cycles between textures (say, for example, for different facial expressions), don't use the SpriteRenderer, it will be overridden by the SpriteSwapper component. The Sprite Swapper component contains an array of Sprite objects, each of which corresponds to one of the possible textures for that body part (such as the different facial expressions). If you need to change these at runtime (for example you have textures with a different skin color), just replace them in the array, like so: SpriteSwapper swapper = GetComponent<SpriteSwapper> ();swapper.Sprites [0] = myNewSpriteReference; Do this for every texture in the array. Hopefully this will be a good help to you flexible programmers who like to switch things up through code. Note that this implementation does not take care of textures that are added "out of nowhere" mid-animation, or in different animation. That implementation does not exist yet. I still haven't quite decided how I'm going to tackle that problem. Probably a similar technique I use with the Sprite Swapper.

The alpha channel should actually change according to what you set in spriter. Are you setting the alpha channel on the textures or on the bones? Bones have no renderer in Unity, so changing the alpha on those doesn't do anything. Sprites with no bones? I'm going to have to test this. I'm actually working on something really neat. It required a lot of wrestling with undocumented code and math I don't know the first thing about, but I've actually finished a prototype Sprite Swapper. It already swaps sprites during animation, but I also need to take into account sprites that are used in various different animations. It's a very easy to work with Script Component that's automatically added to any body part that uses multiple textures. It holds an editable array of sprite textures, with a numeric value that corresponds to the currently displayed Sprite. If you want to change body parts at run time, for single sprite body parts you can just change them in the renderer. For multisprite bodyparts, change them in the Sprite Swapper instead.

https://github.com/D...DX.unitypackage Hopefully fixed the above issues. Once again, I hope someone will check this out and play with it a little to find any irregular behaviour. In addition, Animation assets should now have their loop types set correctly. Also introduced a new feature: AnimatorController! On the surface, this is almost identical to what the previous edition did, with a few differences: -Instead of accessing the Asset Database to find an AnimatorController, it checks whether or not one is already attached to the prefab. -It never removes or replaces anything that's already present in the AnimatorController, although the AnimationClip assets involved might get updated. -It WILL add new states for new AnimationClips. -If it finds an AnimatorOverrideController, it will be smart and modify the underlying AnimatorController -Only if there is no AnimatorController attached to the prefab, will it create a new AnimatorController and then attach it to the prefab. The idea is that the converter should not undo any custom modifications made by the user. For example, if they use the same AnimatorController for multiple entities, or if they use AnimatorOverrideControllers, this structure should not be broken by the import process. Note that most of the above is untested, but it should work in theory. I'm excited to find out if it all works as intended. I'm thinking of adding a menu item of some sort that opens a little window that lets you automatically generate an AnimatorOverrideController from a Spriter Prefab. I still have to say one thing I really like about this is that for the AnimationClips, it ONLY adds curves for things that actually change. It really helps alleviate my obsession with redundancy. :P Now, regarding the swapping of sprites (through animation, I mean stuff like maybe a blinking face, or a hand opening or closing), I'm kinda torn between what approach I would take: -I could change the texture in an AnimationCurve. This is the "cleanest" way but it introduces an issue for users who want to swap textures through script (for changing clothes or weapon skins), because they'd actually have to edit the AnimationClip's curves at runtime. -I could do the same as above, but add a little script that gives the user easy access to change the sprites. I am, however, a little unsure how this affects multiple instances of the same prefab. -I could use AnimationEvents. This does, however, require that I create a Script Component that stores references to all the sprites. The benefit of this, however, is that to change the sprites, all the user needs to do is mess with the references on that Component, and the AnimationEvents take care of the rest. One VERY big flaw about this though, is that every time you re-import the .scml file, all of the AnimationClip's AnimationEvents will have to be wiped clean and then re-added. The result of this is that any user-defined AnimationEvents will be lost. -Forget about changing the sprite's texture at all, and experiment with multiple GameObjects. This will enable the user to swap textures at runtime simply by accessing the SpriteRenderer component on each child GameObject. This approach will likely require the most code and the most experimentation, however. Another problem with this approach is that the child renderer's enabled state will from then on be controlled by the Animator, which introduces similar problems as having the Animator control the sprite's texture. Unlike the above, some kind of workaround may be found by inventing a special Script Component, but we'll have to see how convoluted that ends up being.

I've never seen this error before. And I've deleted my prefabs and recreated them countless times. Besides, that code that you pointed out is supposed to run when there ISN'T a prefab file.

If anyone feels like testing a few things: https://github.com/Dharengo/Spriter2UnityDX/raw/master/Packages/Spriter2UnityDX.unitypackage It's far from done, but the basic things should be working: Disclaimer: This is a test version, this is not a finished project. I still would like to see some feedback, however. What it DOES do: -Automatically convert textures to Sprite if it hasn't already -Creates the prefabs -Creates animations (they are nested inside the prefab) What it does NOT do: -Create an AnimatorController; this is probably the next thing on my agenda, but for now you'll have to create one yourself Currently supported animation curves: -Position -Rotation -Scale -Alpha No changing the sprite texture at this point in time. Will be pretty soon though. Just import the package and play around with it a little. What I'm mostly interested in is whether or not there is any irregular behaviour.

Progress report: I was able to craft an animation through scripting (work in progress). As it turns out, Spriter uses different values for things like position and rotation, so I'm going to have to come up with some translation algorithms (probably based on the original Spriter2Unity). As promised, only curves for which any mutations exist are added to the animation. This should eliminate a lot of those redundant curves that just stay completely identical throughout the whole thing. Mutating transform position works. Rotation: not yet, I think it has to do with Unity's eulerAngle cap but I think that can be easily fixed. Scale or any other properties: Untested. One thing I'm really surprised about so far: The code I've been using is surprisingly compact compared to the original Spriter2Unity. I'm not sure why this is. Maybe I'm just overlooking a whole bunch of things, or the original was just overcomplicating things too much. I don't know.

Oh I've heard of this problem before in one of the previous threads. That might have to do with some changes in Unity 5. Before Unity 5, some hacks were needed to make building animations possible but that's no longer necessary.

Thank Bonus2113 and alaa-eddine for that. I just worked out the weird warning messages. I think part of it has to do with Unity 5 as well since it made certain hacks unnecessary. The new version I'm working on may or may not be even faster. Oh also part of it might have to do with the fact that your textures are already imported?

Hehe, thanks for the support. One thing I'm thinking about in building these animations is to only add curves for items that actually change their state over the course of it. That should also make it less of an issue to use Unity's nifty feature to combine concurrent animations.

That.... works? I guess? It's not a very elegant way of doing it, mind you. I mean you're basically playing tug o' war with the animator. The animator changes the sprite, you change it to something else. The animator changes it back, and you change it back as well. This is one of the problems I intend to fix. The new version of the converter really should determine the sprite through scripting, not by force through the animation. I don't think I'm going to implement Character Maps right now, but I do want to make it actually possible to be implemented at a later point (perhaps by someone else). With the converter as it is, that's just waay to much work. I want my new tool to be extensible. But at the very least, the sprites should be swappable through script, and the Animator should not interfere with that. That's my philosophy anyways.

So anyways, contradictory to what I have been saying for a long time now.... I've actually been working on the converter. Kind of as a side project to prevent myself from burning out on the main one. As part of the exercise I kind of decided to build the whole thing from scratch and do something about the huge maze of classes and method calls that might make it rather intimidating for other developers to work on it. There is no real logical reason for this, it's mostly a learning experience for myself, but if something comes out of it, it'd be a nice boon. One big thing I've changed is the method by which the Scml data is parsed to C#. Originally, during every step of the process, the necessary data was read from the .scml file at every step. I've always felt a bit awkward querying data files directly (requires lots of lines of code to achieve relatively little), especially when it has to happen often. So instead of that, I parse the whole thing to a ScmlObject class instance in one swoop, then access the necessary data in that. It may be a personal thing, but I find it much easier to work with a C# class than it is to work with a data file. Anyway, as for my progress so far: I've been able to replicate the part of the import process that creates the physical Prefab. As far as I've tested, all the bones and textures are in place. I haven't started on building the Animation assets yet, but I did add a really cool feature that automatically converts your texture data to the Sprite format if it's not already in a Sprite format. So no longer will users who use the converter expect to see their sprite, only to see a bunch of empty looking GameObjects without knowing why. Building Animation assets seems like a fun task but that might take a little while to get right. I'll keep you guys posted though.

There actually used to be an implementation for that. I am in fact quite unsure why it has been taken out. That said, your sprite texture is probably being set by the Animation asset. So if you want to change it, you have to change it on the Animation.

Thanks for the swift answer. I know enough for now, but I'll keep that in mind. Thanks.

Out of curiosity, since I find myself fiddling with the Spriter API for Spriter2Unity, is the link in the first post still valid/recent and the whole thing to work with? Just curious and making sure.

There is a new topic up. In any case, you should be able to modify the transitions manually to happen instantly. Just select the transition in the Animator and you should be able to modify it from the Inspector.

Whether or not these issues will be resolved mostly depends on whether or not someone is going to resume active development on the converter. I simply do not have the time for it. I just make some minor modifications to suit my own ends. That said, should I run into that issue myself and see the need to resolve it myself, I will take matters into my own hands. But I can give no ETA on this, or whether it will happen at all. I'm sorry to say all of this. However, you are welcome to take a crack at it yourself.

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. Previous thread: http://brashmonkey.com/forum/index.php?/topic/3365-spriter-for-unity-43-updated-integrated/ Old version: https://github.com/Dharengo/Spriter2Unity Even older version (Unity 4.x compatible): https://github.com/bonus2113/Spriter2Unity UPDATE: 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: Spriter2UnityDX 1.0.3 GitHub Link: https://github.com/Dharengo/Spriter2UnityDX Anyone is free to fork it and do their own work. If it's pretty good stuff I'll merge it into the main branch. Package Link: https://github.com/Dharengo/Spriter2UnityDX/raw/master/Packages/Spriter2UnityDX.unitypackage Use instructions: !!!Requires Unity 5.x!!! 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) Known Issues: -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. ChangeLog: v1.0.4: Fixes: -AnimationEvents are now preserved between reimports -SpriteSwapper renamed to TextureController to avoid confusion -Fixed a z-position issue with the SortingOrderUpdater v1.0.3: Fixes: -Fixed an issue where flipped (negative-scaled) bones caused child sprites to appear out of place and in odd angles Features: -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 v1.0.2: Fixes: -Fixed an issue where sprites appeared distorted when resizing bones -Exceptions are wrapped up nicely and no longer abort the whole process Features: -Now adds AnimationClips to existing AnimatorStates if they exist -Autosaves no longer trigger the importer v1.0.1: 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