foriero

Hello Nate,

Would it be possible to carry on the "designed" track int information with an animation?

Why? We face that reconstruct animations flow in "Unity" with what animator intended on tracks is a bit cumbersome and lengthy process.

It would help a lot if an animator can specify on which track that animation should be played on and then runtime(s) take it automatically. All what is needed is one int carried on with an animation. If -1 then it means Unity developer is responsible for setting track animations. If 0> then we take it automatically and play it in "Unity" ( runtimes ) with that number.

The reason is that developers do not know how animators designed the whole animation structure and right now we have to put some kind of information about on which track that animation should be played in the animation name. It is really hard to work with.

The whole thing would be much easier if an animator can specify for each animation on which track it should be played or leave it -1.

Does it make sense?
Founder & CEO Foriero s.r.o.
https://studio.foriero.com
Avatar de Usuario
foriero
  • Mensajes: 352

Nate

It does makes sense for your use case. There are many ways you can use the runtimes though, so I don't think it makes sense to provide a field that is only useful for one particular use case. It may be a better solution to have something generic that could be used for your or other use cases, eg:
Name/value annotations · #25 · EsotericSoftware/spine-editor
I know you know the issue and it's been quite some time and we haven't been able to get to that issue, sorry. :wounded:
Avatar de Usuario
Nate

Nate
  • Mensajes: 10063

foriero

I don't think it is just a single usecase. If I'm a developer who does not know the animator or simple we are not able to talk it takes me hours to put together the whole character in unity. And in many cases I simply have to wait for the animator to explain me the tracking intention. BUT if an animation has additional int for a track number and in runtime i choose automatic then that way animators could prepare the whole character or object without the need to explain developers how to track it in runtime. This information about on which track that animation was intended to be played is simply essential for developers.
Founder & CEO Foriero s.r.o.
https://studio.foriero.com
Avatar de Usuario
foriero
  • Mensajes: 352

Nate

It will always be necessary for devs to work animators to integrate the skeletons into the app. Ideally you've designed how the animations will be applied and layered with tracks even before the animator has created the animations.

What I mean be your specific use case is that when to play animations, which animations to play, what track they are played on, etc are all application specific information. I'm all for providing ways to make that easier, but we should not assume that the skeletons/animations/skins/etc are going to be used in a particular way. This keeps the system/workflow/APIs/etc flexible and reduces confusion.

It can be awkward to provide special cases for a common way of doing things, as those have to be ignored when doing it other ways. One example is the "animation name" in spine-unity. It's fine if you just want to set an animation name and forget it, but it doesn't combine with code that is setting the animations in other ways.
Avatar de Usuario
Nate

Nate
  • Mensajes: 10063

foriero

I still don't see why you see it as a single, special, and narrow use-case. Please give me specific cases where you would not use the suggested "automatic" version. In all our skeletons we create we simply need this for developers. First for fast prototyping and second for more complex characters and objects where to reconstruct track layering is simply inhuman. As I said you will have options to choose None, Automatic, or specific track in Runtimes. If an animator does not specify the track number ( -1 ) then default is None and nothing will break for the current projects. If he specifies it then default is Automatic unless the developer specifies other track. In that case we won't limit anybody. The opposite is the case. We will enhance the whole "Animation Tracks" experience for all. People who need to use the track numbers in runtimes in a specific way still will be able to do so.

---

It would be super nice to have it like this. Also on the runtime side there will be just a little work. In general just make the track number as an optional param with default -1. And inside the function just find out if that animation pair [name, track] has track set or not.
skeletonAnimation.state.SetAnimation(name, ..., track = -1){
var designedTrack = state.GetTrack(name);
var t = 0;
if(track == -1 && designedTrack >=0) t = designedTrack;
else if(track >= 0) t = track;
// use that track //
}
track_number.png
No tienes los permisos requeridos para ver los archivos adjuntos a este mensaje.
Founder & CEO Foriero s.r.o.
https://studio.foriero.com
Avatar de Usuario
foriero
  • Mensajes: 352

Nate

First, consider AnimationState is not a requirement. We have a timeline API that can be used without AnimationState. AnimationState is already doing a lot to help make playing animations easy.

Typically, when using AnimationState, animations fall into two categories: track 0, where they set the main pose for the skeleton, or track 1+, where they are applied on top of lower tracks. Currently you can use tracks however you like, there are no conventions. Track 1+ animations may be applied on the first highest track that isn't already playing an animation, or you may want them on a specific track. An animation may be played on multiple higher tracks, it is not associated with a single track number, except for in your particular use case. There are other use cases, such as allowing a track 0 animation to play while you play an animation on a higher track which sets the whole pose, similar to a track 0 animation. That way when the higher track is done, the lower track is still playing and has progressed the whole time.

If we could encode how animations will be played back so that in most of the cases you don't need to manage yourself it at runtime, then we'd likely do that. It's a fine road to walk because it can convolute applying animations manually, so "most" needs to be quite high and there still needs to be a nice way to do it manually.

If you don't like hardcoding how animations are played in your application, I would suggest making it data driven. Don't get hung up on it having to happen inside Spine. You could have a spreadsheet or other tools that are used to describe how animations are played in your particular application. Even if Spine had the features you request, in all but the simplest applications you will likely have the need for other data driven behavior, such as attack damage, world properties, etc. Don't tell me you want all that in Spine too! ;)
Avatar de Usuario
Nate

Nate
  • Mensajes: 10063

foriero

No. :-) I just want automatic tracking :-) which covers 90% use cases. :-)

---

Please try to give it a second thought. As a developer you want to just play the animations. You don't care much about how designers and animators set it up.

---

It is simply a double work for the whole team. Animators are setting and animating it in the context of tracks so they know the track layering and we simply LOOSE the information on the way and developers have to REINVENT it once again. That costs me MONEY. :-)

---

I'm not saying that AnimationState is the solution. I'm brainstorming so that you see in your mind the RIGHT solution for this.

---

After we have this then the next step is to include MIX. That is another information that we LOOSE on the way and have to REINVENT it once again in RUNTIME.
Founder & CEO Foriero s.r.o.
https://studio.foriero.com
Avatar de Usuario
foriero
  • Mensajes: 352

Nick

I like the idea. It is more error proof if an animation already know which track it should be using. Less things to maintain and less worry.

However, it is a good to have but not as important as other wish list items like Selection Group, folder for DrawOrder, etc. Those affect the efficiency and mood when doing spine works. To be fair, the time I spend on maintaining my "animation name - track number" mapping file is nothing compared to time lost by not yet having those mentioned features implemented in Spine.
Nick
  • Mensajes: 159


Volver a Editor