What causes jittering physics?

[Hogarth-MMD]

I am trying to automatically add physics to a model with Blender python. There is no animation on the model. It is completely stationary. There are no overlapped rigid bodies. I intentionally chose small size rigid bodies to avoid that problem. But the physics of my model are jittering wildly and chaotically. Any idea what causes the problem of jittering physics? This is happening in Blender after pressing the Physics [Build] button.

[nathanvasil]

In my opinion, creating physics for a .pmx model is one of the very few things that's still easier to do in PMXE than in Blender. (But sizing and orienting bodies+joints is easier in Blender.)

If there are no intersecting collision bodies, jittering is likely due to rigid body constraints that don't allow the rigid body to come to a stable position.

As always, a good place to start is by reducing it to its simplest form: an animated rigid body (bone-type), a dynamic rigid body (physics-type), and a single empty (joint). Does twitching persist in this simplest form? If not, how complex can it get before it starts twitching?

If the simple systems twitch, check all constraints for "valid" ranges (ie, 0 rotation / 0 translation should be allowed by the constraint.) Then disable any constraints that lead to a body constrained by multiple constraints, which can create restless situations. Finally, try disabling gravity temporarily.

If you have a .blend file that you'd like to me to look at, feel free to link it.

[Hogarth-MMD]

https://sta.sh/01fkozwk7dh1

Okay, here it is. If anyone asks you about this model, you can say that it is a hurricane hair dance model which has been created by the highly skilled physics rigging artistry of @Hogarth-MMD . :smile: If you can decipher how to correct this rig, I will be impressed. Right now I'm confused and groping in the dark.

[nathanvasil]

Okay, first pass, looking over it for five minutes. Since you sent me a .pmx I looked at it in PMXE instead of Blender. Since your bodies have Japanese names, occasionally duplicated, I'll refer to them by their numbers.

You do have intersecting rigid bodies. For example, look at rigid bodies 44, 45, and 17. This kind of situation exists throughout the model. These rigid bodies are all in collision with each other.

Note also that 32 starts in collision with 14. Just barely. I don't think that was intentional. Not a big deal though.

Plus, you probably shouldn't attach multiple rigid bodies to the same bone (like 44 and 45.) I'm not sure exactly what this is doing, but at best, it does nothing, picking only one of these rigid bodies to follow.

After I deleted all of the rigid bodies that looked like unintentional duplicates, and all of the joints that were broken by those deletions (physics associated with hair and tie), it works fine in MMD and in Blender.

[Hogarth-MMD]

Thanks @nathanvasil ! :+1: That is very helpful information. In Blender after mass adding physics from a python script, the passive rigid bodies were not being displayed in Blender. Even after I manually enabled the display of rigid bodies in the MMD Display panel, the passive rigid bodies continued to be invisible. That is why I did not understand that overlapped rigid bodies were happening. This invisibility of passive rigid bodies is different from what happens if physics are added the normal non-python way in Blender. So, now I have edited my python script to fix this issue, and enable the correct display of rigid bodies. More work is needed to fix the other issues. Lots of work for me. :smile:

[Hogarth-MMD]

Okay, fixing Haku's bad hair day was not too difficult. Her hair bones are named differently from usual, so my Add Physics operator did not understand that they are hair bones. Issues of overlapped rigid bodies can be solved by collision groups and collision masks, can they not? Is that not what the purpose of collision groups and collision masks is?

There are 3 types of rigid bodies: Bone: static space-filling physics, bone is parent of rigid body Physics: bone copies location of rigid body Physics and Bone: bone copies location and rotation of rigid body.

Do I understand these types correctly? And which type is best: Physics or Physics + Bone? This is an important question that I need to know the answer to.

[nathanvasil]

Issues of overlapped rigid bodies can be solved by collision groups and collision masks, can they not? Is that not what the purpose of collision groups and collision masks is?

Yes, they can; yes, that's the purpose. Well, sometimes you want to control collisions even between bodies that are not overlapping by default, so maybe better to say, that's part of the purpose. (Note that Blender provides some additional tools for this, like allowing bodies to ignore collision with other bodies sharing a particular constraint.)

