Evan Robinson

update: I never figured out what caused the particles to explode, but I "fixed" it by creating my own pop speed limit in a pop wrangle. Although it didn't solve the underlying issue, it killed the momentum before it became an issue, so the sim is now fine.

Hello.
I have this scene of tentacles waving around in the mud. Trying to figure out how to prevent areas of the sim that suddenly explode with insane velocities. What typically can cause that in mpm? I don't have this issue when doing lower res sims. I get the sim to how I like it with lower resolution. Then when I do a high res sim random parts of the sim start exploding near collisions.

Here are the steps that I have taken so far.

1. check collisions. Made sure the collisions are setup properly and that fractional frames interpolate properly.
2. Made the material less stiff.
3. Tried to limit maximum speed of particles. Pop speed limit didn't work at all. Tried a pop wrangle. Limited success, but doesn't solve underlying issue.
4. Increased substeps. Tried increasing min substeps and tried higher global substeps, tried lowering CFL condition to force higher min substeps.
5. Made sure affine velocity clamping is on

The last idea I have is to try changing my animated (deforming) colliders to animated (rigid) colliders. Break up the tentacles using voronoi fracture into smaller pieces to allow for animated (rigid) to work. the docs mention that animated (rigid) is the more efficient of the two and higher accurate.

Any other ideas?

edit: Maybe the explosiveness comes from the tentacles pushing the particles into the ground collider underneath it?

esttri
You need to give all the nodes you do not want to modify a tag called REFERENCE in the graph SOP. You can even delete them and it would still work. That way only you modifications get merged in and the upstream updates of your input graph properly show up..it also make the fuse step a loooot faster if you do that.

In other words we really only care on the edit graph SOP about the stuff you want to merge in not the rest. The rest is completely ignored, so it's not important if it's up do date or not of if you delete because it's not going to be used for the fuse process. And only the fuse process on the auto rig component node is the step that then takes the updated rig into account so you need to look there, not at the edit grap for the procedural update behavior!

Thanks, I really appreciate the replies. What you are saying makes perfect sense (and I previously didn't know that), but I feel like it does not address the original issue I was talking about. I will try to rephrase it.

1. Using component script (apex graph into second input of auto rig component) isn't an ideal way to work for every scenario (like fast prototyping or working on a small rig). If I need to multiply three vectors and wire the product into the rot of a transform object, it becomes the tedious task of graph add node, graph add node, graph add node, graph add node, find port, find port, find port, connect input, connect input, etc.

2. Apex graph allows me to directly edit the graph so I can work quickly. But this comes with the cost of stashing the graph. Example, I connect a vector into the rot of my two transform objects (that are my two joints). I decide to add a third joint and want to connect that vector into the rot like the other two. That third joint won't show in the apex graph sop because the initial graph that is stashed only had 2 joints. I can reset to fetch the new joint, but then I lose my work.

My question was whether or not there was a way to directly edit the graph like using the apex graph sop, but still be able to fetch changes to my original rig (like adding a joint).

What I have gathered is there isn't a way to do this. I should either use the component script method, or use the fuse graph method like you suggested (only care about stuff that is being merged).

Is that assessment correct?

Thanks

Sadly I don't think there is any way to do this currently. Looks like it's either on or off. Even though some pop nodes work with mpm, the mpm solver isn't based on the pop solver so not every pop node/attribute works. I was messing around with the targetv/airresist attributes to see if it works with mpm. That is usually my go-to for getting pop particles to appear partially pinned. targetv/airresist did effect the mpm simulation, but it didn't seem to work properly.