• Editor

  • Blog: Spine 3.0.00 released

    英语
Related Discussions
...
Nate ：

1) Polygon packing would be great, but it's quite complex. Even rectangular bin packing is NP hard.

N is not that big in our cases. Unity and TexturePacker already have it, but I dont know which algorithm they are using. Did you at least investigate it?

Nate ：

2) What benefits are there to putting Spine on Steam? What Spriter does is not interesting for us.

I thought you'll be able to sell stuff in regions, but I dont know if its possible to sell periods and not whole app.

Nate ：

3) I understand the difference in economies between the US and eastern Europe (I live in Croatia). However, it's difficult to make discounts fair, especially for a lifetime license. Unfortunately we haven't been able to come up with a reasonable solution.

Make it yearly, like texturePacker. Even JetBrains doesnt sell life-time licenses anymore.

I admit I haven't investigated polygon packing yet. Of course it's possible and I would definitely like to have it.

I can't seem to easily find what cut Steam takes for non-game apps, but I expect it could be up to 30%. This makes sense for games but probably not so much for Spine. I don't know how their region sales stuff works, but that is a good point. I've seen games for 9 euros, then I switch to a proxy in the states and it's 9 dollars (yeah this is backwards example, sorry :p).

We have talked a lot about offering updates for a year initially and then a small fee for another year of updates. Ultimately we agreed it is probably a better idea than the current licensing, but making that change is a lot of work and we have so many more pressing things we would rather see get done at this time.

I agree. Yearly License would work for us as well. I mean, I would love to support you guys and keep Spine evolving and I would like to see more features. I would even agree to pay for 3.0 Upgrade. Chaos Group doing the same. for example Vray Version 2.0 was 1000$ and all the next version before 3.0 are free.

In addition, what would be cool, if you could have some kind AKA kick starter for Features. So let's say 50 users want to have some feature, those users can donate I don't know whatever 50 EU for example and then you add this feature, even thaw for the rest it will be kind free.

Just some crazy idea.

Just FYI, whatever other company or group is doing historically hasn't been a strong argument for Nate. :p
Any facts and info are helpful though.
And it's cool when we hear about sensible demand and not arbitrary should-be-this-and-that. So thanks for sharing!

For now, there's work to do! Lots of new features for Spine this year! (I hope I don't jinx it!)

Hi guys,
I have just updated to Spine 3.0.02 and think there are new bugs introduced.

  1. Rotation angle edit box changes its value on focus change if negative scale is set.
    Here is the first video describing this bug as usual 🙂

  2. Key frame navigation became broken.
    If I drag timeline cursor the key frames are playing normally, but if I just click at specified key frame nothing changes.
    And the second video is also here.

Thanks kxs. #1 your video was helpful and we are working on a fix. #2 is fixed in 3.0.04, available now.

Awesome! The new scaling is great! Eagerly awaiting the Unity runtime 😃

Damn, so I've basically just made my work file useless as i've saved it in v3, but v3 exports don't work with Unity at the moment? Did I miss some warning with the update on the program that let me know that my files were going to be held hostage until the runtime is updated?

When is this likely to be fixed? Is there anything that can be done to work around backwards compatibility? I've got older versions of the file if that helps?

Also, another discovery while I'm here! When exporting, in V.3, spine/texture packer isn't exporting all the assets used in the animations. It's just flat out ignoring about 1/3 of them. I've restarted and downgraded (due to the whole not working thing of V.3) and they export perfectly in any version earlier than v.3.
In my case, I have about 11 skins, each with a flailing arm animation which consists of about 20 pngs per character (a png sequence rendered from AfterEffects). When exported, V.3 Spine/TP only exports one skins set of arms, and ignores the other 11 skins worth. Yet it exports all 11 skin's other assets (heads, bodies, legs) just fine. Any Ideas?

I'm on Mac btw.

Any suggestions for either of these issues would be much appreciated. Cheers.

I ran into the same thing. Luckily I had a copy of the file backed on online.

@Iluks if you saved your project with an older version there should be a backed up version in the backup folder. If you go to "Settings" you can open your backup folder from there and check.

Would it be possible for you to share your project that is causing exports to fail? If so please send it to contact@esotericsoftware.com and include a link to this thread so we know where it's coming from. 🙂

