A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Calling all New Unity users! Join the Halloween Mods Showcase Challenge until October 31.
Discussion in '2D Experimental Preview' started by rustum, Dec 17, 2018.
This is basic for a 2d animation system.
I really wish some information was being put forward about sprite swapping, even if it's a long way off - instead whenever its mentioned you're met with silence. The 2D Animation package remains virtually unusable for us (and I imagine most people) without it, it's such a crucial feature. It's been several months now with no new information. I mentioned before that having the skinning data tied with the Sprite itself (rather than separating the MeshData into its own object) is more or less the only thing that stops us from using it. The rest of the toolset is great.
Whilst I'm at it, I'll voice my concerns again about having all this information tied up in a single PSB/D; I think it could end up as quite a limitation. Unless the MeshData is separated out, anything that should be skinned on a character has to go in that PSB, which hurts workflow in innumerable ways (files get huge, which hurts version control, lots of objects end up in the base prefab where most will be inactive until needed at runtime - e.g. clothing/equipment, no straightforward way of appending to this rig/data once the project is built).
TLDR if MeshData was abstracted from the Sprite, in the mean time we could just roll our own sprite swapping tailored exactly to our needs and I wouldn't be checking this thread every couple of days
This is what I do also for this feature, and the bug I reported
I think the reason why they are choosing to ignore it is because they aren't ever planning on releasing that feature. They probably painted themselves in the corner with their implementation and it would take massive reworks to get it done from where the package is right now. What keeps them from responding is the fear of backlash after going back on their promise.
At this point I would advise you to act under the assumption that it's never going to be out (for your own sake), I've had similar experiences with Unity features in the past and if they are silent about something it's definitely a red flag.
I fear you may be right. The survey i mentioned is about where to spend Unity resources into next year and it did mention sprite swapping. So you would assume that first of all it will not come this year and secondly if not enough people vote for that option in the survey it may never be implemented.
So best thing we can do is take the survey and set the below option to very Important:
I just did so! I've started a personal 2D project last month and now have to make some early decisions on the animation system. Sprite swapping will be very important. I'm OK with waiting until next year, I can tackle the sprite swapping later on, but I need to know if using that package will come to be a very bad decision if it's never going to be made technically possible (meaning that at least, it could be done with a DIY solution - no fancy UI feature needed here).
I don't think it's been long enough yet to write off the feature as a serious improbability. It's been long enough without comment to be frustrating and worrying (historically, working in silence on a feature for too long without letting the community provide feedback hasn't worked out too well), but I don't think we're in a 4.6 UGUI situation where things have rolled into the indefinite just yet. I've been working with Unity long enough not to hedge my bets on in-preview features, but the silence could easily be down to concentrating on bugs, and the survey can be easily explained by the department wanting empirical evidence that Sprite swapping should indeed be the next thing they tackle, which seems sensible.
We've been working for quite some time under the assumption the sprite swapping won't be out for a while, so we've settled into a pipeline where we construct meshes large enough to accomodate a range of sprites and then use a custom shader that reverses a Sprite's rect-mapped UVs and applies the correct mapping for the new sprite in it's place. It works well, but it's not optimal (for workflow reasons, and it leads to some wasted space / overdraw). Thankfully we're still reasonably flexible, I just don't want to see what's looking to be a great toolset end up releasing with some fatal flaws purely due to working in silence, steadily heading in the wrong direction for too long
Let's change topic to another pretty important issue that needs attention: the .psb importer. Importer itself actually works pretty well, even though you end up with those heavy 100MB files in your project it doesn't really affect the build size that much (you gain like 600KB per .psb which is fine).
What truly turns me off from using the importer is its lack of Secondary Textures option in the Sprite Editor. Meaning you cannot easily add _NormalMap and _MaskTex channels to your character and you have to do it through materials - given that the .psb importer splits the character into multiple sprite renderers you need to create a lot of materials with their separate normal and mask textures (that's a looooot of overhead). Imagine your character is composed of 12 layers - that's 12 materials you need to create, each with their respective mask and normal map separately (so that's 36 files: 12 materials, 12 masks, 12 normal maps). If Secondary Textures was working you would only need to provide a single NormalMap and a Mask that covers the entire canvas and all of that would work on the basic Sprite-Lit-Default material (meaning you only need 2 files in addition to the .psb).
I feel that this forum is deserted from Unity... Maybe I should drop Unity's 2D animation. It goes very slowly. Does anyone have experience with Spine? Does it worth the trouble to learn it?
Spine is a great package, pretty artist friendly (it's UI is a little idiosyncratic and goes against many familiar design choices of popular tools like Photoshop), but when we used it I really hated its Unity integration. It was really messy when you get into anything beyond intermediate use. I'm pretty obsessive about custom tools and workflow, and I found it near impossible to work into custom editor stuff. But in terms of getting an animated character in, running around in Unity, it's good.
I prefer integrated Unity 2d animation but there is no word. Maybe some realistic roadmap, maybe faster access to testing features... I created a game with it with 2018 Unity and now I cant update to 2019 because of a bug I submitted. The bug was found but I have no word when it will be fixed. I cant just wait and do nothing until its fixed. I check this forum every day and every day I get disappointed.
Hi, I tried to work with it, but I don't have the nicely cut psd like the starting post shows.
I got separate pngs for each limb, how do I import the separate sprites into the skinning editor?
Also, whats your thoughts and experiences with Dragonbones? any problem using it in Unity?
The tools is better than I thought, and it's great that I could use the same draw call as my other stuff in the same atlas. And I see the use of ECS and Burst which is nice.
But what wasn't working as expected is the fact that it is not supported in 2019.1 : P
Maybe you could limit version support in the UPM setup?
The 2D Animation package (2.1.0-p2) and PSD Importer package (1.1.0-p1) do work with 2019.1 (at least on 2019.1.0f2), we're working with them on that version.
It works only outside play mode for me, when entered play mode the mesh do not move according to bone position at all (2019.1.9f1) I wonder if it is related to this :
That message from Rustum is very old. You should just need to make sure you have the latest packages. I’ve been working with these tools in 2019, including the latest release.
I have recorded a video of what I did. You see that in play mode it didn't move. Do I have to do something more than this? (2019.1.9f1, 2DA package 2.1.0 preview.7)
- That sprite is not a part of any SpriteAtlas, thought if it was the result would be the same
- I tried using reverting preview 2 like the previous reply said but same result.
- The screen flicker while previewing in Sprite Editor is not reproducible in 2019.2
edit: wait a minute, do I need PSD importer even if I don't need separated parts?
I wonder what irritates you about Spine? Because I don't find anything lacking so far. (I have been using it since long, I am the original KS campaign's backer as well back when it didn't have version tiers)
Surely I also can't know ETA but if there's one hint it's ECS dependency in the package. And that means this package can't be done sooner than ECS. And everything-DOTS is at 2022 on the roadmap they gave at GDC. So I think it's wise to think of that not as an upper bound, but a lower bound because things will get late/postponed..
Well, the only difference I can see in our workflows is that I’m using the psd importer, and I’m just dragging PSBs straight into the scene, with their spriteskin components already pre-made, rather than manually assigning them as you are.
So I posted this on a tutorial video but figured I should re-post it somewhere more official :
We are messing with the Unity 2D skeleton system wondering if we should switch over from Spine for our next game, after all a graph editor again would be amazing (that is my only gripe with Spine, but it's a hefty negative). Some things are amazing, this .psb import worried me but so far it's absolutely wonderful (minus if you scale or change the canvas size, then it completely shatters) but for the most part it works great, and I was able to add several items and it updated the sprite sheet seamlessly!
However, I am having several issues so far, but my biggest concerns are on the IK. I cannot get the IK feet to work correctly, the feet refuse to constrain rotation no matter what I do -- this makes the IK almost inept for legs. I have seen several examples of it working for others in videos, I try to imitate those tutorials but to no avail. I have noticed the IK tool I am using is slightly more updated than the videos I am watching, did something happen? Also, I seldom use IK on arms, but one reason I do use it (and will need it for the new project we are making) is for is when character is holding something 2 handed, like a shotgun. In those cases (on our previous projects) I would set arms to IK and put a controller on top of them which I would then use to drive them, that does NOT seem to work here, the IK arms went insane when I put a parent over them. Can you tell me if these are things I can get working and any tutorials that would better help me? I have gone through all the major videos I have seen from Unity, or should we avoid using Unity's 2D rig for now? I basically need to know if this thing is ready for a bigger project.
I've run into a weird animation glitch and would like to ask if anyone has seen this and knows where this might be coming from.
Sometimes, in a random frame, the animated character kind of explodes into pieces for a single frame and then turns back to normal. This happens from time to time, but not always at the same time of the animation. It's been observed by multiple team members in the editor, windows standalone and Nintendo Switch player.
My first guess would be that it has to do with bone weights, but I'm certain that it's nothing that is directly recorded as properties, instead the glitch happens randomly.
I would report a bug, but at this moment I cannot reproduce the issue other than a video and screenshots from a previous playthrough on device. If anyone has seen this, please let me know, maybe I can reproduce it more reliably and report it.
Is this tool dead? or are the tool developers on vacations? I see no updates or answers in this forum.
I’ve seen something like this happen in my project (editor only) after moving to 2019.1 from 2018.3, but it mysteriously stopped thereafter (we’re currently in 2019.10 with all packages in most recent version). Haven’t seen it in a few weeks.
Apologies for not being more active than we should for the past few weeks. We are working on getting the package working for the upcoming 19.3 beta release and we are almost there.
We are still working on the Sprite Swap feature. There is a very early version of it in 2.2.0-preview.1 but we quickly found out that the implementation wasn't ideal. That's why it was not mentioned so far. We have since did some rework and will be targeting a release soon. Stay tune and thanks you!
Yup! As Leo Mentioned:
1. On 19.2 latest 2D Animation Package, you should be able to try the very first draft of Sprite Swap.
But... do note that it is very early for that version.
We made a whole bunch of changes and are focused on delivering the 2nd draft with fixes, updates and documentation.
It will be incoming in 19.3 and 19.2 soon.
Do note on 19.2, if you get a Burst related error, try updating the Burst package to fix those errors.
Apologizes on any inconvenience.
Hi MikaMobile and Xarbrough,
We have seen this internally a couple of times and have been trying to make fixes to prevent this.
Do try to upgrade to use the latest versions if possible.
If possible, when you encounter this issue,
do file a bug report with a slice of the repro project through = Unity > Help > Report a Bug...
This helps us to debug and hopefully ship a fix faster.
I confirm that with Unity 2019.1.10 and 2d Animation 2.1.0 preview 7 my submitted bug was fixed!
Could you please tell if it is possible now, and if so, - how can you "update" the graphics already imported by the PSDImporter to its newer version?
Since I have never found any mention of how to do this often required process, I tried to simply change the PSB-file to a new version outside of Unity - in the Windows explorer...
But despite the fact that the Rig with the bones, the binding and the weights is preserved, the result was not successful...
In my opinion, the structure of the layers and their names have not changed in the imported file, the dimensions of the picture also did not change (I watched it),
but the PSD Importer, even in the form of an atlas shows a completely different picture.
And of course, on the scene, the fully working prefab of the character was completely broken
A similar substitution for the old PSB file did not help...
I understand that the method I used to update the graphics is slightly "hacker"
but how can I do it in a regular way?
P.S. Beware of Googletranslate...
Would you recommend adopting the current draft of the sprite swap workflow if it's going to have some fairly significant changes in its next release? I guess a secondary question to that is, if we adopt the workflow, can we expect work to carry over ok to the second draft once that version's out? I'd rather be using built-in workflows where possible, but if the workflow will be significantly changed in the second draft perhaps it'd be worth waiting for that?
Also just to clarify, is the second draft of sprite swapping targeted for 2019.3?
Hello - first time posting here. I have been using the new 2D toolkit for a few weeks now, and would like to share my feedback. Or rather I'd like to share some concerns I have, as it is otherwise pretty enjoyable to use aside from a few things.
My main concern is that I'm not sure just how manageable it is in its current state. For example, I created a character, and over the course of a few days I was adding animations as the need for them came up. Eventually, one animation had me realizing I needed to alter the source graphic slightly. The neck layer was a bit too long. So I go back into my graphic editor and fix it up....
When I re-imported the updated graphic, it caused the slicing layout to rearrange because one of the layers was now a different dimension. And when that happens, well, you may as well start over. Because it causes the skinning to lose much of its data. I'd have to do all the custom geometry vertex and weights again. In my case, I was working with a detailed sprite, so that's a rather large amount of work lost.
Has anyone here found a good workflow process for layering on clothes/equipment to their rig?
I was unclear on the ideal way to go about doing this... Now, if I just had all the clothes as part of the original .psb graphic, then it's no problem as I can rig it all together and just use c# to toggle visibility as needed. However, that is obviously not a very scalable idea. I would almost certainly want to add new equipment content as the game develops. By adding more equipment layers to the .psb, I would have the same problem mentioned earlier with the slicing being redone differently.
The only solution I found so far that works is to import the clothes as its own .psb, and copy-paste the bones from the character over to it. Then do all the weights and vertex work... then create matching IKs that are exactly the same.... then give it a copy of the animator... and have the code issue commands to all the matching animators. That way you essentially have the clothes layered over the character and following the exact same animation sequences. It works but it doesn't strike me as a particularly ideal solution. Feels clunky.
EDIT: Well, after reading tweedie's posts above, it seems like the problems I'm experiencing here aren't mine alone, lol.
It would be best to try the next release.
Do note that as a preview feature(Sprite Swap), we will still make changes as we collect feedback on workflows from users (Forums, Studios etc...)
Yes, the second draft will be on 2019.3.
Great, thanks for the prompt reply. No worries about it being Preview, just want to wait for the best moment to jump in. Cheers!
I have a very annoying bug that needs to be fixed. When I change the compression settings of the PSB and I save it I get this error:
"Identifier uniqueness violation: 'Name:Missing Prefab (Dummy), Type:Prefab'. Multiple Objects with the same name/type are generated by this Importer. There is no guarantee that subsequent imports of this asset will properly re-link to these targets.
And then my prefab in the scene lose the connection and become dummies. then I have to work the prfab in the scene from the beginning. This is a lot of work!
I have been struggling to update from 2018 to 2019 when I lose all my PSB prefabs and I have to do them from the start. This is very frustrating. Same thing happens when I delete the Library folder.
Hi. We have animated models in bundles, but we don't use your classes in our code. After building il2cpp on Android in the game I get a warning "The referenced script (UnityEngine.Experimental.U2D.Animation.SpriteSkinEntity) on this Behaviour is missing!"
I think this is a problem with the "Managed Stripping Level". It removes your code from build because there is no reference to it in our code.
Is there a solution?
We will also try to back port the work flow for 19.2 as well.
Tried to use this with 2019.1.10f and 2.1.0 preview 7, entities preview 33, but when entering play mode I always get the error:
"ArgumentException: type UnityEngine.Experimental.U2D.Animation.SpriteComponent is a ISharedComponentData and has managed references, you must implement IEquatable<T>"
I thought maybe it's fixed in a newer version, so in order to use 3.0.2 I got unity 2019.3a8, but I get the same error as here:
Which says it's fixed in 3.0.2 when it's still giving errors for me. I looked at the changelog for 3.0.2 which says "marked to support 2019.3a10 onwards", so maybe it's fixed in 2019.3a10? But 2019.3a8 is the latest public so it seems this is a dead end for now too.
What am I missing?
EDIT: I can confirm this happens with entities preview 32 and 33. This is unfortunate since preview 33 is required to use the physics package.
So basically 2.1.0 is too old to use, and 3.0.2 is too new to use.
EDIT #2: Current workaround was to just implement IEquatable in SpriteComponent. I thought it'd be more difficult to modify a package but seems all you have to do is copy the package from the PackageCache to the Packages folder.
What happened to the interface of the sprite editor in the alpha version Unity2019.3.0a7
And it would be possible to work, if the tab on which shows the sprites did not disappear - as I tried, I could not see it...
The panel shows only the hierarchy of bones.
Sorry if this is already fixed in a8 - I could not start the 8th alpha due to a known bug for Win7...
Is it possible to set rotation constraints?
This is due to Unity reskinning. We have a fix and you should have the fix with the next Unity 19.3 release
According to the IssuеТracker log, - in 2019.3.0a11, also the bug with a crash when started under Win7 should be fixed.
It looks like I will have a celebration ...
I decided to try 2019.2 today. Of course, it breaks my project that's running fine in 2019.2.12, something I have come to expect from Unity. I'm running into this issue, which makes my scripts unable to compile: https://issuetracker.unity3d.com/is...rsion-of-burst-that-yields-compilation-errors
According to this, it's fixed in version 3 of the package. Will this fix ever be present in a version of the package for 2019.2.x, or should I just not upgrade until 2019.3 lands in the fall? Would going to the 2019.3 alpha at this point be the best move? I've been trying to keep this project current to take advantage of the latest and (hopefully) most stable versions of these 2D tools since I plan to use them in production as soon as they exit preview.
Unity 2019.2 -released! Great!
New amazing movie with a demonstration of the capabilities of the new Unity... -Cool!
So where is all this beauty now?
I feel ya buddy. Its an up hill battle for sure. But Unity are doing some amazing things, its just that it has teething issues like any new features.
I have just updated my project to 2019.2 and updated all out dated packaged. But im having issues with entities package by the looks. Clicking on the error highlights gameObjects with 2D animation components on them so I thought this thread would be the right place.
Console shows following error:
which will point to gameObject with following components on it
The characters no longer animation too. The bones are moving but it seems as though the sprites have detached and lost their pointers or something.
Hoping there is some kind of quick fix or something
Have downloaded the alpha (2019.3.0a10) the errors are gone. But the animations are still broken. It just looks like the link between bone->sprite is broken though, the animation file is still moving the bones, but the sprites don't follow so hopefully I can just hook them back up.
I did the same, and had the same issue of bones no longer actually working on instances of the objects. Reimporting the sprite would fix this, temporarily, until the scene was reloaded. When selecting one of the bones in the scene, the inspector would show a warning at the bottom of the sprite skin component: "Sprite has no Bind Poses." I've submitted a bug for this.
The work around for this issue is by manually upgrading to Burst 1.1.1.
In the upcoming update, we are going to remove the dependencies on these packages because it is very volatile at the moment.
If this doesn't work, do let us know.
I noticed you are using Entities 0.1.0. This is the reason why it is breaking for you because for the Animation package, we are only supporting up to 0.0.12-preview.31. Try reverting back to the original Entities version required by Animation and it should work.
There is a bug in AssetDatabase V2 that causes Sprites not to have bindpose data stored correctly. You can change this from Edit -> Project Settings -> Editor and look for AssetPipeline. Change Mode to Version 1
The AssetDatabase team are looking into this issue.
Tried changing this, and now all of my sprites have lost their geometry. If I try to reimport them, the console is spammed with messages like this:
Failed setting triangles. Some indices are referencing out of bounds vertices. IndexCount: 93, VertexCount: 0
Guess I'll stay in 2019.1 for a while.
Thanks for your replies. All up and running now
Nice! So anyone familiar with Spine have tried the latest version and could compare some pros and cons, now that Unity’s 2D animation finally seems to support sprite swapping?
I really love spine, and it would be interesting if someone made a way to convert/import a spine Json file into Unitys own system to compare, since we already have a bit setup there.
Are there any performance gains with Unity’s animation compared to using Spine which seem to be performant?