They all have same functionality in the end. But if you ask me your video doesnt look very bad. Slowmo behaves sometimes very awkwardly. The node is changing the Root orientation and since the speed is not changing i would expect some foot sliding. That slowmotion probably makes it look like 3 times worse than it is actually. A Lerp with an Alpha somewhere between 0.04 and 0.05 should be good. I assume Strider has a regular Lerp Alpha for Smoothing, which is between 0 and 1.
slomo should be Perfect if you want Perfect animations. Not āacceptable at speedā.
you may not notice the glitch. Someone on 25fps will.
You actually want to compute the orientation warp angle for each cardinal direction every frame, then use a blend node to blend between the directions. That will ensure smooth orientation warping. Itās how I do it in my system now.
In some cases slowmo doesnt reflect how it is actually. With lower time dillation, sometimes character is not behaving how it would behave with the input. It exaggarates some movements. That is what i meant. So, in my experience it is not always same playing in normal speed, recording a video and playing the video in slower speed when compared to lower time dillation with input in ue4.
Sure, not the same. but start off with Slomo and make sure it looks Ok, no sudden jumps that get exacerbated or similar.
Once thatās done you can record a video in real time, and slow itās playback down to detect any issue.
Also, with the new animation tools that I have yet to figure out how to use, you should be able to record a session and play it back Over and Over with/without slomo.
Having the ability to replicate the same āerrrorā over and over is great, especially for those situation where you arenāt sure what has caused it input wise.
My goal is to make the animation look good even in slowmo. MostHost LA made a good point about people who have low fps. Low fps will display all the faults in animations, if not done correctly.
Thanks for the input. I have looked over how Epic did it, and they do the same, from what my ignorant eyes I can tell. I have actually already implemented this scheme (I think, at least), but perhaps Iām doing something incorrectly.
(I also think Iām hijacking this thread, so feel free to instruct me to make a new thread at any time.)
Since you have mentioned it, i have tried to implement a solution. In real life, when you change direction, you get slower. So, getting the inputAxis change rate (difference between previous and this frame), and lowering the Max Walking Speed due to the change rate, combined with a Speed Warping node, gives what you want. No foot sliding when changing direction. I am going to publish a whole project with Blueprints set up in my plugin pages with a Dropbox Link when i am done with my whole system. So, you can also see how i have implemented it.
Edit: Here is what i mean: Direction Rotation Change Speed Decrease - YouTube
That sounds like a great idea! Itās better than any idea I currently have, at least. Iām sure there are other approaches, but the one mentioned sounds promising.
So, just a heads up to everyone. Do what i mentioned, but instead of changing Max Walk Speed directly get the ration of new max speed to base speed and multiply it with both axis inputs. It will behave exactly same but this is natural for multiplayer and will work regardless of the lag. Setting max walk speed not a good way for multiplayer.
Iām trying to calculate the stop distance in Blueprint. The physics calculations should be straightforward, but I donāt quite understand what the Ground Friction and Braking Friction Factor are in the Character Movement Component. In physics speak, I need the normal force, coefficient of friction, initial speed, etc. Iāve never tried to do these simple calculations in BP, so I have a few questions I would appreciate help on:
1.) Where exactly do the Ground Friction and Braking Friction Factor fit into a physics calculation?
2.) Is there a character mass somewhere in BP?
Or perhaps Iām approaching the calculation in completely the wrong wayā¦
Donāt try to use actual physics, Itās much simpler than that. All you have to do is simulate the CalcVelocity function ahead of time in your own function so you can predict stop location. Also I tried to do this initially in BP but I couldnāt get it to work correctly doing a loop, so I had to implement it c++.
How about answering the valid questions instead of telling him that physic calcs are BS - which is just plain nonsense?
- they come into play when a phys volume or phys mat alters the way friction works.
basically the reason this is often implemented in c++ is that BP has (or at least had) no easy access to retrieve the current values. However the variable is avaliable in c++, so you can use it to make your code work on anything.
Ground friction is how slippery a surface is - applied during movement.
Breaking friction is how quickly a character stops when no input is applied. So youād remove it to have an Ice slide effect.
- yes, its usually the total sum of the PHAT bodies. They provide the total mass in KG but you would have to parse through them to tally up, and hope that whoever set it up actually set decent weights.
Normally you do this once on BeginPlay or Construction event. Depending. The phat may not be loaded during bp construction but it usually is on begin play.
Since you only tally once there is virtually no overhead even on a phat with 1000 bodies (which should also be impossible anyway).
you should be able to get and query each body in a for each loop even in BP, but youāll likely have to hunt the correct pathway and cast to the phat assetā¦
The movement component should have its Own value - which is merely likely to be set correctlyā¦
@postman09: When you say simulate the CalcVelocity function ahead of time, I assume you just mean I should use the initial velocity to calculate the distance traveled after the input is removed. That makes sense, but Iām unsure how to implement that in UE4 (mostly due to the ambiguity with Braking Friction, Ground Friction, etc.) If this was unambiguous and in Matlab, I could do it no problem. All my physics research makes use of Matlab, so UE4 (and especially c++) is a bit foreign, but BP has become more familiar(comfortable) to(for) me.
[USER=ā3140864ā]MostHost LA[/USER]: Thanks for your detailed reply. I have a few more clarifying questions:
1.) When you say āBP hasā¦no easy access to retrieve the current values,ā are you referring to the physics information, or something else?
2.) If Braking Friction is āhow quickly a character stops when no input is applied,ā should I therefore take it to be an acceleration value that has already assumed a normal force (and therefore friction)? Iām trained in physics, so Iām just trying to figure out how to arrange the stuff in UE4 to make sense in my head.
3.) In your opinion, would it be worthwhile to pursue a physics route for character animation distance matching calculations, or should I do something else? (If I understood what āsomething else,ā Iād be more specific.
-
particularly to the current ground friction and breaking that gets updated by the current material you are on. This could have changed since I last looked at it though.
-
yes, friction. But remember its only applied when no player input is being applied.
-
a decent physics implementation mimics what the engine actually does, giving you the most accurate possible results.
once you have the result the hard part is making/authoring the animations that fit, to make them fit, with the proper curve values and all needed parts.
just because you know the capsule will stop moving in X, it doesnāt mean your animations will look rightā¦ and thats really 90% of the battle hereā¦
PS:
I suppose the superior solution is to modify the character movement to output the values you need in BP nodes.
Since it is responsible for running most calcs anyway, it would make more sense to tap on to the very limited things avaliable within it.
That does require c++ but i think youād have an easier time converting math equations into c++ then you would with BPā¦ have a brief look at it, see if it makes sense to you or notā¦
All the information about friction can be found in the character movement component header file. Quick TLDR:
if buseseperatebrakefriction is checked, it will use the brake friction value, otherwise it will use ground friction (the cmc variable). theres a multipler as well in the cmc but its usually set to 1
If friction is >1 then it becomes velocity dependant, so you need to simulate calc velocity multiple times over some time, and break when the simulated veloicty is zero. This is especially important when trying to predict pivots.
The CMC is not a physics simulation so it shouldnt be treated as such. Trying to predict using the kenimatic equations only works for the case where friction is 1.
Speed = Speed - (Speed Ć (Braking Ground Friction Ć Friction Factor) + Braking Deceleration Walking) Ć DeltaTime gets you the Speed for the current frame. So, each frame you get slower and slower. Braking Deceleration Walking is constant, other two valuesā results change every frame since Speed is changing. That is the tricky part, you have to either do a loop or calculate it with a finite geometric series to get a single formula. You do the calculation one time after acceleration is 0 and get the distance to the stop position. CalcVelocity is in C++ and it does exactly this speed calculation for the frame.
Thanks again, [USER=ā3140864ā]MostHost LA[/USER], for your detailed response. Modifying the Character Movement Component scares me a bit, but Iāll save a backup and take a look. I downloaded VS2019 today. And regarding the animations looking right, I have no doubts thatāll be challenging. Before getting into game dev in January, I never realized how difficult it is to make characters look like they can move naturally. Iāve basically spent months trying to get a character to walk.
Thanks for the TLDR, @postman09. I wouldnāt have originally considered much of what you mentioned, so I appreciate the detail. Admittedly, Iām still grappling with organizing the terminology in my mind, but Iāll get it down soon.
[USER=ā3666339ā]Berkay Tuna[/USER], a geometric series, huh? I wouldnāt have thought of that. Since Iām still trying to wrap my mind around the game logic, I donāt see exactly where the geometric series would be needed, but Iām glad you brought up the idea, since now Iāll have it in my mind. Iām still considering purchasing your Distance Matching plugin, by the way. But now Iām more interested in seeing how the code is is written, that way I can learn. I tried creating a anim node in the past, and that three-week process ended with an enormous build-up of frustration on my end and without much to show for my efforts (other than a decent understanding of how to navigate Visual Studio as well as the knowledge the editor and runtime modules are needed.)
Here is video I made a while ago to show the progress for my plugin update: https://youtu.be/se5ewJsLzhQ
There are a few hitches, and I have refined it since then. Hardest thing by far was getting the pivots and multiple pivots correctly blended. Next hardest thing was getting the angled starts and stops looking decent, since you need to alpha blend between two animations, for example forward and strafe right.
I used the simulate calc velocity with a loop method.
@postman09 Oh! Youāre Patrick. I was commenting on your video yesterday. Your progress from six weeks back looks good, even for not being complete. I notice a bit of foot sliding at the start and stop. Iām currently having the same issue with start transitions. (I havenāt developed my own usable solution for stop transitions yet.). Iām certainly curious to see the current state of things on your end, but I bet youāre striving to get things perfect before the āreveal.ā
EDIT: Here is my newb attempt at predicting stop location. Obviously, the stop animations arenāt working properly.
Yup thatās me lol.
There is a slight amount of foot sliding in mine I canāt get rid of using the prediction, even though its near perfect. There are a lot of things going on like turning animation warping off near the end, blends, accuracy of the curve that effect it. Itās way worse for faster animations so in mine its a bit noticeable if you look at the videoās since Aurora has a fast base move speed. Iām going to try and implement IK foot locking like Longmire did and add it to my IK solution. With that hopefully perfection can be reached.
Your foot slide issues are either arising from your stop anim not completely transitioning to idle within the stop anim, or you are blending into idle too soon. Might be able to solve it with IK foot locking. But like I said above I havenāt tried myself yet.
Also are you using kubolds pack? It kinda looks like it from the video.