What would be the easiest way to have a bit of code trigger when a specific animation reaches a specific frame during playback? A basic example - playing a foostep sound effect when a character’s walk cycle reaches frame 15. The only solution that comes to mind would be to constantly check if animation[“walk”].time = 15, but I assume that during normal playback, the precise frame number may get skipped in all likelihood… or maybe not? I’m not home to test it myself :-\
There may be a better way to do this with animation related functions but building on your
if animation[“walk”].time = 15
base and assuming steps come one 15 and 35 out 0f 40 frames
in your setup function
stepped1 = false;
stepped2 = false;
if animation["walk"].time >= 15 and !stepped1 {
stepped1 = true;
stepped2 = false;
playstep();
}
if animation["walk"].time >= 40 and !stepped2 {
stepped2 = true;
stepped1 = false;
playstep();
}
(above is untest psuedo JS) as long as you don’t skip 20 frames (time between steps) you’ll be OK. even if you do skip 20 you’ll resync on next loop.
Yeah, this type of solution had occurred to me, and while its not ideal, it may be the only way. I kinda wish I didn’t have to resort to using variables to make sure the event only happens once when its appropriate frame # occurs. Embedding information into an animation track is really what I wish we had. It would be nice to be able to flag a function to trigger based on animation playback, and have Unity deal with keeping track of that event happening once and not repeating it forever.
Hmm… had a solution for something like this earlier… now, where is that?
Forum search for “animation trigger” and here it is:
http://forum.unity3d.com/viewtopic.php?t=5290
Hmm, so was playing animations that need to trigger things on a fixed frame rate and putting your triggers in fixedUpdate the solution you went for?
I’m wondering what David meant when he said that playing back many or all of your animations at a fixed frame rate would be ‘expensive’. What kind of expensive? CPU? memory? I guess I don’t understand why it would be harder to calculate than normal, or what kind of performance impact it might incur. Let’s say I have 20 simple characters on screen, each with a very small bone count (15-20), 1-2 influences per vertex and less than 1000 triangles per character, all of them playing at a fixed framerate. Would Unity explode?
Triggering code via animation is something I can see being extremely useful, not just for sound, but also particles, melee hit detection… it could also be extremely handy for minimizing bandwidth consumption on a network game. By linking things that might otherwise have to be RPC’s to frames of animation that are being state-synchronized anyway, you could save a lot of trouble… unless of course frames get dropped when state synchronizing them I haven’t touched the network functions of 2.0 yet.
It wasn’t even for anything I was working on, I just did as help to someone else. For something like the sound of footsteps, I wouldn’t use fixed update. It just isn’t necessary.
For more mission critical stuff, you’d just have to try it. The difference is that everything involved in animation would be happening many times per frame of visuals. Just multiply the complexity of what you are doing per frame by how many times your fixedUpdate goes per frame (I think it’s adjustable, too.)
Anyway, if you go for it, let me know how it turns out.
That script should work for most situations.