This is a work in progress of a ragdoll using physics animation component, utilizes angle of hit to a sinusoidal distribution to determine strength of hit events, utilizes the experimental component for physics animations released in 4.13 to current, set up for realism and take downs when legs are interfered with, has two types of stand up animation (the animations will be changed probably for better ones currently using mixamo animations as placeholders) stand up front quick, stand up front dazed, stand up back quick, stand up back dazed.
**NOTE: This is a work in progress, and is gearing towards being a game template with user interface and accessories. Might be trying to release on the market later if it turns out well enough.
its really early and still pretty buggy but I enjoy feedback… and I am using this approach due to a suggestion by Xodroc on my free asset which is in a different post and utilizes the old ways of simulating physics.
Have a looksie at some of it happening, like the video if you like.
Comment anything you like.
Syk (Sykoo) is my partner on this and is helping me remedy some issues and is working on replacement animations to replace those mixamo place holders.
Cheers.
-MDO
Just want to comment (on my own post, which does seem strange to me but doing it anyway), replication with the physics animation component setup has proven extremely difficult, but is mostly done. And sorry to the feller that commented but I had to delete the thread to move it cause somehow I put it in the wrong place.
Man this is exactly what I have been looking for. Will pay for this no question, especially if MP supported. Please continue updating us on this project!
I actually haven’t gotten that far yet, having some issues with basic replication. Mostly because I am floating the capsule and using traces to keep it updating. Problem with this is that it seems that the sockets are still returning the wrong location or info in dedicated mode in the current version and the known fixes have been no avail mostly, this is making the way I am doing this more complex, works on listen server works in single player, on dedicated it falls apart. Though when I get this working or abandon that method and do something else I will have to figure out how to properly make the reactions of the hits the same on all clients, I know this can be accomplished a few ways I was thinking using the client side to send to the server for rep. However, I have seen time and time again that these hits and ragdolls always seem to differ. I am not sure exactly what you mean by sending info on each body. If you think it will help the progress please elaborate? any advice is always appreciated.
The physics bodies the skeletal mesh uses when simulating physics.
Skeletal mesh components do not automatically handle replication of that information.
You can just cycle through all the physics bodies and send their information each tick, but this leads to quite a bit of jarring on the client each time it receives an update.
If a skeleton has a lot of bodies, it also ends up being quite a lot of information to send.
You can solve the jarring by using prediction.
Instead of forcibly updating the client bodies to match the server info, you predict their movement based on the last update from the server and nudge each body in the right direct as needed. @TheJamsh has provided some great info on this, but I can’t seem to find his post on the subject
Wow this is exactly what I am looking for, the exact issue I am having…
Unfortunately, I can’t seem to find any posts or info on either method, updating the info from each body on the tick (how would you go about that?) and/or predicting body movement based on previous and giving a nudge (what does that even look like, how would one do that?) If you can give me any more info, I’d be much obliged… I will keep looking in the mean time.
I am currently stress testing it in one of our game projects with a limb sever system. And basic replication is done yes, but it won’t be done until i get perfect ragdoll replication down. Hopefully, I can figure out this physics bodies rep thing, so each part of the mesh replicates across multiplayer properly. But until the rep is completely ironed out I cannot call this done. Hopefully it wont be too much longer.
I was reading that the reason people just try to match the server and client side environments enough to get similar results on the ragdoll, but not exact was because passing the information from all the bones on each event is a lot of info to send and causes lag, stutter and on network lag severe results. On mine it would be even worse because I am not activating Physics Animation Component on event, then it would of been just like my old asset. I am actually constantly running simulation and have the physics animation component active. Like a marionette thats tighter when not getting hit. So it would be constantly sending that information. But I imagine thats why you said use prediction on some of the in between stuff and send info on I guess what, main bones and thats where I was unclear, I wasn’t sure if you meant just setting the world location and/or rotation on the tick. I will definitely give this a shot, but I fear that it might become too dependent on good pings. Or another concern I have is that I never get the right socket info on clients, its always slightly off and that causes big trouble, and on dedicated server the info is even further off, sometimes shooting off on alternate ticks to some unknown location. So, if this is dependent on getting socket info I fear that its going to be too much.
Some people have said that refreshing the bone on each tick had resolved their issues, and for sure that and a reliable tick replication on my capsule float segment minimized the damage from getting off info from sockets, but it definitely did not fix it. I wonder if there is something else going on. At this point I am not sure if perfect ragdoll replication is going to be a goal anymore, or if just getting the replication close enough. Though the thought bothers me. I was playing GTA online side-by-side with my fiance on two ps4’s/tvs and we noticed that the ragdolls were separate… It really kind of shattered the illusion of one world and became noticeably a client/server parallel universe.
I can achieve that method of bone update in bp I am sure. But I wonder how one specifies which mesh server or client side it reads the bone info from. Setting it is obvious, but when we just pull the world socket info running straight out of the bp without rep (because its not actually connected in the flow) does it fire just on server, or both client and server? Which info is it sending? I think I will have to mess around with this and see if its a fit for this.
Thanks for your input! I am not sure if the method will work out for this, but I certainly hope so.
Hey there! Glad to see you’re still working on this! Just read the above and yeah, “perfect” replication for ragdoll/physics is likely not going to be viable for a typical server solution. Cloud computed physics, where each client contributes might be a possibility; which is how Crackdown 3 has replicated dynamic building destruction… Not easy to implement I’m sure.
I was asking about this same issue back in 2014. The idea I had was that only important bones should be replicated, and let the client handle the rest. The torso for example is pretty vital, maybe the head and the hands. Ideally if a character gets hit by a force and goes flying and smacks into a wall, I would think the torso is most important because it’s a large central mass. Perhaps it would be as simple as having the capsule match the orientation of the torso(I know some prefer to use the hip) in that event. In 2014 the answer I got was that it couldn’t be done in blueprint.
I noticed in 4.15 they have a new feature called Pose Snapshotting, which would allow you to capture a ragdoll pose and use it for animation blending. I was wondering if perhaps it would be possible to replicate a snapshot of the server’s ragdoll on major collision events, and then let the client’s ragdoll take over from that pose. The client will still be running it’s own physical animation most of the time, only getting updates on “important bones” and snapshots of major hits.
Hey Xodroc! wondered when you would pop up, haha thanks for confirming what I already thought. Yeah I think thats what Kris was suggesting too, just 4 or 5 main bones. Everything I’ve seen is people handling it client side as well, which poses no security risk though it was counter-intuitive to me at first, but I am still relatively new to this stuff. I was going that route until I saw how involved, then I switched to trying to handle it all on the server and have the mesh replicating while always simulating and managed to get rid of the stutter from that alone. But it translates zero of hits on the bodies [other than environmental, because its more macro (size wise not coding) and more likely to be the same], so I guess trying it with main bodies sending info from the client side is the only way. Its really a shame that replication of a mesh doesn’t do squat, aside from making the bodies line up a little closer in orientation (not translational movement or world space).
So that’s the next goal to try, but first I have to finish my chore list on this game project working titled “Another Day” started by Syko my partner in MUG. Where I’ve been working on the asset merged into this limb sever system and trying to iron out the kinks in the replication at the same time, in retrospect it made it harder to isolate issues but killing three birds with one stone made it worth it. Now I have most the kinks worked out I will finish my chore list on that game, then copy the asset code back out to the original asset project and I will try to tackle the issue of updating the key bones. Then I guess try to find the socket info on the bones in between and give them a force or impulse in the right direction maybe. But, if it turns out to be too much for resources I will abandon this method and go with the “good enough” having similar enough environments on client and server where you hope the same things happen close enough. I’ve gotten this Another Day project to the point where they are landing in the right places, oriented right 98 percent of the time and are always losing the same limbs and having the same hit events. So thats good at least.
haha, the detailed progress report was probably unnecessary but I know there are a couple people who have reached out to me about this and I just wanted them to know that I am not neglecting it, but realized that this was more of an undertaking than originally thought. At least to do it well.
I’ll check out snapshotting. I wish I would of just taken your suggestion when I was working on the old ragdoll asset using the legacy kind of way of doing things. I would of been done with this a long time ago. So, I will give that pose snapshotting a gander.
So James Golding is giving a speech at GDC on Animation + Physics, upcoming features that will probably make me facepalm at every method I used before. Interested in seeing the project you’re working on.
I will take a look. I just recently started watching ue4 sponsored streams.
For sure, give us a couple weeks to straighten out the collision on these limbs flying everywhere (they are useable as weapons, so I have to have the collision on spawn) and tweak some stuff and I will link. Its pretty neat though, the limb sever and the PAC ragdoll together. I just finished a quantum exam so I should have a couple weeks unimpeded to work on things.