Bone: static space-filling physics, bone is parent of rigid body

Yes. Used for collision or as the anchor of a joint/constraint.

Physics: bone copies location of rigid body Physics and Bone: bone copies location and rotation of rigid body.

Both physics and p+b copy both location and rotation. In the case of p+b, rigid body and inputted (including via constraint/append/parent/whatever) bone transformations are combined for the final bone transformation. Transformations aren't precisely copied; rather, the bone acts as a child of the rigid body. So for example, it rotates about the center of the rigid body, rather than about its own center.

And which type is best: Physics or Physics + Bone?

I don't think this is a situation with a simple "x is best" answer. Use what you need, for what you want to do. But most of the time, you'll see MMD models use physics (only). Among other possible reasons, using physics-type bodies will lead to the best agreement between mesh and collision bodies.

[Hogarth-MMD]

Thank you for all of your helpful insights @nathanvasil . This isn't crystal clear to me yet:

" In the case of p+b, rigid body and inputted (including via constraint/append/parent/whatever) bone transformations are combined for the final bone transformation. Transformations aren't precisely copied; rather, the bone acts as a child of the rigid body. So for example, it rotates about the center of the rigid body, rather than about its own center."

It's seems that I need some kind of simple example model with example animation to clarify this. I'm not sure what the best test/example model with animation would be for this.

[nathanvasil]

Sorry, I worded that poorly, and also was just plain wrong about the way p+b works.

With a physics-type body + bone, the bone acts as as a child of the rigid body (rather than of its parent bone.)

With a bone+physics-type body, the bone appears to acquire its position from its bone parent, but inherits rotation from the rigid body (only from the rigid body, not in addition to its bone parent.)

In neither case does the bone's own transformation, including from appends, have any effect on the bone's final (visual) transformation.

https://mega.nz/#!iXgyTKya!qcW3g5RQ8hEq_rqcIS0Jx0yf02ty3F-ijouCp94pXns has the file I used to test this out.

[Hogarth-MMD]

Interesting! Thanks for your research. So Physics+Bone type has immobilized location relative to the bone, if I understand correctly. It folds without stretching or compressing. I think it's possible to also immobilize location with a Physics type rigid body, just by using settings of the rigid body or joint. So the Physics+Bone type doesn't seem to be needed.

[Hogarth-MMD]

Okay, a zillion diagnostic prints and test runs, later, there remain unsolved issues:

1. Using collision groups and collision masks to prevent physics jitter is a very nice idea IN THEORY. This method was successful with a simple test model. BUT to avoid the problem of physics jitter, the hair rigid bodies need to avoid colliding with and overlapping with, the body of the model and the skirt rigid bodies need to avoid colliding with and overlapping with the body of the model. In that case, the hair and skirt will be passing through the body of the model.

[Hogarth-MMD]

2. In addition to the 2 causes of physics jitter that we already know about, I have found that incorrect parent-child relations of bones can also cause this issue.

[Hogarth-MMD]

3. I cannot control the size of the rigid bodies. mmd_tools seems to be using some kind of weird, complicated mathematical formula for the rigid body sizes. The rigid body sizes that you choose in the Add Rigid Bodies dialog box are not in Blender units and they are not the same as the bone length. I do not understand where these bone sizes are coming from. Some help from @powroupi would be helpful in this aspect.

[Hogarth-MMD]

Here is another interesting puzzle: What are the ideal default physics settings for hair, skirt or whatever? I was thinking that it might be nice if we can have some scientifically exact physics settings for hair, skirt or whatever (if that is possible, without spending an excessive amount of time researching it).

[Hogarth-MMD]

For Box or Sphere rigid bodies, scale z 0.5 and the rigid body will have exactly the same length as the bone. For Capsule scale z 2/3 and the rigid body will have exactly the same length as the bone.

[Hogarth-MMD]

Blender's cloth physics has 5 presets: Cotton, Denim, Silk, Rubber, Leather. It would be cool if those presets could be converted for MMD rigid body physics. I have no idea how or if that could be done, though.

