• Editor
  • Blog: 3.5.00-beta released

  • Editado
Related Discussions
...

"Changing the FPS affects the speed of the animations at runtime and the setting is for the entire project. Changing the FPS does not change the frames for existing keys, so your animations will run slower or faster. This means you should set the FPS before you start animating."

You added something dangerous XD
I was wondering: let's say I have 30 fps, does this mean that at render time if a computer is able to render at 60 fps it won't? or is it something just to make animators more comfortable?
Maybe it's a stupid question but since I'm not using beta version at the moment I don't really know how it works yet (:

The FPS only controls the playback speed, Spine still does interpolation between frames. The frame numbers really only exist to make animating easier, by having keys snap to whole number frames by default. I'm sure you already know, holding shift allows you to place the timeline position between whole number keys, so you can set a key anywhere. When you are animating something very fast, you may need keys more often than the default 30 FPS, so a higher FPS would let you still use snapping instead of setting keys between whole number frames. A reason to use a lower FPS is if you have learned how fast X frames of movement is at a particular FPS.

If you change the FPS, fixing up your animations isn't hard, just a bit tedious. Eg, if you changed from 30 to 60 FPS, you'd go to each animation, select all the keys, then drag the edge of the selection so the animation is twice as long


a one second animation that used to end on frame 30 would end on frame 60. Changing the FPS isn't likely to be very common though.

There's a bug in the blog. The previous post's TS examples are now 404

I've created a ticket here to request the runtime update as our own modifications need to go in, are you planning on including some of those custom things from that "did you customize your runtime" thread?

Can't wait to mess with the constraints order! I remember just plain parenting things when the current ordering bit me in creating this rig (though I'll probably just use it on my next rig).

The scale and reflection inheritance thing is JUST in time, as I just did all my animations facing right, but his body needs to stay unflipped (It contains a word that kids need to read) 🙂 !

edit
I just upgraded my editor:
Why are Rotation- and Reflection- inheritance linked?
I'm trying to fix the legs on my walking pickle, I had a working setup a-la stretchyman (and those lips I made) - but I'll dig in my bones scaling inheritance some further and report back.

So far: I hope I can fix it in setup pose!
:sweat:

This is what I get, I've sent you the spine file in case that's an interesting thing. If not, please ignore the email.
Setup in 3.4:

Setup in 3.5:

UPDATED
FIXED

Yes, I had to transform constraint the foot bone to the shin bone 😃
-just key in the length of the bone as the offset, DONE 🙂 All animations work again. PHEW
:love: :heart: :love:

Erikari escribió

"Changing the FPS affects the speed of the animations at runtime and the setting is for the entire project. Changing the FPS does not change the frames for existing keys, so your animations will run slower or faster. This means you should set the FPS before you start animating."

You added something dangerous XD
I was wondering: let's say I have 30 fps, does this mean that at render time if a computer is able to render at 60 fps it won't? or is it something just to make animators more comfortable?
Maybe it's a stupid question but since I'm not using beta version at the moment I don't really know how it works yet (:

I think this point of confusion is good to elaborate on.
Maybe it should be named "Dopesheet Framerate"

A custom value here doesn't make animations at runtime "framerate dependent" (ie, movements won't speed up or slow down depending on how fast your machine is. They'll just be smoother or choppier).
Once you export, all times are converted to seconds using the fps factor. 30fps was implied before Spine 3.5. Meaning 30 frames turns into 1 second.
Animations are interpolated in the editor and by the runtimes so animations can play at 120 fps if your hardware could handle it.

So at 30 fps (default):
Any key you place at frame 30 will be converted to a "1.0". Meaning 1 second. (frame 30/30fps = 1 second)
At runtime, it will use the exported time in seconds and can play as smoothly as the hardware and engine allows.

If you change it to 24 fps.
Any key you place at frame 30 will be converted to "1.25". Meaning 1.25 seconds. (frame 30/24fps = 1.25 seconds)
At runtime, it will use the exported time in seconds and can play as smoothly as the hardware and engine allows.

When you drag around in the dopesheet, the dopesheet cursor snaps at whole "frames" by default.
So the practical reasons for the custom dopesheet framerate are:

  1. Traditionally-trained animators can animate with timings they are familiar with. (8fps, 12fps, 24fps)
  2. Some image sequences/frame-by-frame animations can be keyed at the intended framerate. They could be pre-renderered effects exported from another program, or hand-animated frame-by-frame.
  3. Very fast movements can be tuned precisely (at 60 or 120fps). The intention may be to give it extra polish, fix visible glitching because keys spaced 1/30 of a second is too far apart for the given movement, or just to better-support games that involve periods of slowmo. This could always be done before, but custom dopesheet framerate means keys can now snap to whole frame numbers, making editing super easy.

