If you have a pflow that includes various events that particles are sent through, the resulting exported XMesh will not have a consistent vert/face order throughout the animation.
If the pflow does not have any events that particles are progressively sent through, the face/vert order will remain consistent throughout the entire sequence.
On the orbaz forum, Vlado was asked if pflow can order resulting meshes by particle birthID and not eventID, and he said it was not possible, so technically this is not an XMesh problem. However, on scriptspot there exists a handy script to bake particles to geo, which essentially caches particles to objects by grabbing a particle’s mesh, assigning it to an object, and then following each particle through all of the events it goes through and grabbing its transform at each frame and assigning it to the object as a keyframe.
Would be awesome if XMesh had a setting to cache particles that way as well (ie, instead of just grabbing the pflow computed geo, it manually goes through and caches transform and mesh data so that the resulting mesh’s vert/face order remains consistent over time).
The reason for this request is that inconsistent vert/face order causes many problems when using things like lock/bond operators, modifiers on top of the xmesh that support sub-object selections, etc.
Just a small correction, Vlado is the VRay developer, Oleg is the Orbaz guy. Both slavic and very smart , so an easy mistake.
Anyway, you are right that this is the way PFlow (and TP) works. We ask the particle system to give us the mesh it would pass to a renderer, and we run with it.
Your solution would only work if the particle count was consistent - no new particles were born and no old particles died. Each time a particle dies, its geometry would be removed and the following particles’ faces would still be renumbered.
The latest version of XMesh MX we posted two days ago supports the saving of particles baked as geometry objects. Typically, when you bake a PFlow to geometry objects with keyframed transforms, the birth and death are represented by visibility track keyframes. The v1.1.3 XMesh MX Saver gives you the ability to respect the visibility track and output an empty mesh where visibility is below 1 or equal/below 0. Of course, this would once again change the face order since faces would come and go as “particles” come and go, but moving a particle to a new event would not cause a reordering of all faces.
I will log your request on the XMesh wishlist, but I am not sure it would be very high on the priority list (since the above approach is a viable workaround).
