Tracking centre of mass as mesh deforms: Is it possible?

[weThereYet (Yan)]

Essentially a script or technique through constraints that dynamically replicates the “set origin to geometry” option, but that I could let’s say add this behaviour dynamically to an empty or centre of mass bone. If there is only a especially complex way, I’d probably be better off to achieve my effects manually due to time as always. (but happy for any answer even so.)

Simply put: a given character bends (the mesh deforms) and the origin offsets in theory.

Probably mixing up centre of gravity and centre of mass, but it is the principle I am after (the average centre of the mesh, dependent on its shape.).

The best compromise is that I’ve for all this time missed a “set 3d-cursor to geometry”, I do not believe I have. (And I’m aware of origin to geometry, but it adds unnecessarily to the flow for my style of animation.)

[bandages]

I know of one method. No idea if it’s too complicated for you. It’s probably not very much use in most circumstances.

So we’ve got a deforming mesh, and that deformation changes its center of mass, and however it deforms, we want to teleport it so that its center of mass remains in the same place, right?

We can get the center of mass using GN. Make a big grid of dots, big enough to encompass the space of anticipated deforms; then, remove all the dots that are outside the mesh. (Probably, by sample nearest surface, compare vector to position to surface normal at that position.)

If we get the mean position of the remainder, and everything’s the same density, then we get the deformed center of mass. We can then re-instance the deformed mesh at the location we want to keep consistent. (Desired center of mass could be a moving target.)

Drawback #1: This is a sampled technique to calculate center. There’s noise. If we use few vertices in our grid, that noise will be large; if we use a lot of vertices, that noise will be small. It would probably, technically, be possible to measure the volume of a manifold mesh that didn’t self-intersect, but I think it would take a long time and be complicated to implement. Some kind of temporal smoothing of the sampled center might help, I don’t know.

Drawback #2: Most of the time, you want deformation that responds to the center of mass. If a character rocks on their heels, their heels stay in the same place regardless of center, right? Their heels don’t just teleport with their changing center of mass. But the motion of their legs, in turn, changes where the center of mass actually is. So if we wanted to do this with a character, it’s potentially an iterative process: check center, redeform; check center, redeform-- etc. That doesn’t strike me as practical.

[weThereYet (Yan)]

Then I’ve gotten a good answer to the wrong question on my end, sorry. What I got from that CoM is fixed regardless of shape, i.e., if a characters CoM is at their hips it’s always at the hips, e.g., teleporting mesh to the updating origin.

(Apologise for being rudimentary, recalling knowledge mostly as the need arises. Understand the principle, not versed enough to implement it quickly at this time. Guess it could constraint wise be achieved through boolean and shrinkwrap used in its projection/raycast capacity or geometry nodes maybe.)

Back to the point. I am trying for a discount solution to what you’d see in “Cascadeur” i.e., the character counter-balancing shifts of weight/CoG (see image) then without dying in cyclical dependency hell on an armature.

An excuse to pose is an excuse to pose.

Really only thing I could see working is a reference point (empty/bone) offsetting with the mesh deformation (the key being that it only ranges between 0 and the developed offset) that I could copy transforms from onto (assuming a IK-rig) to a hip bone for instance. Assuming single direction of gravity, armature lifts arm (mesh deforms from base state), CoG offsets, CoM (hip bone) compensates/balances in location and/or rotationally.

Have a halfway solution I saw in another post implicitly accessing delta time in the most practical way possible through duplicated armatures using the same action in NLA but with start frames offset from each other, essentially acquiring speed and acceleration with drivers or copy transform/child_of thereafter. But it assumes that the brunt of whatever animation is in a single action, scaling real bad in certain scenarios.

I’m forced to be as pragmatic as possible, as import/export workflow between “Cascadeur” is lackluster in terms of time efficiency even with a bridging addon, at least until it both works better with rigify armatures and I upgrade hardware to be able to process/export large scenes quicker.

Appreciate the input, helps my thinking a lot.

[bandages]

@weThereYet

What I got from that CoM is fixed regardless of shape, i.e., if a characters CoM is at their hips it’s always at the hips, e.g., teleporting mesh to the updating origin.

I’m not sure that’s the right takeaway. Let’s look at something where this would be practical:

We’ve got a ball, with a shapekey (next to it). The ball travels the parabola, but we want its center of mass to travel the parabola, not the object center, and the object deforms. So we find where the center of mass is, relative to the object, and move the object such that where its center of mass was moves to where it should be:

Does that make sense? And this would work-- would even be a good idea-- for like a pole vaulter or something as well. They pose about their center of gravity, which moves in a parabola, even though the position of their spine bone changes in relation to that center of gravity-- sometimes, the COG isn’t even inside their body.

For something like what you’re showing, I don’t think an automatic solution inside Blender is best. But, you could use the technique I mentioned to give you a dynamic indicator of your COG while posing. It doesn’t require any iteration to say, now it’s here, now it’s there. And it would be possible to bake that CoG indicator and reorient things to keep it relatively static, either by skating feet, or by just accepting that bending the legs wil change the CoG, but it’s okay, they’ll only change it a little bit.

[weThereYet (Yan)]

Ok. So the CoM does shift with the shape, if I now catch you correctly.

Looks like the view is orthographic so I’ll run with it. The dot is the new assumed CoM after deform?

So CoM locks to the original curve of motion (when it is a ball) or does it imply a new curve of motion from the instance the shape shifts?

In either case I’d guess you’d run your solution in your first comment across the timeframe the shape changes.

Either potential ouch here in my case at least is that I’d have to save whatever target poses the character moves between as shape keys and probably have a set of reference shapes that I could derive the CoM to approximate it for similar poses when animating normally beyond that.

But, as long as I can potentially achieve a reference point dependent on mesh shape it might actually be real good.

Appreciate you answering my probably grade school physics problems, but its so far behind me now that working the problem intuitively is what I got atm.

Gonna see where this gets me.

[bandages]

The dot is the object origin, not the center of gravity. We can’t change the object origin. What we can do, is change the mesh such that its center of gravity is at the object origin, regardless of how we deform the mesh. (Or, that the CoG maintains any particular relationship to the origin.)

Here, I’ve been translating the mesh. This is appropriate for a falling body like I’m showing. It wouldn’t be impossible to rotate the mesh instead. For something that’s kinda like your red dot pic, where you were talking about Cascadeur (don’t know that, I’ll have to look it up), it would be more appropriate to rotate about a position on the ground instead.

Now, if we had an armature, we could do all of this stuff on multiple objects, maybe multiple armatures: first we take the base pose on a mesh, find the location of the CoG; then we do transforms from some known point to that point, translation, scaling, whatever (usually we don’t care if CoG moves up or down slightly, we’re concerned about it staying inside the world XY box of the feet), then we could write that new position to, say, a root bone (via constraints targeting GN mesh objects,) and re-deform the mesh. If we have IK legs that aren’t parented to the root bone, they’ll stay where they are, meaning the new mesh shape is different than the first deformation we measured, so the CoG we calculated won’t be accurate any longer, but it’ll probably be close enough.