Sorry for the problems. 3.0 is a very large upgrade but we'll have the bugs ironed out soon. We are working crazy hours to fix things.

What about Unreal 4 runtime?

The UE runtime got pushed by v3 taking unexpectedly long. 🙁 v3 needed to happen first since it affects so much how the runtimes work. UE is still very important for us. Once we are freed up from v3 issues and updating runtimes we will get the basics working in UE (rendering animated skeletons), then add more features over time (interaction with the scene graph, similar to spine-unity). Sorry for the delay!

Oops, sorry I somehow didn't see your post at first, lluks. The state of the runtimes will often fall slightly behind the editor as new features are added. We do this so we can get editor features to users ASAP, as not everyone needs to use the runtimes or they want to use the new editor features and are fine with waiting for the runtimes. As with updating any project dependency, a myriad of things can go wrong and this can be disruptive to a project. I'm sorry it wasn't clear that v3 is a large update and that the runtimes are slightly behind. You can freeze your Spine version to control when it updates, and you are of course in control of when you pull in the latest runtimes code. In case you need to go back to an older version of your project, when you save a copy of your project file is created in your Spine backup folder which is accessible through a button in the Settings dialog.

Your export problem is very strange. Maybe you could email the project file and images so we can reproduce the problem? contact@esotericsoftware.com Please include a link to this post so we have context.

lluks, is it possible that all the attachments that are not being packed have a path set? That seems to be the bug, will be fixed in 3.0.05.

Nate, any changes for my "loading bug"?

Don't know if it had been posted yet, but there's still a bug that forces me to close spine and reopen it in order to load a skeleton exported via photoshop script. (all the pieces end up in the same place instead of having their correct disposition). Also at some point if I'm moving the bones or the origin some points of a mesh stay in the same place deforming everything instead of moving with the root.
Both problems vanish after restarting but they're happening quite often and it's getting a little bit annoying.
Btw new scale system is definitely better! I can't wait for the new stuff to be implemented (: excited

EDIT:
Here I recorded a video of the root bug:

Finally !! I am able to make this. 😃
Thanks spine 3.0!!! :beer:

Very cool Hwadock! 🙂

I know the question "how did you do it?" will be asked.
So here is a Spine project you guys can take a look at to see how to do it.

Hello. One important question. If i used v.2.1.27 before. Can i switch to 3.0.05 within a one project? Does Unity SDK supports older versions?
For example my game already contain few characters made in 2.1.27. If i update to 3.0.05 and make few character animation in new version. Will i have problem with the old animation in my game with new SDK?
I hope i clearly described. Thanks in advance.

Shiu ：

Very cool Hwadock! 🙂

I know the question "how did you do it?" will be asked.
So here is a Spine project you guys can take a look at to see how to do it.

how could you not do that in <3?

artist confirmed it was magic

this 3.0 stuff confuses me :x :x

@effectic:
v3.0 runtimes will ignore flipX and flipY and won't be backwards compatible with inherited local-axis scaling.
If you used non-uniform scale before, you may need to adjust your animations. But it's also possible that they look just fine. (I used to use non-uniform scale at really tiny amounts just to warp sprites a little.)
If you used bone flipX and flipY, you DEFINITELY need to switch your animations to using negative scale and re-export.

If you DIDN'T use non-uniform scaling on non-terminal bones, or flipX or flipY, everything should work normally.

@[已注销]
It was one of the first things I tested when I first got Spine.
You definitely couldn't do that before.

hwadock, that is mesmerizing!

puzzler, no not yet. Sorry, there are a lot of things going on and since your Spine is working, it's lower priority. I do realize it's annoying though and we'll get to it. 🙂

Erikari, wow that is a strange problem! Can you email a project that shows any of the problems you are experiencing? contact@esotericsoftware.com We need to be able to reproduce the problems so we can fix them, so anything you can do to help with that would be great.

BinaryCats, you could rotate bones before v3, but v3's nonuniform scale allows you to squish child bones along the parent bone axis. This means when the child bone it rotated, it's tip will trace an ellipse rather than a circle. When you attach images, they are squished in the same way. This enables things like hwadock's cool effect (the fireballs are moving in an elliptical path) or squishing a rotating image to give it perspective.