Hi Marcus, having an issue with recording the simulation onto rig, that walk animation is not touching the ground after baking like the simulation does.
What could cause that?
Issue below
https://mega.nz/file/v4MxUIJJ#aZ_rt3ohU6FzC0VFINhaGOZVJwJyjQqwznwMEhTKO0c
Let me know, if you need the scene.
Heya @LL_LL, would it be possible to upload to the forums instead? You can drag’n’drop a video into the text field to upload it. It means it can be played back here directly without download or going off-site.
Tried that in the first place, reply function did not accept the video stating its too big, its 7mb size and a mp4 file.
Alright, made it little smaller in size and it let me upload it.
Thanks, I can see it now.
This would heavily depend on where things get recorded. For example, if your character has an elbow with locked Rotate X and Rotate Z, but your simulation was free to move in every axis, then the recording would be unable to reproduce the simulated result on the elbow.
This looks similar. Is it possible that the Marker have more freedom than the legs? It’s not clear from the video, but if the feet were driven by IK, then retargeting onto that IK control should keep it locked in place. If it’s all IK, then it would depend on how close the rotate pivots of your controls are to the Markers.
Yes i see what you mean, but im unable to find the culprit. The markers are all simulated even the root.
Regarding the legs and rest of the rig, there is no IK but parenting to an imported walk animation i did on 3ds max.
Tried couple of things, but it keeps getting worse. Having trouble with this physics rig for a long time, could not just restart after putting much work in it.
Can i upload the scene for you in private?
Following the conversation via PM, another thing you can try to debug is Ragdoll → Utilities → Extract Simulation. It will generate a new joint hierarchy containing your simulation that you can use to manually constrain your character to. There’s an option to automatically constrain your character in that menu item, from there I expect it will be come more clear why the character isn’t following the simulation. You can use Maya’s native Bake Simulation tools to transfer it to your character in a similar way to how Ragdoll does it from there.
Yes that tool is very nice. Will keep using it from now on. Thanks
Continuing from private message, on how to debug a scene.
In the above case, we’ve got many things happening at the same time, and the best place to start is to try and break a big problem into many small problems, starting with:
If we remove the recording, we can spot at least 1 issue. The arm is making a drastic move on the first few frames.
Drastic moves on the start frame is Ragdoll trying to correct for something. Typically, there are two causes.
In this case, I suspect limits. Although I cannot spot anything obviously wrong. Both the arm and clavicle appear to start inside of their limits.
A robust way to make sure is to temporarily disable all limits.
That appears to have solved it. But sometimes it can be difficult to see due to the character also falling under gravity, so let’s also temporarily disable gravity. We should expect no sudden moves when starting playback.
Bingo. Now let’s dive into the original limits and try to spot which one caused the issues.
That’s the one, but why?
Ok, we can see that the YZ axes lie outside of its limit, meaning Ragdoll will try and rotate the arm such that it is back within the limit. In this case, that’s nearly 180 degrees, which would explain the sudden pop at the start. Because these axes are also locked, rather than just limited, the motion is instantaneous as opposed to the soft cone that otherwise depend on Limit Stiffness and Damping.
This button is the equivalent of Ragdoll → Utilities → Reset Constraint Frames and restores the limit to what it had at the time of assigning the Markers in the first place and is a good place to return to when having these kind of issues.
Alternatively, you can try and asymmetrically edit the limit until the red axis line lies within the red limit cone.
To confirm all is well, playback the simulation once more.
Next let’s look into why, despite a successful simulation, this cannot currently be recorded.
Other than the result being completely bonkers, what specifically can we observe?
Let’s have a look at what our Retargeting UI has to say.
Great, we’ve got a plethora of warnings. Primarily green ones, which indicate that the channels Ragdoll would record onto are already driven by something, other than animation. In this case, there is a constraint.
Ragdoll is just an animator. And an animator and needs to do what animators do: set keyframes. It needs to set keyframes on the controls that move parts of your character. In this case, Ragdoll is attempting to set keyframes onto controls (joints, in this case) that cannot/should not be keyframed.
For example, when moving the root, it doesn’t actually move the character.
Let’s follow the connections into this node to try and find which one actually does translate the character.
Using the node editor, we land upon a separate hierarchy. It’s not clear to me why this hierarchy exists, but this is the one Ragdoll should record onto. In this case, it could have been assigned onto in the first place meaning it would follow the right thing, and record onto the right thing. It would have avoided the need to even look at the retargeting UI.
With this information, one thing needs to happen and a second thing is optional.
The ideal route would have been to assign to this separate hierarchy from the beginning, that would have automatically handled both following of the input animation and recording back onto it. But if you find yourself in a situation where you cannot turn back time, you can retarget.
Now that our Retargeting UI is warning-free, it’s safe to record. 
And there you have it! 
Despite simulating ok, and despite recording ok, there are still a few red flags in this setup that I’d like to touch on for future readers.
Consider what parts of your character you want to animate, and assign to only those. Sometimes, this can be just a tail. Sometimes, just the upper body. But most of the times, there will be joints and controls in your character that are superfluous in a simulation.
In this case, there are 5 Markers that serve no apparent purpose. On the head, there are two additional Markers called “neck2” and “neck3”. My guess is that these exist in the original motion capture or rig joint hierarchy, and serve a purpose there. But for this physical creature, they are attached as though they were cancers or additional limbs. And they would move as such.
Like any good doctor, removing these would have a net-positive impact on your simulation.
Generally, huge values - those beyond 10x of their default - is a symptom of a problem.
For example, some limits have a huge stiffness value.
This would suggest that the limits do not appear strong enough, and the intuitive solution would be to make them stronger. But why are they not strong enough? How is it that the default assets do not need such values, and still appear to respect their limits?
Let it remind of you this scene from Futurama.
Similar situation, clear intuition. But instead of turning up the heat he should have lowered the cold, and the same often times apply to Ragdoll - and in fact any kind of simulation in any other software, both real world or digital.
In this case, I expect the reason Stiffness needs to be this high is related to the next red flag.
Now this is one that should never need to be anything other than Earth gravity, unless you want your character to appear as though they are on a different planet.
There are artistic reasons to tune this value, but this scene does not strike me as anything but a realistic human character on our own planet. But why is the value high? Sometimes, to counter some other issue; you want the overall motion to move down more strongly, so you crank up gravity. Intuitive.
But then Time Scale is set to 0.5, and now things get complicated. If gravity pulls your character 5x faster to the ground (-5000 cm/s^2 as opposed to -982 cm/s^2) , but time only moves at half-speed, what should we expect? Maybe 2.5x the gravity? Except forces are also accumulated at 0.5x the time step, meaning they double up; forces like contacts and limits.
Einstein would struggle to understand what should happen here, so your best bet is to leave Gravity and Time Scale at their default values at all times, unless you welcome their artistic (i.e. unrealistic) effect.
This one is most interesting. Some Markers have densities of up to 900 (!). What does this mean?
Let’s look at the intuitive case.
So far this make sense. Assuming these boxes are made of the same matter, e.g. wood or water, then the bigger box should weigh more. Sensible.
So what does “density” mean? Density is a multiplier of the volume of an object to determine its final mass. That is, if one box has 2x the volume of the other, than a Density = 0.5 would make it have the same mass.
Here’s a riddle for you.
Is it 2x lighter? 10x lighter?
Let’s find out.
Based on this simulation, we can surmise that a box with Scale XYZ = 0.5 has a volume 8x smaller than the box with Scale XYZ = 1.0. Is there any scientific backing for this? Yes!
And 0.125 is 8x less than 1.0.
You might then ask "why is the middle board wiggling, shouldn’t it produce an identical result to when the boxes had the same size and density? It should, until you realise that because of the small scale, the big box also reaches the board ahead of the small one, causing a slight tilt.
Now, what should we expect from a Density = 900?
Simply put, it does not compute. There is nothing on earth capable of interacting with a difference in densities this great. It’s as if you turned the box into a black hole.
There are solvers out there capable of simulating this scenario, scientists use it all the time to figure out the origins of the Big Bang. But Ragdoll is not one of them, and the character in this scene does not need it.
Unfortunately, each of the three issues listed affect each other. So it can be challenging to zone in on exactly which is to blame. But, what you can do is think twice whenever you find yourself needing to crank a value past 10x its default. “Is there a value I can reduce instead?” should be your first thought. And usually, there is.
Hope it helps, and let me know if you have any more questions!
Hi, needed to finish my current project before i could come back to this matter. Firstly, thanks for the time and effort you put into it…
So lets start with the limit issue:
Like we discussed in dm, the problem here is not to fix the limits (was forced to do it myself numerous times), but why they occur out of nowhere. Sometimes they happen when using symmetrical option in the manipulator. I mainly work on the left side, thats why the right elbow was buggy in this case, but happens on other parts too.
So again, why does the right elbow limit, which should be symmetrical to the left one, is bugging like this?
Now to the recording issue:
That happened after i followed your advice here
But i still dont understand how it can bug out like this since it just occured after applying “extract simulation” option. Also how come the floor is freaking out like that?
Then the “post credits”:
First of all like i mentioned in dm, this rig is pretty much experimental, because i struggled to achieve more realistic behaviour out of the simulation engine. Therefore i ended up with these extreme values, which somewhat gave heavier motion results…
Starting with the overassigning issue:
Not sure at all why i should remove these 5 markers. They are part of the spine hierarchy and absolutely need to be simulated by ragdoll.
The only difference between those markers and the rest is, that they dont need to be colliding with anything.
Can you explain further why they should be gone, again?
Lastly the rest of points regarding huge values:
They are the results of struggle to achieve realistic behaviour. With the default/initial values i got nothing but a cartoonish looking doll, with too stiff limbs.
Therefore i started to increase the mass first in hopes of getting more heavier motion and inertia and so on. Then adjusted everything else…
How else do i achieve realistic look? How to avoid the dolls motion to look like cardboard when colliding? Or when swinging an arm and it feels like there a lack of inertia of mass?
I´ll gladly redo this rig, if you can lead me in how to achieve realism with Ragdoll.
Thanks for taking the time and effort with this matter. Eagerly awaiting your advice here!
To answer this, I need to know what steps you took to produce it. Since I’ve got your asset, would it be possible to clear all physics and redo just one of the arms to the point where the error appears? A video would work, alternatively a series of steps I can perform here.
Here’s an example of what such a list of steps could look like.
In the Extract Simulation options, there is an option to constrain your character to the extracted hierarchy. This too is meant to debug any recording issues, it’s the same constraints made during regular recording. But they aren’t meant to be kept; they would prevent further recording since they now drive your character. You would use this extracted hierarchy to verify that (1) the simulation was extracted successfully and (2) the constraints drive your character as you expect.
Unclear, I did not investigate the floor.
If i could reproduce it, i would have posted a video long time ago. Its happening out of nowhere and not just the elbow, but any other part that is symmetrical worked on. Checking always, if its correctly working of course, but then after reloading the scene the next day or couple times after to continue working on it, its bugged like you saw in the example.
And yes the steps you described are exactly the way i tried to reproduce it. No success so far.
Let’s take a closer look. Here’s what the joint hierarchy and Markers look like at the moment.
When working with Ragdoll, it can help to think of your character as a physical robot.
Here, each limb connects to each other via a physical joint. The physical construction of the connection determines how and if a limb can move, let’s focus on the arm for example.
In Ragdoll, we can model the geometry in the same way which would make both limits and the need for overlap readily apparent. But because it’s tedious, and not necessarily useful for collisions, Ragdoll enables you to skip this step and act as though this is what it looked like under the hood.
You’ve now saved the time and effort involved in modeling things like this robot here, but you are still bound by the exact same laws of physics.
In the case of your character, here’s how Ragdoll expects limbs to connect.
Where 2 overlaps with 1, 3 overlaps with 2, and so forth. Just like in the case of that robot. But instead:
2 does overlap with 1, but then 3 does not overlap with 2 - instead there is a large gap between them. This cannot exist in reality; think of the physical robot above and how you would manufacture this limb.
Then 4 is especially troubling, because although 4 does overlap with 3, it also overlaps with 2 and 1. This has no connection to reality anymore, it simply cannot exist and Ragdoll cannot know what to do with this.
In these scenarios, it’s perfectly fine to only include 1 and 3, skipping 2 and 4 entirely, depending on around which pivot you would like Ragdoll to rotate the head.
Does that help?
So to understand this right, Ragdoll can only handle overlapping markers that are neighbooring each other and it has nothing to do with collissions but their shapes?
For example, if i´d want to keep all 4 markers i need to reshape the markers so that just neighooring overlap?
Guess i can get rid of marker 2 and 3, but there are markers at her spine that need to be simulated. Then i just need to replace their shape? if thats how Ragdoll works, that is fine by me.
On a side note, what kind of troubles do these overlapping markers cause since i didn´t encounter any issues so far by keeping them?
Faulty simulation results or jittering markers e.g?
