Alexandre Sirois-Vigneux

AlexandreSV

About Me

Alexandre Sirois-Vigneux is a Senior 3D Software Developer at SideFX with a passion for the intersection of computer graphics, machine learning, and visual effects. With an M.Sc. in Computer Graphics and Machine Learning from McGill University and Mila, he has developed a strong foundation in physic...  more
専門知識
Developer
業界:
Film/TV

Connect

LOCATION
Sherbrooke, Quebec, Canada

Houdini Engine

ADVANCED
Digital Assets  | Pyro FX  | Fluids  | VEX
INTERMEDIATE
Karma  | Lighting  | 説明  | Python

Availability

I am currently employed at SideFX

My Badges

SideFX Staff
Since 6月 2023

チュートリアル

obj-image Masterclass
MPM | H20.5 Masterclass

My Talks

obj-image HIVE
Mastering the Elements: The New MPM Solver

Recent Forum Posts

How to set surface tension in MPM? What's stiffness? 2024年8月30日15:59

kodra
Thank for your answer. I suppose it makes sense... but I still don't know how to control the surface tension. I know honey doesn't have a very high value of surface tension in real life. I just wonder if it's a controllable parameter in MPM.

Surface tension is currently not implemented in MPM, but it is being looked at.

Why does MPM source need a container? 2024年8月30日15:56

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

MPM constrains and stickiness 2024年8月30日15:19

MPM,like FLIP, works with a background grid that is not visible to the user by default. All materials are transferred to this background grid, so the contact between these two materials is going to behave like a blend between metal and concrete which is expected to be very sticky.

Reducing the particle separation on the mpmcontainer can help to reduce this effect. You can also reduce the gridscale from 2 to 1, to scale down the transfer stencil.

Another hack could be to do a first sim with both material simulated, then resim with one of the material as a deforming collider so you have full control over stickiness levels.

I talk about this issue/feature at 3:00:16 in the MPM Masterclass [www.sidefx.com].