0.1.0.44572
Windows 7 (64 bit)
Max 2010 x64
VRay and Scanline
I’m trying to Xmesh a Mesher compound object referencing a ParticleFlow system.
It works as expected, but I get motion blur pops on the particles as they are born.
But ONLY on particles that are being born and only on their birth frames.
After the particles are born, they motion blur fine, even collision-spawned particles.
I’m attaching an MOV file that demonstrates this.
(Particles are being born for the first 25 frames.)
We are working on a solution (direct baking of PFlow, direct Velocity acquisition from PFlow channels like we do with TP).
What I THINK is happening is this:
XMesh calculates Velocity in the general case (except for TP for now) like this:
*It takes the mesh at the current time
*It takes another mesh sample 1/4 frame later.
*If the two have the same face and vertex count, it assumes that the topology is consistent and calculates the velocity
*If the topologies are different, it tries another sample 1/2 way between the previous two (reduces the step to 1/8). This repeats until the step gets shorter than 1 tick.
It looks like XMesh is finding matching vertex and face counts, but since the particles might be moving around the events, the two meshes have some particles moved around the containers, which causes XMesh to track a particle to a completely different particle (because the order of the vertex and face lists of the particles have been shifted around). So if you had particles with the SAME shape and IDs 1,2,3 on the base frame, and on the next frame they are suddenly ordered as 1,3,2, the topology will be correct but you will get extreme motion blur from IDs 2 and 3 because they go to the wrong counterpart in the second sample!
As mentioned, the solution to this for PFlow is to stop taking two or more mesh samples and simply assign the velocities of each particle to its vertices like we do with TP. This will solve all current problems. Also, we are fixing the inability of XMesh to save a PF_Source (this is because XMesh expects the actual EVENTS to be passed to it, not the main system node). This means that in the future, you will even have the option to cache INDIVIDUAL Events to separate XMesh streams (if desired)!
Sorry about that, we are working as fast as we can to fix this!
Would it be possible for you to please send us your scene file, along with an .xmesh file that exhibits this problem? (Please note that we need the .xmesh and all .xmdat files for the frame). You can submit files to us either on these forums or through our ticket system.
Hey Bobo. Thanks for the detailed reply!
I THINK caching individual events would be helpful…trying to envision a situation in which I’d do that.
But having Xmesh open-ended enough to allow it is definitely better than the alternative.
Paul…I’m attaching the original max file and all the xmesh data.