My goal is to use Epic’s strategy for start transitions. I have the high-level logic outlined, as shown in the below picture. (There’s more, of course, but the rest is irrelevant to my question.) My question is: **if I’m blending two animations via a Blend node, is there a way to access curves corresponding to each individual animation? **The Explicit Time variables for each animation correspond to a curve specific to each animation, but I’m unsure how to make the GetCurveValue() function get, for example, the curve from StartAnimFirstStepA and then also, separately and simultaneously, get the curve from StartAnimFirstStepB.
If you are writing your own get curve, almost no idea.
if you are just using the engine’s version,
it works on whatever is playing for actual curves.
Like IK and what not. The blend node takes care of merging the values based on the blend node. And potentially you could drive a blend crazy by feeding a curve value that contradicts itself, so careful what you do.
If what you are doing is working start/end transitions based on curve value, you probably do need your own custom get for the relevant animation. You have time via that explicit, you just need the value based on that and the animation.
unlike what the engine does, this should just be read in from the asset itself. You can find some code and tips in the thread down below titled distance marching giving it a shot.
If all you need is to sync footsteps the epic endorsed way to do it is by using sync groups. Works entierly different but it does work If you spend time to sync animations.
[USER=“3140864”]MostHost LA[/USER]: Thanks for the response. I was hoping to use the default GetCurveValue() function found within the engine, but I realize that function takes curves from animations currently being played and then does some sort of averaging/blending. But, from what I can tell from Paragon presentations, Epic has a separate Explicit Time variable being fed into the two animations that are to be blended, which indicates to me two distinct curves (for time) are being referenced at the same moment and are not being blended together.
Maybe I’m misunderstanding the logic Epic used to create their Explicit Time variables though. Right now, I have a C++ function that maps the character speed to animation time by referencing a Speed curve within my individual animations. Perhaps my approach is not the best, but I’m unsure how to create a good GetTimeValue() function. (I’m aware of the “Distance Matching - Giving It a Shot” thread, but the supplied code for getting time is…not ideal, though I appreciate the generosity of the person who created and shared his work.") Basically, and in a roundabout way, I’m flipping the axes of the Speed curve.
I’m not sure if my explanation makes sense.
Not too much in terms of what the end goal here is.
A start animation plays fully all the time unless control is let go / some event triggered.
The next animation will be a speed warped run blend space (or walk).
It seems to me like you are just attempting to sync steps given the snapshot you shared. Which is probably what has me confused about this.
- why/what does your start moving animation have to do with step management?
From idle to starting you should always have complete control of what stepping is happening since there’s really only 1 animation in play.
- this isn’t true for stopping, but sync groups takes care of skipping a step in the animation if setup properly, so from run to stop when left leg is front, the next stop animation knows.
To make this animation you just include a full walk cycle so the engine can either keep or dump the first step. The rest of the animation can thereafter play fully.
- remember that if a curve doesn’t exist in the next animation, the system will not blend it.
not sure if that means the value is set to 0 or preserved as the other non blend calls for. But it doesn’t matter does it?
You can include the exact same curve in both animations with the same name. Then blending will always return the full curve value regardless.
at that point, even the default get curve value will return whatever your animation calls for ar runtime.
You can leverage that by fetching and feeding a different curve value to the nodes you need. You just need to make double sure that the curve value has the same values and either the same or a longer length as the initial / hiccups might not even matter really because of the blend.
If none of that helps, explain a bit more about what the end goal here is. Because you do have me confused too.
[USER=“3140864”]MostHost LA[/USER]: Thanks for trying to understand what I’m saying and trying to help me out. I’ll aim to address each question/comment in the order you presented them, and then I’ll add more thoughts after.
1.) In my current setup, each start animation belongs to the same Sync Group as the rest of my on-the-ground animations. I have yet to add sync markers to my start animations, but I definitely plan to do so before testing, otherwise the designated Sync Group won’t matter. Now, regarding only one animation playing during a start transition, I don’t think that’s how Epic set things up. (I reference their setup because I’m trying to use their genius.) From what I understand, during the first step of the start transition, two animations are blended together. After the first step, the two-animation blend transitions into a single animation with orientation warping. (See the below picture of my setup, where I’ve stolen ideas from Epic as well as the ALSv4 setup. Also, see this video by Epic at 18:15: https://youtu.be/YlKA22Hzerk?t=1095.) But the two-animation blend is where my confusion resides. Each of the two animations is driven by a distinct float value corresponding to a time within that particular animation sequence. Each of the two animations could have a different total length, and could have different step times, so each one is driven separately. If sync markers adjust any out-of-sync issues, why did Epic use two distinct float values to drive their two animations? (I guess that’s my question.) And I believe each float value comes from some sort of GetCurveValue() function that pulls information from each individual animation, where both animations have curves of the same name (presumably). So two curves of the same name are pulled separately from two different animations and fed distinctly into the Explicit Time pin. (Perhaps, of course, I’m making assumptions of Epic’s strategy I’m unaware of.)
2.) Stop animations will be my next challenge… On one hand, I look forward to the challenge; on the other, not so much.
3.) Both animations have the same curve name, but I’m desiring to get the values (which will be different) from each curve distinctly rather than retrieving some blend of the two animations’ curves.
Maybe my approach is completely off, so let me explain my goal: (1) during the first step of the start transition, drive each individual start animation (N,E,S,W) with its own distinct “time” curve, and blend the two chosen animations; (2) have the animations synced (via their Sync Group); and (3) after the first step is taken, have the two-animation blend transition smoothly into a orientation-warped single animation.
Overall, I think the whole thing is an overcomplication driven by the fact they didn’t have proper animations in the beginning.
when you start moving in any of 8 directions because in a 3rd person usually you have 8, not 4 and you have a specific animation to fire for each direction, the foot thing is completely pointless.
The animation will fire off from start to finish, and it usually only lasts about 10 frames before the final speed is reached (for walking anyway).
the walking animation takes over at the point where the start moving ends, so if all your 8 directional animations start and end on the same foot as they should you’ll never have a foot swap happen.
When you don’t have good animations, and you start moving to the left ends on a left foot forward, while your walk cycle is not dedicated and starts on a right foot forward, that’s where you have issues.
My 2 cent on that is, don’t try to correct the issue programmatically. You can (obviously) but if you get better animations you’ll simply never have issues of any kind.
All that explained.
Your approach isn’t completely off. But if in (1) you end up using a manually blended value to transition then using the regular get curve should also work?
I’ll also have to re-watch the vid in its entierty, because there is a lot there that isn’t really needed - maybe “anymore” since it’s dated by now. Maybe just because I opt for better animations…
[USER=“3140864”]MostHost LA[/USER]: Unfortunately, I also don’t have proper animations. Not for strafing, at least. I’m using the Mobility Pro pack, so I only have start transitions for strafing in the N, E, S, W directions. The animations themselves seem pretty good, but I don’t have as many options as I’d like. That said, I think I can get things working if understand the logic properly. But only time will tell.
Also, the reason for using only a four-directional set of animations combined with Orientation Warping is to avoid the horrible leg cross-through when changing direction. For start transitions, the leg cross-through wouldn’t be an issue, since an eight-directional blend would only be used for the first step before transitioning into an orientation-warped four-directional blend.
I’m going to use the standard GetCurveValue() function for now. At the moment, I can’t think of another way to approach the situation. Well, actually, there is another thing I considered: a Blendspace Evaluator. I could (possibly) make a Blendspace with all the starting transitions, where the horizontal axis is the RotationRelativeToVelocity and the vertical axis is Speed. Perhaps I could drive that somehow. I just haven’t figured out how, especially since a Blendspace Evaluator takes in Normalized Time rather then a “standard” explicit time, due to the weighting and averaging that Blendspaces do.
You can normalize time with usual formula,
(var - min) / (max - min)
Afaik with proper animations in a blendspace you have no issue. Each walking animation in the set needs to start opposite to the previous so you don’t bunny hop at 50% blend.
with sync groups setup you can get away with murdering animations in a blendspace too XP
I’ll go and re-watch the vid today.
So far, what I just told you about the blend-space, they do via blend by bool because you can’t have a blendspace of blendspaces.
Since they have blendspaces for lean and incline, that makes sense.
Also, his explanation on how to avoid the bunnyhop is probably better than mine 
[USER=“3140864”]MostHost LA[/USER]: That’s right. I actually used that formula but forgot. Wow. Haha
Hmm. Maybe that’s true. I haven’t had good experience with avoiding the leg cross-through in Blendspaces though. I’ve avoided the bunny hop, but not the leg cross-through. I wish my (super) small team had an animator. Right now, we have to deal with the animations we have. Most of what we have is okay, but making small edits in Blender would be helpful. Unfortunately, my ignorance of Blender is deeper than the freakin’ ocean.
I’m thinking of use a Blendspace for the start transitions, but I’m going to try one more thing first: driving the single animations with distance from a Distance curve. I suppose I could do the same in a Blendspace too. I’m just going to keep testing until I get something useful. I hate freakin’ foot sliding. Haha
Thanks again for helping out. This animation implementation stuff is an absolute pain.