I’m trying to use an animated XMesh object as the emitter source for pflow by using it in the Position Object operator. It seems that I am able to use the Xmesh as a particle emitter, but pflow doesn’t seem to be recognizing the Xmesh animation since all the particles stay in the spot that they are birthed. This is despite having Animated Shape and Lock On Emitter checked in the Position Object operator.
I’m sure it’s possible that this isn’t working due to a pflow error but I wanted to check here to make sure I’m not trying to do something that’s impossible.
This is surprising, and I was not able to reproduce it when I tried (with a simple setup).
Here is what I did:
Created a Teapot, animated its position over time, added a Bend modifier, and also animated the Bend Amount.
Baked the Teapot to XMesh sequence.
Created a default PFlow, replaced the Position Icon operator with a Position Object.
Picked the XMesh Loader as the Emitter Object.
Enabled both Lock On Emitter and Animated Shape
Changed the Birth operator to give birth to all particles on frame 0
Played back the animation
RESULT: The particles were born on frame 0, and stuck to the surface of the moving bending teapot as expected.
Variation:
I went back and animated the segment count of the Teapot to increase over time.
Resaved to the same XMesh sequence
RESULT: When the topology changes, the particles jump around the surface because all they recall is face index and barycentric coordinates. This is a known limitation of 3ds Max / PFlow.
I resaved again, this time reducing the segments over time.
RESULT: Some particles would find their faces have disappeared, and end up at the origin of the XMesh Loader as they have nowhere else to go.
This was all tested in 3ds Max 2018 with the latest XMesh MX v1.5.0.
Thanks for taking a look at this Bobo. As usual, soon after I post I think to myself: “I probably should’ve done more more testing before I posted…”
I attached a couple example files. One is a simple setup that works, another is a little more complex and doesn’t work. The example that doesn’t work is similar to the effect that I was trying to go for in the first place. The Xmesh paths will be broken, but you can resave the pflows to xmeshes on your workstation if you want to try this yourself.
1st example, simple: I have a geosphere animated along a spline. I save this animated sphere out to xmesh, relaod it and use it as a particle emitter. Pflow seems to be able to follow the sphere’s motion when emitting particles:
2nd example, more complex: I create a simple pflow where spheres are placed on an animated plane that moves down in the Z axis and has an animated noise on it’s surface. I save out the moving spheres to Xmesh and reload them back into the scene. When I try to use the resulting Xmesh spheres are particle emitters the particles don’t follow the animation of the spheres:
In this example I was trying another workaround method where I’m trying to find ways to get particles to emit other particles.
Ultimately I’m trying to create a scene showing neurotransmitter transmission across a synaptic cleft in a nerve impulse. There will be synaptic vesicles (spheres) releasing neurotransmitters (particles) and it would be ideal to control both of these animations with pflow. But, since one animation is dependent on the other I would need to control a pflow with another pflow, which I can’t, so I was trying to see if Xmesh might help here.
Turns out this is a limitation of the PFlow Position Object, Volume, with Lock On Emitter option. It only works if the animated object has animated transforms, shifting the volume through space (e.g. your successful test). However, if you animate the mesh relative to the object pivot, for example by adding an XForm modifier and keyframing the transforms of its gizmo, then the particles don’t “see” the animation and stay where the mesh was originally relatively to the pivot.
I believe that the PFlow developer did not have a reliable way of ensuring that particles would stick to a volume in the case of an animated mesh. So instead of trying to reproduce their placement on every frame (which would fail as there are no face IDs and barycentric coordinates to lock onto like with Surface mode), he decided to always use the object space mesh from the first frame, and just apply any world space transforms that might be animated on the source object.
So with both a mesh with an XForm modifier, and with a World Space XMesh, you get the distribution on the first frame, and no additional transforms after that.
There is no easy workaround, except maybe creating spheres with internal faces throughout their volumes, then using the Surface placement mode instead of Volume. This will give you particles distributed inside the spheres similar to the volume mode, and the second PFlow will follow those correctly.
Thanks for your help! I strongly suspected that this was due to a limitation in the pflow position object operator and so I probably should have tested this some more.
I tried a similar approach based on what you suggested. I switched the Position Object operator to use Surface and I used a negative Surface Offset value to essentially move the particles off the surface and into the volume. This time pflow recognized the Xmesh animation:
Thanks again for your help with this! I’m often run into random limitations with pflow and I’ll definitely keep your advice in mind as I work on this further.
