I’m using a dynamic force applied to the torso link to simulate a high velocity knockback from an explosive blast, and whenever the ragdoll hits the terrain at a weird angle with a high velocity, the model’s legs, arms, and head are prone to phase through the terrain.
Is there any way I can fix this with different settings to the DAC? I also tried setting a CCD motion threshold and radius on the terrain, but the issue still persists.
I can post a short clip demonstrating the issue as well if that would be helpful.
Thanks, setting the CCD parameters as you suggested appears to have fixed the problem for the most part.
The issue went from happening almost every time to happening only 1 or two times out of a few hundred attempts, so I think that is an acceptable margin for error, and the two times it happened corresponded to a lag spike and only a small part of the hand passed through the terrain, so it was barely noticeable compared to before.
Sure, here’s a clip I took that shows the issue before I set CCD parameters to fix it.
Now my next plan is to apply some forces to the ragdoll’s arms and legs when she’s on the ground to make her roll into a plank-like pose, either on her stomach or back, and then play a corresponding stand up animation to simulate a smooth recovery process following a knockback like this.
btw. i belive its same issue i had when shooting “bullets” into ground. Fast moving physics objects might pass through “plane”/“heightbased” collisions. CCD parameters solved that mostly.
If you still see occasional terrain penetration, you might try a lower CCD threshold, for instance:
rigidBody.setCcdMotionThreshold(radius/3f);
The threshold trades off CPU consumption for accuracy. Depending on your app and your hardware, you might be able to go almost to zero without seeing any performance impact.
To me, this approach sounds very tricky to get right … so many forces to calibrate and situations to handle.
When I considered this sort of effect in the past, I thought of enabling springs on the physics joints in the ragdoll. The idea was to fix the setpoints of the springs when the model was in a fetal pose, so that the ragdoll would tend to revert to that pose instead of, say, a T-pose. This would still create a slew of parameters to tune, however.
I’m now encountering another issue that has started happening since I began setting a CCDMotionThreshold and SweptSphereRadius on the DAC’s physics links.
It appears this is causing the physics links within a single DAC to collide with each other in weird and buggy ways that causes the limbs to stretch and contort in unatural ways when the force is first applied, and the issue becomes worse when the force being applied is greater. Sometimes it will even cause a limb to become pinned in mid-air and extremely stretched out as if it got caught on something that isn’t there.
The issue stops when I remove the code setting the CCD threshold and swept radius, but then I’m back to having the limbs clipping through the ground again. Specifically it seems related to setting the swept sphere radius, and will not happen if I only set a CCDMotionThreshold.
It seems like the physics links need to have the CCD values ignored when colliding against the other physics links within that same DAC, but I’m not sure if that’s something you could easily do?
I can also try to get a short clip demonstrating the way the joints bend unaturally and sometimes become pinned in mid-air when a force is applied if that would help to better explain the issue.
Collisions between bodies in the same ragdoll are special. There’s already a mechanism to ignore some of those collisions, and I believe the mechanism applies to CCD as well as normal collisions, though without studying the code, I can’t swear to it. Seems worth trying anyway … void setIgnoredHops(int numHops)
The default for the “ignored hops” parameter is 1, which means that collisions between bodies that share a physics joint are ignored. Try raising this parameter to 2 or 3, which will additionally ignore collisions between bodies that are separated by 2 (or 3) physics joints.
If that doesn’t help, then a video clip might help me understand what’s going on. Even better would be a simple test case that I could experiment with locally.
If necessary, I’m sure I could add a mechanism to disable CCD between bodies that are part of the same ragdoll. My only hesitation is that com.jme3.bullet.animation is already a complicated software package with a plethora of mechanisms and tuning parameters; adding a new mechanism risks introducing bugs and/or making the package more difficult to test and use.
I tried setting this to 2 and 3, and it appears to worsen the issue and made it happen more often while CCD was enabled. But with CCD disabled I could set it between 1 and 5 without the issue at all. I tried setting it to 0 hops just to see what would happen, and it caused the model to twitch and convulse but the twitching is much less natural and more sporadic with CCD enabled, so it seems like enabling CCD will always cause the ragdoll to collide differently with itself in some way.
Here’s a clip showing the issue without changing the hop count and with CCD enabled using this code:
I’ve tried adjusting those CCD params a bit as well to see if I can find a sweet spot, but it seems like changing the motion threshold doesn’t make the issue change at all, and removing or lowering the swept sphere radius seems to make the issue go away, but then the CCD stops working and limbs start clipping through the ground again.
I believe the twitching with ignoredHops = 0 is caused by conflicts between rigid bodies that share physics joints. Since ignoredHops = 1 has always been the default, that doesn’t worry me at all.
After viewing the video clip repeatedly at full resolution, I’m convinced that some of the joint limits are ineffective. I haven’t decided whether the angular limits are the only ones affected or whether both angular and linear limits are affected. In a ragdoll, ineffective linear limits usually result in the appearance of ribbons at the physics joints, as the model stretches to accommodate the motion of the rigid bodies.
Could I please see a comparable clip with CCD disabled?
One thing that’s puzzling me is that I have a closed-source project that enables CCD on ragdolls, and I don’t currently see distortion of this sort. I wonder whether the difference in behavior is due to differences in the models, the software, or both.
Another thought: there have in the past been bugs involving CCD, such as JME issue 1283. So please report which versions of Minie and Libbulletjme you’re using. Also, what is the physics time step?
Yeah here is a video showing the ragdoll working normally a few times without CCD:
And here is another shorter video showing the problem occurring with CCD enabled. The issue is much more noticeable in this video than the clip I put in my first post. The problem usually happens inconsistently but I managed to get a good clip of it happening noticeably twice in a row:
I’m using Minie 6.0.1
And I’m not quite sure how to find the version of Libbulletjme or the physics timestep, but I haven’t done anything to set / change either of these that I’m aware of so I think they should be whatever is the default.
A dramatic illustration of the problem! Thank you for sharing the new clip.
I suppose the stretching of the upper body around 0:04-0:07 might be due to one or more physics links (possibly the right shoulder) getting snagged on a physics object near the top of the viewport. But at this point, I don’t have a plausible explanation for why the problem occurs only with CCD enabled. Without being able to run the app locally, I can’t say much more than that.
When debugging issues like this, one of my usual strategies is to reduce the app to a reproducible test case, such that the result doesn’t depend on real-time inputs such as keyboard and mouse. That way, when I tinker with the code and/or model, it’s likely that any changes I see are caused by my tinkering and not by different inputs.
The Libbulletjme version string is printed to standard output during initialization. The message should look something like this:
Libbulletjme version 16.1.0 initializing
You can also obtain the version string by invoking NativeLibrary.versionNumber() at runtime.
I’m still curious about the physics time step. You can obtain its value using physicsSpace.getAccuracy().
I’m also curious whether halving the time step might mitigate the problem.
It’s usually a good idea to enable debug visualization, using bulletAppState.setDebugEnabled(true). If there are invisible physics objects in the scene, that should reveal them.
Finally, you might try replacing version “6.0.1” of Minie with version “6.0.1+debug”. The debug libraries perform extra checks that may uncover software bugs.
I tried halving it right after initializing the bulletAppState with bas.setAccuracy(bas.getAccuracy() * 0.5f) and it makes the issue happen worse and more often when CCD is enabled. Halving the timeStep did not change or break anything when I did a test with CCD disabled though, it only worsened the existent bugginess with CCD enabled.
I tried this as well and then did some tests reproducing the error a few times, but I didn’t have any different results and did not see any errors or anything printed out in the console output.
Here’s another short video showing the error happening with the debug wireframe enabled. There doesn’t appear to be any other physics bodies in the air, but it does look like the DAC’s physics links end up pushed inside of each other at some points while the buggy behavior is occurring, and I also noticed 2 other buggy things with the wire frame debug enabled that I included in the video.
After I display the original ragdoll bug with CCD enabled at the start of this video, I then move the character around at a fast speed and that causes the wireframe for the DAC’s physics body to lag behind the model, and it gets much worse and sometimes suddenly flickers whenever you move faster.
And then for the last section of the video, I show the character playing a roll animation in kinematic mode, but the torso link does not follow the animation and remains in its original position floating in the air (I’ve also experienced buggy ragdoll behavior when the player gets put into ragDoll mode in the middle of the roll animation, so I suspect this frozen torso link is what caused that). I also showed this happening with another ogre model’s death animation where the torso link remains floating in its default position even when the rest of the ogre’s physics links are correctly following the death animation.
Hopefully this extra information helps to point us closer towards the source of the problem. I can provide more information if you think of anything else worth checking / trying, and I will also work on putting together a test case that reproduces the issue and will post that in the next few days when its ready.
Thanks for running the experiments I suggested and reporting the results.
The visualization lag is irritating, but I don’t think it indicates a serious problem. It might have to do with update order.
On the other hand, the misbehavior of the torso link (during rolls and death animations) seems noteworthy. I think it’s more likely to be a DAC bug than a debug visualization bug. I’d like to solve that before pursuing the CCD issue further.
I’d like you to update Minie to v6.1.0, which includes a bug fix related to DynamicAnimControl.
Unless that solves everything, I’ll look forward to experimenting with the test case when it’s ready.
I upgraded to Minie 6.1.0 but it did not appear to change anything with the issue. The bugginess still occurs with CCD enabled and the torso link is still stuck in mid air during the roll animation.
However I did notice that, for the female elf model, the torso link issue only occurs with the roll animation, but does not occur with her death animation. I think this might be related to the whether the animation uses the rootBone or the pelvis bone for controlling the rotation of the entire model.
I looked at both animations in blender, and it looks like her death animation uses the rig’s root bone for rotating the model, wheras the roll animation uses her pelvis bone to rotate her model during the roll.
I didn’t animate the ogre model that also is having this torso-link issue, but that model appears to be rigged and animated in a similar way where there is a rootBone, but then there is also another pelvis / torso bone that is a direct child to the rootBone and a parent to every other bone, so it effectively acts like a secondary root bone. It seems like the DAC’s torso link is ignoring this extra pelvis bone and only listens to the rootBone.
I also tried going back into the DACWizard to see if i can change the setup of the torso link, but when I am on the step to select the bones to be linked, it appears to not let me select the “root” or “pelvis” otherwise it gives a warning saying “No mesh vertices for the torso” since they both have indirect mesh influence.
It seems like the DAC’s torso link is ignoring this extra pelvis bone and only listens to the rootBone.
Minie v5.0 introduced a mechanism to specify the main bone of a ragdoll when it doesn’t happen to be the skeleton’s root bone. Unfortunately, DacWizard doesn’t know about this feature yet; it’s something you have to code by hand, invoking dac.setMainBoneName("pelvis") (or whatever) before the DAC gets added to the model.
I finished making a simple test case. I uploaded 2 java files as well as a single .j3o file (the model I’m having trouble with) to this github repo:
I based it off of the last test case I made for when you helped me with another DAC issue earlier this year so it might seem familiar.
If you press N while running the test case, it will spawn in a copy of the female elf model in front of the camera and force the camera to follow the model, then after 2 seconds she gets launched in the direction the camera was facing when you pressed N, and the camera continues to follow the model in ragDoll mode for 6 seconds. After that the camera is released and you can spawn another model in front of the camera by pressing N again to repeat the process.
Whether or not CCD is used is determined by a boolean at the very top of the Main class that you can change from true to false before running the app to compare the bug against normal behavior. And the second class included in the test case (ElfCharacter.java) is where all of the DAC related code is at, so if you need to see or tweak any code with the DAC its all in that smaller class, while the basic initiation for things like setting up the terrain and listening for input is in the main class.
It seems like the test case does a good job reproducing the issue consistently when CCD is enabled, and after a few launches you will likely get at least one where the bugginess is very obvious, but let me know if you have any trouble reproducing the issue.
And thanks for all your help debugging this issue so far
