Bekko

hi, i mix between animations using track but i need to jump from frame 2 to frame 8 on both animations
my question is how do i jump to a specific frame in a track ?
track0 = skeletonAnimation.AnimationState.SetAnimation(0, "animation 1", true);
track0.Alpha = 1;
track1 = skeletonAnimation.AnimationState.SetAnimation(1, "animation 2", true);
track1.Alpha = 0;

//mix
track0.Alpha = 1;
track1.Alpha = 0;
best
Bekko
  • Posts: 32

Nate

You can use TrackEntry animationTime (also see the other methods available). At runtime seconds are used rather than frames. If your dopesheet is the default 30 frames per second, then use frame / 30 = seconds.
track0.AnimationTime = 8 / 30f;
User avatar
Nate

Nate
  • Posts: 12129

Bekko

thx @nate

i forgot to say that i'm using TrackEntry :
[Range (0, 1)]
private Spine.TrackEntry track0;
but i figure it out
track0.TrackTime = 8 / 30f;
Bekko
  • Posts: 32

Friebel

Nate wrote:You can use TrackEntry animationTime (also see the other methods available). ...
track0.AnimationTime = 8 / 30f;
At this moment I'm working my way through all timing getters and setters in the API reference of TrackEntry to get to know them / learn them all in detail, and so I found this thread.

In the example you set the animationTime to a value. But according to the API reference on the Spine website animationTime is readonly. Am I missing something? Or is this a typo in the API reference, has something perhaps changed or is there something different when used in Unity specific? (I don't use Unity btw, but am a little confused by this thread)

http://esotericsoftware.com/spine-api-reference#TrackEntry-animationTime

BTW I see that recognised API-text on this forum wrapped with ticks automatically ads links to the reference. That's cool! 8) I wonder how you set the link on your animationTime inline code to the reference though.
User avatar
Friebel
  • Posts: 48

Nate

Oops, you're right TrackEntry animationTime is indeed readonly because it's computed from other values. Likely the OP wanted to set TrackEntry trackTime.

FWIW, often it can help to look at the code, at least for the simpler parts of the Spine Runtimes, such as getters:
https://github.com/EsotericSoftware/spine-runtimes/blob/3.8/spine-libgdx/spine-libgdx/src/com/esotericsoftware/spine/AnimationState.java#L1013
There are some parts that are likely not worth trying to fully understand, like the monster that is AnimationState apply.

As you explore the AnimationState and other APIs it would be interesting to hear if you get stuck or otherwise where we might be able to improve the documentation to give you an easier time. As much as we try, we can only pretend to look at it with fresh eyes!

Lastly, for a new project you may want to target 4.0, as the Spine Runtimes will be ready and it will come out of beta in a reasonable amount of time. The new graph is a huge improvement and greatly increases animation quality. There are API docs for the v4-beta here:
API Reference (beta) - Spine Runtimes Guide
We just updated the beta docs, as we've added timelines for separate keying of X/Y and RGB/A.

The forum will make a link automatically if you use either of these in your post:
ClassName `methodOrFieldName`
`ClassName`
User avatar
Nate

Nate
  • Posts: 12129

Friebel

Nate wrote:As you explore the AnimationState and other APIs it would be interesting to hear if you get stuck or otherwise where we might be able to improve the documentation to give you an easier time. As much as we try, we can only pretend to look at it with fresh eyes!
So far nothing much, but I had/have some confusing about times though. I needed to tryout things in code to grasp the different timing values of TrackEntry though as the TrackEntry API-descriptions alone weren't enough for me to understand them. Mainly because it took me a minute to understand there are basically two time ranges: a 'local' one per animation, and a 'master' one per track.
To me it wasn't clear which method was using which range. It would be nice if that could be clearer or described in the guide.
(that said, I didn't read the full guide yet, so forgive me if you did if after TrackEntry in the guide)

At first the difference between 'local' animation times and 'global' track times wasn't clear to me just by reading the API. I'm working my way through the guide and jumped into the TrackEntry API as the guide skipped that (would be nice if there could be something about the important TrackEntry though?!). But so far didn't read anything about the difference between animation-related times and track-related times.
Would be an improvement I think if there could be something about that in the guide so at least we know there are two different time 'systems'. Also in relation to delays and timeScale, for one it has an effect on the time and for the other it hasn't. I only knew by trying it out myself and creating my own notes. But for others I'd think it's nice if that would be cleared up in the guide and the difference described better in the API doc.

Also I found the description in the API with animationLast confusing at first. Not only because it sounds like animationEnd, but mainly because as I believe the word 'apply' was used in the guide for animations to append them to the track. But in the description of animationLast 'apply' is related to the apply() method as I understand now.

The description now says:
The time in seconds this animation was last applied.
I think I would have better/earlier understand it and didn't have this confusion if the line was something like:
The time in seconds the apply() method of the animation was last called'.
I also don't get, still, why there is a different getter for getting the 'last applied' time in comparisson to the 'animationTime'. I understand now one is the current pointer in time (updated by update()) and the other one is the time when apply() is lastly called. But I don't really understand yet why we would like to know when the apply was last called. To me all these different kinds of times are both very handy and useful as well as confusing at first. Especially because of delay and timeScale affecting some and others not.

Than it's important to get a full grasp of how the system really works, so to me something like a graphic in the guide about this would have been helpful!

[edit] Another thing that keeps confusing me is when the API 'speaks' about 'removing animation from the timeline'. Like on the description of trackEnd inside TrackEntry, it says:
The track time in seconds when this animation will be removed form the track
But that keeps confusing to me. Eventhough I understand the animation gets removed from the track when done, I would
understand this better without confusing when the focus would be on the ending of the track, rather than the action that follows by that (removing the track), so would be something like
The track time in seconds when this animation is done and so will therefore be removed form the track
Not (yet) sure if this fits all situations though.

Hope this helps!
Nate wrote:Lastly, for a new project you may want to target 4.0, as the Spine Runtimes will be ready and it will come out of beta in a reasonable amount of time. The new graph is a huge improvement and greatly increases animation quality.
Yes, I would very much like to use everything v4 already. I run both v3 and v4-beta in parallel and try to use v4 in my notes. But for runtimes that's a little difficulat as I'm using pixi-spine and it isn't compatible with spine 4 yet. I put a request there though, so hopefully in a while it's available!
Nate wrote:There are API docs for the v4-beta here
Nate wrote:we've added timelines for separate keying of X/Y and RGB/A.
Cool!

And thanks for the info on the forum-links.
Testing:
TrackEntry animationTime 8)
User avatar
Friebel
  • Posts: 48


Return to Unity