Have a bit of a strange one here. When caching out a particle simulation with xMesh, we were getting a different result from the actual ‘live’ pFlow.
It appears to be that on frame 0 the data operator in the flow is having its influence applied twice to the particle. On that first frame it gets a little extra ‘kick’ that offsets the rest of the simulation.
Toggling all the operators on and off have shown that the error is coming from just the data operator.
Changing the caching range of xMesh to start one frame earlier, to before the particles are born, yields a correct result. So it is my conclusion that xMesh is applying the data operators influence twice on the first frame of the simulation.
I have experienced similar problems with writing some maxscript, and the cause of the problem was the ‘Auto key default frame’ was set to ‘off’, so I checked that to see if it was any part of the problem, and it is enabled, if that information helps at all.
I have attached the file to help demonstrate the issue.
Is there a fix for this, and or is it a (known) bug?
A few things to try (as I don’t have Box #3 installed here at the moment):
*Set your renderer to Scanline and render an image of the first (or any other frame) using the PFlow itself.
*Render the same frame using the XMesh.
*Load both in RAM Player and compare A|B. Are they the same or offset?
I am asking because XMesh is requesting the mesh that a renderer would request, using exactly the same functions. XMesh is NOT running PFlow or its Operators, it is only asking PFlow to give it the render time mesh.
If the two images are indeed different, we will have to figure out whether XMesh is doing something a renderer isn’t, causing PFlow to update incorrectly.
Another thing to try - try saving to XMesh with the Proxy option turned on. This will keep Max in viewport mode (as opposed to “render” mode) and should save to disk EXACTLY what PFlow is showing in the viewports. If the Viewport Proxy does NOT match the PFlow after that, again it would point at a problem in XMesh. If the two are identical, then the problem is in PFlow/Box #3.
I made a simpler scene without a data operator to see if the problem still happens, and it does.
I started with a new scene and I created a default PhysX Flow and then Xmeshed it. The only thing I changed was I enabled the proxy mesh set to Optimize.
I attached the scene and the renders of both the pflow simulation and the xmesh. The offset is not as severe as it was in my previous scene, but it is still there. However, this time they did match in the viewport and the offset only appeared in the render. I also recreated the scene on 3 different computers and got the same result. xmesh.max (208 KB)
If you play a box#2 sim over and over it will keep giving slightly different results. This is a known issue with box2. Make sure you check “realtime” in your playback to ensure the most stable view. Or cache the sim.