[nagadomi]

I cannot control the size of the rigid bodies

You can change the size with Object Tab > MMD Rigid Body. Or, If you are using object scale operation, you need to apply the scale change with Object Menu > Apply > Scale.

[Hogarth-MMD]

fallling and bouncing jitter https://sta.sh/022brqmrzhlf

I have made this perpetual motion machine! Now all I need to do is persuade a wealthy financier that MMD physics works exactly like real world physics and I will be a wealthy man. :smile: Theoretically collision masks and collision groups protect against physics jitter, but in this case that is not effective. I am not sure what causes this type of physics jitter, or how to fix it. Maybe it happens because the top bone in the chain is falling by rotating(?). To see this physics jitter, load the model in MMD, select Physical Operation, Display Bodies. Shake the model back and forth a little with the model move controls.

[Hogarth-MMD]

After unsuccessful attempts to troubleshoot the falling and bouncing physics jitter, I am beginning to realize that there are very fundamental aspects of MMD and Blender's rigid body physics that I don't understand, and I need to study up.

Are there any parent-child relations happening between rigid bodies and joints?

Are joints bound to their original locations? And when they reach their maximum limit distance away from their original location do they bounce back as if colliding with an invisible barrier?

Do joints have attractive or repulsive forces?

[nagadomi]

I am not sure what causes this type of physics jitter. But it can be solved by setting mass of hair4 ~ hair7 to 0.1.

MMD and Blender's rigid body physics

As far as I know, both MMD and Blender use Bullet Physics library, but MMD uses a very old version. In Blender we can change the accuracy of physics simulation with Scene Tab > Rigid Body World > Steps per Second / Solver iterations, but it can not be change on MMD (60FPS makes it a little better). Probably it is poor accuracy.

[nathanvasil]

Are there any parent-child relations happening between rigid bodies and joints?

Not exactly, but... In MMD, the joint is mostly like a child of its first rigid body, while its second rigid body is a little like a child of the joint.

Are joints bound to their original locations?

Not exactly, but close to it. Physics are not exact. Limits are suggestions, not hard limits.

And when they reach their maximum limit distance away from their original location do they bounce back as if colliding with an invisible barrier?

Yes, if I understand you correctly. Same goes for angle limits. That's probably the jitter you're currently seeing: it gets pulled out of limits, then yanked back into limits.

Do joints have attractive or repulsive forces?

Both, yes. That's why they have both minimums and maximums. Don't forget to use "spring" to smooth out these forces.

Blender's cloth physics

Blender's cloth physics use a different way of doing physics, one not supported by MMD. (It's soft body physics in nature, so might be supportable by MMM, not sure.)

It can be tricky to develop an intuition for physics. Try re-creating structures from models that you like, and eventually you'll get a feel for it. Outside mass, rigid body settings are all in 0,1 range; most modellers use move attenuation higher than default, like 0.9 or so, to accentuate physics. Placement of joints and rigid bodies is the most important thing; joints should usually be centered on bones, while rigid bodies should usually either be centered on bones or span bone lengths. Try to avoid angle limits (use -180 t0 180 if you can) and provide enough spring to keep physics behaving how you'd like instead. The amount of spring you need is proportional to mass (including masses of further bodies ultimately dependent on the joint) and so might be a huge number like 1000.

[Hogarth-MMD]

It would be very nice to diagnose and prevent overlapped rigid bodies. using Blender python. I did a Google search and I found these stackexchange pages, about mathutils BVH tree overlap():

https://blender.stackexchange.com/questions/9073/how-to-check-if-two-meshes-intersect-in-python

https://blender.stackexchange.com/questions/45827/how-to-check-if-two-meshes-intersect-in-python-with-bvh-tree/45834

https://blender.stackexchange.com/questions/71289/using-overlap-to-check-if-two-meshes-are-intersecting

I haven't tested this yet. The mmd_tools sphere rigid body is not a perfect sphere and the mmd_tools capsule rigid body is not a perfect capsule shape, so maybe this is a problem, with the detection of overlapped rigid bodies(?).

