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
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 physically based animation, and machine learning.
Throughout his career, he has worked as a Senior FX TD and Tool Developer at multiple major studios, including Digital Domain, Method Studios, and Industrial Light and Magic. He has also spent time in research and development roles at Ubisoft La Forge and Nvidia's simulation group, where he contributed to the development of real-time fluid simulation prototypes and GPU-accelerated liquid solvers.
Alexandre is driven by a desire to empower visual artists and creators through technological advances. He brings a unique blend of technical expertise and artistic understanding to his work is always on the lookout for innovative solutions that can simplify complex problems.
When not coding, he enjoys photography and exploring the great outdoors. He is always happy to meet new passionate people who share similar interests. less
EXPERTISE
Developer
INDUSTRY
Film/TV
Houdini Skills
ADVANCED
Digital Assets | Pyro FX | Fluids | VEX
INTERMEDIATE
Karma | Lighting | Destruction FX | Python
Availability
I am currently employed at SideFX
My Badges
SideFX Staff
Since Jun 2023
Recent Forum Posts
How to set surface tension in MPM? What's stiffness? Aug. 30, 2024, 3:59 p.m.
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? Aug. 30, 2024, 3:56 p.m.
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
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 Aug. 30, 2024, 3:19 p.m.
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].
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].