I’m a bit confused why we need to have container plugged into mpm solver AND referenced in the MPM Container parameter of the mpm source? That kind of breaks the pattern of what we’re used to do, no? Not to mention that t would be great (and fairly basic UX design principle) if the order of inputs remained relatively consistent between solvers, e.g. container is always on the right, collisions are always second from the right etc. Not a big deal but one of those small, unnecessarily inconsistent items.

I'm not 100% sure if that's the main reason, but I believe MPM works best if all your sources have the same particle separation (size). That's why defining it once somewhere instead of on individual source is better. Making Source depends on Container makes this obvious.

the order of inputs remained relatively consistent between solvers

Not sure why MPM Solver's input order isn't the same as FLIP Solver SOP's...

Hi Luke,

Thanks for your feedback.

As kodra pointed out, the sources and colliders need to be aware of the global sim resolution to defined their own resolution in an optimal manner.

That being said, there are many different ways we could have gone to get this to work. For example with FLIP and other solvers you have a stream of wires going down from the first node setting up the scene all the way to the solver. Each node takes 3 wires and you basically append more things to the scene as you go down.

This is convenient because all new nodes have access to all previous nodes' data. The downside of this approach is that your node tree look like an history stack where sources could feed into colliders, which semantically does not reflect how the data is being used.

One could argue that a direct connection between two nodes should indicate that the incoming node is required to compute the current node. Having pass-through data that are sometimes used removes a lot of meaning from the node tree itself and forces you to dive inside each node to understand what is actually happening. I agree that it is a little odd to have the mpmcontainer indirectly fed into the mpmsource and mpmcollider, but a least with this UI/UX it is very easy to visually understand how the scene is constructed by looking at the 2D structure of the node tree.

I this case, we tried a different approach to see how it would be perceived by our users. If this is better we might move other solvers toward this UI/UX. Otherwise, we might migrate MPM to be more like the other solvers. The future is in your hands

Huge thanks for the response. I mean the fact that you took time to explain and engage is what makes SideFx such a kick ass company!

AlexandreSV
I this case, we tried a different approach to see how it would be perceived by our users. If this is better we might move other solvers toward this UI/UX. Otherwise, we might migrate MPM to be more like the other solvers.

Hopefully you keep the mpm layout as is and not try to adapt to a similar layout as other solvers.

Personaly I'm finding the mpm manner of organizing ideal - Of course changes/additions to UX/functionality are always welcome - but not just to mimic other solver environments.

I also prefer MPM approach compared to FLIP multi wire

Since Sources and Colliders are not technically part of the same data pair like geo and constraints in rbd or vellum so multiwire stack is more a nuissance in that case

FLIP arguably unnecessarily couples sources and colliders in a per substep basis making it very slow
I always end up sourcing FLIP colliders directly into the DOPnet to avoid this dependency especially with static and transforming colliders

So my hope is that FLIP will also inherit VDB Collider support for ease of use and optimizations in that workflow
It'd be also useful for Pyro as the current Packed colliders are tedious to set up confusing to manage and tricky to combine with other colliders