Hehehe it gets the mood right for some paragon animations 
No IK yet. hoping to use control rig to get IK and slope warping seems to be cheaper than regular IK too.
2 Likes
Just no.
Regular IK via leg IK has by default 6 solver iterations.
thereās nonway for control rig to improve on anything about it.
Any IK solver (Fabrik, CCKD etc, can also be adjusted to have less solving or more).
The whole point of IK is that you need to do the math - yourself - of where your foot needs to be. How far the pelvis has to shift, and in relation where the other foot needs to be. Localized to the vertical axis.
I doubt control rig would do that for you anyway - let alone correctly.
did you get the chance to open the Slope warping control rig that was showcased during that last lengthy stream about unreal? itās not perfect yet but it can improve for sure. the full body IK solver was doing most of the job with some constraints. the math there is certainly not all the math that you would do for the regular IK. the traces are even called inside of control rig. it has potential for all kinds of procedural animations for sure.
But not performance. You said it could be cheaper. It isnāt. And thereās probably no possible way it could be.
you are sure or theoretically speaking? . https://youtu.be/GTOs4XwzcME?t=3314 I know the numbers can be insignificant like that but in a MP situation with 10-20 players it can make some difference. maybe i got the wrong idea?
Probably. More operations cannot Possibly Ever result in less work.
Given how much control rig does (or can do, more appropriately) thereās just no way that it will end up costing less than using a single LegIK node.
Use a box trace in the size of the foot solved by the position(distance) from foot bone to the socket. This way, manually moving the socket generates a longer box that covers the foot and prevents toe clipping.
You can code IK to make the character fall if your leg variance (vertical distance between the 2 legs) is above a predetermined threshold (I use capsule half height or a variation of it, so that itās automatically present and adjusted when setting up the character).
Look, the video isnāt the best to begin with. Whatās concerning is the amount of overhead operations that are completely unneeded if you do the math right.
Granted, this private video is about something completely different. the IK here is done with just math, and 3 to 4 nodes.
It also propagates to walking states with the IK curves.
Where Control Rig shines, is to fix that absolute mess that you can see the pertuges do with clipping and unstable simulate physics.
it does make perfect sense that if you would use any full body solver it would cost more than a single IK node. but the hole idea is that because it use its own VM if you do something very advanced thatās when the performance difference shows when something with multiple virtual bones and many calculations and a full body IK node normally is done with control rig . either case something like in the video below might not seem like an overkill now ( I have always thought this is one of the coolest IK solution ever showcased and Iāll be giving it a shot after i am done with this.)
Good animations lead to that.
However a basic IK implementation does everything showed in the video without having to resort to control rig for it.
And, without having to check the next stop location response ahead of time.
in fact, if your character missteps you should probably have him stumble and recover. It gives the game a much nicef feel of realism; being almost completely random.
As a bonus, it can possibly cause the player to die because he was rushing, which is always a great addition to any game 
checking the step location ahead of time would allow you to take that higher step to go over it while reacting to something already underneath you ,wouldnāt give you the same effect. granted you can do something like this with normal IK implementation but wouldnāt the math for hip correction , āāballāā bone and toes rotation be lot?
stumbling and falling is just about the animations isnāt it or you want it procedural with a physics set up thatās be cool as hell. the prediction of the step is for a natural āāstep overāā which is exactly the opposite lol. still the use of control rig becomes attractive when you start thinking about other precaudal stuff. simulating a pivot for example can be done in control rig is an elegant way. how ALSv4 did it but in another level. adding a slight center of mass pull down a foot lock and a shift towards acceleration can certainly be done with regular IK but control rig can be easier to work with and can give great results. i just think if you are a familiar with procedural stuff which you clearly are control rig has potential to allow you to make even cooler stuff.
As a bonus , imagine playing a survival game and you trip and fall on a rock and you break a leg hahahah
I wanted to ask about the one thing i had an issue with when it comes to distance matching and you seem to have it covered. Offsetting the root bone for the turn in place and spin transition is perfectly fine in single player but is extremely jittery in multiplayer . i narrowed it down to the fact that the clientās actor rotation value is not perfectly in sync with the server. since i am also manually replicating the control rotation to use it being unreliable can results in some desyncing from time to time specially in high ping. is there something i can do about that without touching the character class itself?
The issue with turn in place synching in networked games, which i assume affect every locomotion strategy, is the network interpolation part.
You have to hook into the proxy network interpolation update and adjust your turn in place system accordingly.(SmoothClientPosition_UpdateVisuals())
Thank you so much for the insight.
2 Likes
Hey guys! Itās been awhile since my last post, but Iām getting back into distance matching. I wanted to ask you guys how did you apply foot ik to rotate the feet and did this solve the leg crossing problem? Iām using sync markers and the kubold animation pack.
Also, Iām currently using the following formula in the screenshot to calculate my distance. How are you guys applying the friction and what friction variable do you use for your starts? And is brakingfriction the correct one to use for stopping?
I know 2 approaches. First, like in paragon - switching between direction instead of blending (see Paragon locomotion system - YouTube and bringing-a-hero-from-paragon-to-life-with-ue4.pdf ā ŠÆŠ½Š“ŠµŠŗŃ.ŠŠøŃŠŗ), second, like in this blog post Realtime Animation Tips & Tricks ā Strafing Locomotion
P.S.: Look at this too, may be it be useful for you Animation System Prototype: Distance Matching on Vimeo
Look at source code of UCharacterMovementComponent::CalcVelocity
Yes. I used what itās there with Iterations to figure out the stop location
I saw your most recent video you were using Kubold animations but you didnāt use the strafing animations. Did you just orient the forward animation loop 90 degrees?
Iāve been looking at it, trying to understand it. Is there a particular section that I should focus on or do you guys just copy the entire function for your start and stops? Also, the distance to the stop/start is calculated once, right? Then you would use CalcVelocity to update the current distance every frame in order to get the time for the animation, right?
I used strafing animation in this video Paragon locomotion system with Kubold anims - YouTube
Itās the same approach which Epic used in Paragon. Just switching between direction and using root bone rotation + aim offset for turning character when itās moving diagonally.