Typically, you would only set the framerate when you start the project. (say, 24, or 30)
An animator should know what framerate they are comfortable or intend to use and set it at value.

Every now and then, you may realize you need to tune movements to be faster, so you may need to double your framerate. That would be easy to fix in that case. You just need to scale the animation keys out to double using box selection scaling.

Image removed due to the lack of support for HTTPS. | Show Anyway


After that, you would keep the framerate at the new rate.

To get the 3.5 compatible runtime for Unity, do I need to download it from:

http://esotericsoftware.com/spine-unity-download/

https://github.com/EsotericSoftware/spine-runtimes/tree/spine-csharp-3_5

or
https://github.com/EsotericSoftware/spine-runtimes/tree/master
?

I'm sure I'm missing something, but would it be practical to list the version of the package at the top of the readme?

:whew:

No, we haven't started porting Spine 3.5 compatibility yet.
That branch is where the porting will be done for csharp.

Check the spine-unity download page for the beta when it's available. Once there's a working beta, it will be in unitypackage form too.

Thank you for your patience 🙂

Could you hint at when said port might be done?

The readme found here https://github.com/EsotericSoftware/spine-runtimes/tree/master/spine-unity does not list the version it is compatible with.

I realise it is clearly listed here: http://esotericsoftware.com/spine-unity-download/ - but I was secretly hoping the github version was ahead of that.

I fully realise I should have been more careful (Though I think I can fix the mess I'm in) :sweat:

22 días más tarde

Just out of curiosity, is there any ETA on 3.5 release? At least if it's a matter of days, weeks, or months. 🙂 Thanks!

Xelnath escribió

There's a bug in the blog. The previous post's TS examples are now 404

Fixed a few links, though not sure what 404 links you found.

nimbling escribió

Why are Rotation- and Reflection- inheritance linked?

Rotation inheritance can't be disabled and still allow reflection, else when reflected and the parent bone is rotated, the child will appear to rotate. It seems you also ran into the slightly different disable scale inheritance: scale now affects rotation even when inherit scale is disabled, to avoid a similar problem.

Sorry these two things are different from the old behavior and gave you trouble, but we had to make these changes to make the features stable. We should never have behavior that becomes unexpectedly weird in certain situations, which is what the old implementations did. We try very hard not to make changes that require projects to be fixed up, but sometimes it's unavoidable.

As you found, a transform constraint may be what you want, though it has different behavior depending on how it is configured. Unfortunately there is no one solution that covers all use cases.

Pharan escribió

Maybe it should be named "Dopesheet Framerate"

I agree, that is a great name, but it's so loooong. How about:

Image removed due to the lack of support for HTTPS. | Show Anyway

As for when the runtimes will be updated to 3.5, we have just finished updating ALL the official runtimes to 3.4.02. This was quite the effort, as a number of runtimes needed to be rewritten or otherwise improved to bring them up to the desired level of quality. Next begins the update to 3.5 which thankfully is incremental and will come quickly. You can subscribe to the 3.5 update issue to keep an eye on when the runtime you are using is updated to 3.5, otherwise when you see a 3.5 non-beta release you will know ALL official runtimes have been updated to work with 3.5.

un mes más tarde

I tried the new beta version[3.5.12-beta]
but I can't export project.
I also tried the official project.

I downgrade to lower version [3.5.04-beta/3.4.02],the export function works fine.Any idea about that?
3.5.12 is a great version,I think I like it, added so many new function,amazing!Thank you!

Please post your spine.log file.
Windows: <user home folder>\Spine\spine.log
Mac: <user home folder>/Library/Application Support/Spine/spine.log
Linux: <user home folder>/.spine/spine.log

Nate escribió

Please post your spine.log file.
Windows: <user home folder>\Spine\spine.log
Mac: <user home folder>/Library/Application Support/Spine/spine.log
Linux: <user home folder>/.spine/spine.log

I updated to the newest beta version[3.5.14-beta]
It works fine now!
Thanks Nate!

7 días más tarde

Is there any chance to open new version of the file in the older version ?
Cant open 3.5v animation in the 3.4v spine. I have to make whole animation from the beggining ? -_-''