Esoteric Spine Mac Cracked Rar File
Harriet Wehrenberg
I finally got the chance to take a look at the 'issue' I had mentioned in my post a month ago. Turns out it seems to all boil down to one thing - not understanding how the "wind" and "gravity" values that are set/keyed in a Spine animation get translated to how they actually appear in Unity. Note: I did most of my testing with "wind" and not "gravity" so I'll just focus on "wind" since I think they operate in a similar fashion.
In my test project I set up a hanging banner (like a flag) that hangs straight downward. It's mesh is bound to a chain of bones. I created an animation that has a single key, which is the "Wind" being set to 30.
I noticed that if I cranked up the Wind to a ridiculous value, it did affect how it looked in Unity, but way less, as though it was scaled down a bunch. So I thought it might be something related to "unit values" (ie. Spine units versus Unity units, or something like that). I tried changing the "Scale" on the SkeletonData.asset from the default value of 0.01 to 1. This did indeed help (how it looked in Unity became closer to how it looks in Spine), but it still isn't correct. It was still off by a factor of 2, or something around that.
There is a typo in my post (supposed to say "...either the Spine Editor or the Unity Runtime") but I can't seem to edit the post? I don't remember where the Edit button is supposed to be, but I've been looking for 5 minutes and either it's not there or I'm going crazy, lol
Physics is affected by bone lengths. It sounds like there is a bug where data loading scale is not being applied in a way that results in the same physics behavior at different scales. We'll take a closer look at it and get back to you!
I updated with that version, and unfortunately it didn't fix the issue. I just emailed a zip of my Spine project to con...@esotericsoftware.com. In the project there are a couple different pieces, since I was testing things out. The issue happens with this bone, which is the only one that uses the physics constraint for "Translate X/Y". When I set that physics constraint for Translate X/Y back to 0, it fixes the issue.
The issue is that, in Unity, the bone goes way out to the side, something like 200x further than it should in the animation.
To repro:
1) Export/import the project into spine
2) Create new SkeletonAnimation by dragging the SkeletonData asset into the scene
3) Set the SkeletonAnimation to use the animation called "wind animated"
4) Run the scene and observe that the bone goes way further to the right than it does when you play the "wind animated" animation in Spine.
As mentioned above, changing the "scale" on the SkeletonData asset itself (the one that is by default 0.01) seemed to affect it, so I'm wondering if its some sort of conversion from Spine units to Unity units, or something like that ?
@Jamez0r We have just pushed a bugfix to the 4.2-beta repo, it turned out that load scale (import scale in Unity) was ignored, affecting wind and gravity. A new spine-unity 4.2-beta unitypackage is available for download:
-unity-download
Please let us know if this now fixes the issues on your end as well. Thanks again for reporting!
The problem is with an IK constraint for this Woodsman character's elbow. We've used rigs like this before, so we think its an issue specifically with 4.2. I just sent you a zip of the spine project (I replied to the email response you sent me earlier today). There is an animation called responses/technique/default/4.release. This animation has the character's claw-arm raise upward, and at a certain point when he is raising it up, an IK constraint on his arm is keyed to go from "Options: Positive: True" to "Options: Positive: False" (the checkbox).
Steps to repro: Export the project from Spine to Unity, create a new SkeletonAnimation with it, and set its default animation to the responses/technique/default/4.release (ARM ONLY - IK ISSUE) animation. Observe that the elbow goes wild during the animation.
Let me know if I can provide any more info, or if you want me to start a separate thread or submit an official bug report or anything. This is the only remaining issue we're having with 4.2, so we're pretty stoked!
Quick question just to point me in the right direction here - in regards to question #2 on my original post in this thread, is there a way to programmatically set the (global) wind/gravity values for a SkeletonAnimation? I might mess around with testing out that wind system I mentioned sometime soon ?
If you would rather use an animation, you'd have to create a new animation and timelines or dig through an existing animation's timelines to find the wind and gravity timelines, then you can change the keyed values, add/delete keys, etc on the wind and gravity timelines. Note that by default the animations are shared by all skeleton instances, so you'd need to duplicate the animation if you don't want your changes to affect other skeleton instances.
What I'm looking to try out is not having wind or gravity keyed in any animation on the character, but instead having my own weather system in Unity determine "how windy it should be" each frame at the location each spine-character is standing, and then apply that value to the SkeletonAnimation somehow. Imagine a grassy field with characters sprinkled around in it, and my weather system handles calculating the "wind value" for each character as gusts of wind blow across the field.
If I knew "at this moment in time, the wind value for this character at this location should be 2.5", how could I most easily apply that to the SkeletonAnimation for that character? You mentioned being able to set the wind/gravity values on the physics constraints directly, so would that be the best to do it? Meaning I need to aggregate a list of the physics constraints, and iterate through them applying the wind value (rather than doing it at some "global" level that automatically affects all of them)?
I think we've been experiencing something similar, we're using todays update which fixed some other issues we had but we're suffering a leaning issue that differs between Spine and Unity much like this
100 gravity on the right shoulder strap in Unity at the end of the Angry animation
100 gravity on the right shoulder strap in Spine editor at the end of the Angry animation
0 gravity in Spine Editor, the right shoulder strap veers further to the left much like in the Unity scene
I've sent the spine file and a blank unity project with just this scene and spine already configured to show the issue to con...@esotericsoftware.com, just hit play in the unity project and you'll see the difference.
@bantam Sorry to hear you've encountered problems, thanks for reporting! This sounds like the bug with wind and gravity which has been fixed just 4 days ago:
EsotericSoftware/spine-runtimes2446 (via this commit)
Could you please have a try whether the very latest spine-unity package resolves the issue on your end?
Thanks for responding, I may have I have missed a step to make it work, do we need to programmatically provide a gravity level in Unity somewhere? I didn't see a method for it through the SkeletonAnimation api.
Also tried it with another one of our spines that uses 100 gravity for hair with a test pose to make it more obvious, 2023 blank project with default unity settings with SkeletonAnimation pulled into an otherwise blank scene to make sure its not any of our current projects settings screwing things up.
I think spine is an attractive tool, I'm considering buying the Pro version. However the big deal breaker is the lack of a particle system, as of now Spine users have to animate each particle by hand instead of just adding an emitter that spawns them. I have read the forum and seen that Nate have said that there will be no particle system due to the maintenance debt that would come with it - namely supporting every different runtime that handles particles differently.
I can understand that, HOWEVER..... I think you can dodge that debt entirely by labeling the feature "Experimental", adding a warning dialogue box that explains that particles only work within Spine, and are not supported for export. This would not incur any runtime maintenance debt, and would be a huge timesaver for users who want to use particles in Spine.
In fact there are a few of us who want to use spine primarily as a stand alone tool, not for exporting to game engines. Many people out there are looking for easy and cheap ways of making animations for video, twitch, youtube, websites etc. And right now people like us are forced to hand-animate every single particle instead of just adding an emitter that farts out a bunch of particles in a specific direction with a specific transform and lifetime... It seems like you already have 90% of the features needed for a particle system, the last 10% would greatly help users, and also expand your user base beyond those who use spine as a gamedev tool.
A particle system is a lot of work, even if it can't be exported to runtimes it's complex and has a lot of controls. It'd be a significant drain on resources for something that can't be exported to runtimes, and that's not great. We do want to improve Spine for cartooning and other use where the final product is video export, so maybe it fits in then.
I totally understand, it's not optimal to put resources on things that are contained in the application, but on the other hand it might help expand the user base and take Spine from game engine-adjacent development tool to a more stand-alone application. I think Spine is can serve as an alternative to the more bloated and technical applications out there that people use to make animations for video.
I'm not trying to underestimate the work it takes to do a 2D particle system, it's indeed a sizable chunk, but to me it seems like you have already come a long way. With relative basic particle controls we would be able to achieve a lot paired with the tools that are already at our disposal. The physics update sounds interesting, but a particle system (even a basic one) would be pure gold. I will keep an eye out for the physics update though!
7fc3f7cf58