eulaliecoevoet / adaptivemerging Goto Github PK

I have noticed some unwanted occasional bounce effect... (even if the restitution is zero)

RigidBodies have a BodyContact list, and the body contacts have the contacts, so we don't need a list of contacts in the rigid body. There seems to be a half dozen places or more where this is maintained, and otherwise unused, so an easy candidate for cleaning!

Two options. We can merge everything into one clump if they are connected by the same body... (i.e., in the inertial frame), or we can try to keep them into different merged islands, but in the inertial frame.

I think it is easiest to consider simply merging pinned bodies into the collections and seeing what happens! I think it will simply work!! Just want to make sure that the velocity of the merged body is zero, and perhaps propogate the pinned property up to the RigidCollection. COM doesn't need to be set or changed, while minv and jinv for the collection are simply zero.

I'm looking forward to trying this demo. Thank you for sharing the code.

The README.md mentions running the app src/mergingBodies3D/LCPApp3D. I can't find that file. I do find src/mergingBodies3D/LCPApp3D.java, but it's been a long time since I've compiled/run java code.

I tried issuing javac src/mergingBodies3D/LCPApp3D but I got 100s of errors.

What's the right way to build/run the 3D demo?

I'd like to see a version of merged body colourings that uses random hues. I'm not sure if it matters so much if the colours randomly change on merging and unmerging... but if we cared to try to make some temporal consistency, then a merge could always preserve the colour of the larger collection, and same for unmerging.

See the new jam*.png examples. If two objects merge with a single contact, propped up by a 3rd body, then when they merge, they become rigid, and the external contacts will not stay fixed to keep everything in static equilibrium. I wonder if this can happen in a wider variety of cases? Best initial fix would be to merge anything ready to merge in one go, but perhaps we'll need to walk the graph and detect properties? To discuss!

Two issues here... one is my general uncertainty as to using relative velocity as a merging criteria, or if we can't monitor a relative velocity energy. Should probably look like

v^T (J M^{-1} J^T )^{-1} v

Where J maps the two bodies to a combined COM frame, and v has the relative velocities computed in this frame.

Anyway, the other issue is that in watching the spinner, while the linear velocity was what was keeping the bodies from merging, I was surprised to see that the angular velocity had a fairly large mis-match, on the order of 0.01 rad/sec. Perhaps 1000 PGS iterations is not enough? Might be worth another look to see if this kind of innacuracy is expected, perhaps using a spinner with larger blocks?

Contact jacobians for those contacts that live within a collection need to be updated for the single cycle PGS touch-up solve, but likewise, those forces on an unmerge serve as a good warmstart. This needs some careful bookkeeping.

When lifting a sub stack in a bigger stack... the contacts that go down to zero force with the single step PGS should become active, and the rigid collection graph should be split in 2 on this "edge".

Or... will this cause a problem in a more complicated jumble, if the top is still rigidly connected to the bottom through different internal constraints!? To discuss!

When we merge with pinned a body, there are still some problems with the jacobian of contact. See example jamTest.png

A spring is only between a point in a body and a point in the world. Seems like there are too many members.

When you have this configuration:

The contact pruning between the collection and the pinned body makes the update of the contacts in collections wrong.
We are using these contacts as external forces, when updating the contacts in collections.
While in this example, the third contact we just lost is important for the update...

It requires another approach for the pruning. Like doing the actual pruning by looping in the collection bodies?

Dropping the count to 10 from 50 didn't work. What's going on? I know there was a monotonic portion to the criteria, which might be something we would also want control over (i.e., include or not). Likewise, we might also consider a merge when all contacts in a body pair have had stable contacts with forces within the friction cone over a given time period.

mobile.png and simple7.png show examples where a stack of a few blocks lands on a springy platform. The platform bobs up and down, and perhaps it does achieve near weightlessness at the top of the trajectory, but the springs drawn suggest that the bottom block has never stopped receiving an upward force. Is the behavior correct? Might be based on the symplectic integration and the starting state given no global viscous damping! Worth a closer look.

Move the diagonal entry computation Dii and Aii in Erleben's paper, called JMinvJt in the code, along with b, outside the iteration loop as they are constant. They should be stored in the contact rather than making an array.

Not a big issue, but I have been thinking about how the warm start check that blocks and bodies match for a contact in the last time step with one identified in this time step involves building a string and a string compare, as opposed to checking the object IDs.

Another thought is that with the BodyContact objects (can this name be refactored / improved) storing information on the contacts between two rigid bodies, it can be a faster map lookup to check only those for the same pair of contacting bodies... Perhaps a silly optimization given that hashmaps and treemaps are so fast. And there are much bigger fish to fry.

Instead of storing lambdas in a vector, allocating these vectors, and keeping contact indices, can we just let these values live inside the contacts? Not a bug, but certainly something that will help prevent bugs!

Mouse springs provide gentle interaction for manipulating simulations, but it might be interesting to test impulses (much like momentary collisions) to see how it influences the unmerging rules.

currently, this example will merge after a long time.. about 200 seconds? Was it just luck? should it really have merged? That said, might be nice to expose some very gentle viscous damping parameters to slow everything down by a small factor (e.g., 0.999 of current linear and rotational speed, or 0.99, or something smaller)

I'm having a hard time understanding the effect of the compliance and stiffness feedback on the internal contacts resolution. Everything works very well if we set the parameters to zero. Maybe it's a bug, but if so I cannot find it...

I think we shouldn't apply the velocities of the collection to the body after unmerging, otherwise
we will miss the response of an impact.
It can easily be seen with the new feature "mouse impulse" (shift + left click).

I think we should come with a strategy for that because, we need this feature to correctly solve
collision/impact, yet it can lead to unstable configuration if we apply these cheap results
all the time?
What about applying these cheap results only if the relative velocity is twice (or something else) the threshold? or if we notice big and fast change?

There are a number of keys in the keyboard interface, and likewise, if the mouse interaction starts to have shift/alt/control or whatever for doing different things for mouse interaction, then we should have a simple help jTextPanel to list what's what... I can drop in some code for this.

Important to understand what's going on with the delta v unmege test. Are we correct to compare the single cycle PGS velocity updates with the current merged collection velocity, or should it be the velocity at the next time step.

Can we remove this? It is unused, but perhaps could be useful for something? Not sure... would prefer to delete! :)