It seems like it’s standard practice to move the pelvis up/down for foot IK but then I feel like it can break various things.
The pelvis moving up/down is kindof a visual thing but the character’s actual capsule doesn’t move so the capsule is no longer a true representation of where the character is or how they collide.
There’s also the eyes on the character. GetActorEyesViewpoint may not necessarily be accurate anymore if the character’s pelvis moves up/down, bringing the head with it.
It can also break hitboxes in shooters where the character may be forced to move up/down due to some cosmetic effects but their true positions of body parts may be somewhere else. Maybe one client sees a character’s head at one height, but another sees it at another height, and the server thinks it’s somewhere else entirely, and you get these desyncs. It could be a discrepancy just due to how the lower half of the body is currently rotated for a character from a client’s point of view. (I always thought this is why CS:GO chose to not have foot IK)
It also makes it harder to do a first person shooter with full body awareness. You don’t necessarily want your eyes moving up/down constantly as you turn and your character turns and decides to reposition their feet in a way that moves the pelvis up/down. In first person you may want to disable the pelvis moving up/down and then your legs start to hover.
Aim offsets may no longer be accurate since a character aiming a gun may have their aim offset based on Control Rotation as they aim at a target. But then their pelvis moved down and now you have to adjust aim in the anim blueprint or something rather than going off of the Control Rotation. It may not be too noticeable if the target is farther away but up close, you’d see a character aiming their gun lower than what they’re actually aiming at because the entire pelvis moved down. You could potentially adjust this by tracking what a character is aiming at, and if it’s a player, get the location their crosshair is aiming at.
I’m just wondering how people reconcile all these flaws/issues that happen from moving the pelvis up/down due to foot IK.
You listed a lot of different scenarios and features that maybe not all developers would like to integrate into their game.
All you described can be achieved using existing nodes in Unreal and all the setup for the character is pretty much done for you, so if you want to integrate everything you listed, the best way would be to start integrating one by one and simply check if some of the features are going against each other or break one of the behaviour you already have, and if you’re not able to find a good solution to fix the issue, you’re going to choose which one to keep.
Again, is all there and there are tons of tutorials regarding first person shooters in Unreal, so I’m pretty sure that you’ll find a solution for everything you look for, otherwise you have to code it yourself.
My question is more on the lines of what to do rather than how to do it in Unreal. I can always figure this out and already have some very complex anim blueprints and control rigs in my game.
Like for example Garbaj often has videos explaining how games actually handle complicated things in shooters at a high level.
A lot of tutorials in Unreal explain how to do foot IK but they don’t explain what to do about the flaws in simply moving the pelvis up/down. Once you actually try to make a game, how do you work around the issues I described above. Like what do games usually do in these situations. I’d even be happy with a simple answer like, actually games ignore these issues and all work fine.
I’ve been experimenting with games like Crysis and Battlefield studying how the animations actually work to see what they do, but it’d be nice if there was some article or Garbaj video explaining what games do in these situations.
After that I’d integrate all these ideas into my game with the best architecture that fits my solution.
That’s what Technical Animators are for, to solve technical issues or integrate complex mechanics, making them work together, eventually finding a trade off between performances, features and bugs
The reason why you won’t find a lot of specific technical solutions is because most of the time that is done internally within the studio and is not shared, also because every game has its own mechanics, features and animations, so even though the mechanics of a FPS may look similar, the behind the scene is a different story.
The GDC talks are a good example of studios sharing their knowledge and problem solving, where they usually don’t show/share the code, but allows you to understand how the issues were solved.
Long story short, Tech Anim is a wild world and Technical Animators keep their knowledge as if its their precious ring
Yeah, I’m essentially the TD figuring all this out for my game. I’ve figured out many things but am having headaches thinking about this now. I was kindof hoping to get people’s opinions or answers to what people do in this situation with the pelvis moving up and down since I can’t think of a good thing for my game.
Garbaj videos are nice and aren’t even about Unreal Engine, but Godot and making games in general.
I’ve decided that for my game that I’ve been working on for quite a while, maybe it’s not a good idea to have a completely unified first person and third person animation system.
It’s almost like the CAP theorem with databases.
With a game you can’t make the perfect system that works in both third person and first person without sacrificing something. I don’t know what the exact pillars are for character animations but it’s starting to feel something like this.
Feels good to play: Responds to controls well, mouse motion feels really snappy, doesn’t wobble your camera too much. Bullets come from your eyes not the gun. What you see in first person and third person don’t match at all.
Realistic: Camera placed exactly where your character is animated, bullets come out exactly from the gun. Things are out of the player’s control so it’s frustrating and unresponsive and clunky.
Amount of Work: Trying to use only one set of animations or code for the character in both first person and third person. Trying to make those animations work in both cases. Figuring out complex blending systems and space switching and IK instead of making animations the way you would for a gun where you only see your arms and not your whole body. On the other hand, you use one set of animations instead of trying to make 2 sets.
You have to kindof choose a middle ground among these 3 things and there are probably other things.