[nathanvasil]

Rigid body capsules and spheres, in reality, are more perfect than any mesh representation could ever be. They're mathematical, not based on faces: a sphere is the space defined by a given radius, whereas a capsule can be seen as two spheres as well as the cylinder that connects them. (And a box is mathematically defined as well.)

You can provide any mesh to Blender and tell it to use a given shape-- you could for instance make a sphere and tell Blender that it's a box. Blender will do its best to smartly map the rigid body's dimensions to the mesh. But the boundaries of the mesh don't perfectly define the boundary of the rigid body. (Unless its a mesh-type body, or a convex hull-type body using an appropriate mesh, two types of bodies that are unsupported by MMD.)

If you want to do this in script, techniques using meshes are going to be both more complicated and less accurate than techniques using the mathematical definitions of the rigid bodies. Blender almost certainly provides some tools for this, because the basis of its rigid body physics is the ability to tell if two rigid bodies are in collision.

However, it's not really a big deal, because it's rare that you need to carefully control for overlap anyways. Instead, use collision groups to prevent collision between two overlapped rigid bodies.

[Hogarth-MMD]

mmd_tools is using some weird complicated math formula for the size of rigid bodies. I cannot make any sense out of this mathematical formula and the size of rigid bodies does not seem to happen in accordance with this math formula. This seems to be an mmd_tools bug. Quoting from the mmd_tools source code:

        size *= target_bone.length
        if 1:
            pass # bypass resizing
        elif self.rigid_shape == 'SPHERE':
            size.x *= 0.8
        elif self.rigid_shape == 'BOX':
            size.x /= 3
            size.y /= 3
            size.z *= 0.8
        elif self.rigid_shape == 'CAPSULE':
            size.x /= 3

[Hogarth-MMD]

I just endured a marathon trouble-shooting session with this &^%&%& falling and bouncing physics jitter issue. I was almost going to announce that I am giving up on this Add Physics operator, but as I was intending to announce my defeat, a new idea has entered my mind, but I have not yet tested this idea.

My LAST idea before giving up:

Maybe this is a falling by rotating issue. Either the bones involved must begin in a completely straight vertical angle, or they must be able to rotate into a completely straight vertical angle.

[Hogarth-MMD]

If I understand the mmd_tools source code correctly, this is how the size of rigid bodies works:

'SPHERE' x = radius, y and z are ignored 'CAPSULE' x = radius, y = height, z is ignored 'BOX' x,y,z = width, height, depth (The size is a multiple of the length of the bone.)

The interface and tool tips of mmd_tools completely fail to clarify this. This lack of clarity of the mmd_tools interface is a very bad mmd_tools bug.

[Hogarth-MMD]

My "last" attempt at fixing the falling and bouncing physics jitter was not successful. This problem is worse in MMD than in Blender. At this time I am "sitting on the fence" as far as giving up and quitting is concerned. Maybe later I will think of a new idea.

[Hogarth-MMD]

The dimensions of a 'CAPSULE' rigid body that you see in the 3D view window are not necessarily the same as the dimensions of the 'CAPSULE' rigid body that you see in the MMD Rigid Body panel. This seems to be another mmd_tools bug.

[Hogarth-MMD]

I was thinking of rigging skirt bones or hair bones with IK, as a possible solution to this issue. All physics rigid bodies would be on the IK target bones. That wouldn't work though, I don't think, because the IK target bones would still need to be constrained from falling.

[Hogarth-MMD]

Okay, it looks to me like I made the mistake of choosing a physics test model which is the physics test model from hell. Its original condition, and my physics rigging of it, produce a physics rig which has not one, but several issues simultaneously. These issues may be, but are not necessarily limited to:

rigid bodies too small overlapped rigid bodies disconnected bones joints immobilized from rotating or moving (Joints must be given freedom to rotate and move , but not excessive freedom to rotate or move.)

I cannot provide any definitive or reliable information about any of this, however, until I first have or make several test models, each of which has ONE, and only ONE of each of these issues.