AWS Thinkbox Discussion Forums

XMesh Mx to My Problems

Hi

Having some really annoying issues with XMesh for Maya. Caching out Particle Flow from 3dsmax and loading it into Maya I’m getting these errors:

// Warning: Mesh “xmesh_DOESNT_WORKShape1” has changing number of vertices (1464 expected, 1472 actual). //

This is causing the velocity information to not render with Vray for Maya.

After some detective work, I’m finding the same cache works in 3dsmax Loader and Vray. Also it seems to only be an issue with the Flows that I’ve created in this project, and strangely not all of them. Its seems like something has got corrupted. If I create a brand new PFLOW and cache that, it works. There is definitely something wonky going on under the hood.
I’ve attached the dodgy 3dsmax scene 2014, and a Maya scene with loaders.

Any help is appreciated, as my deadline is looming.

Thanks

Tim
Test_Files.zip (3.73 MB)

I think you will need to change your motion blur settings in V-Ray. In Maya, please do the following:

  1. Open the Render Settings dialog. (Window menu -> Rendering Editors -> Render Settings.)
  2. Switch to the VRay tab.
  3. Open the Camera rollout.
  4. In the Motion Blur group:
    [list=1][*]Change Duration to 0.99 (or some other value < 1).
  5. Change Interval center to 0.
    [/*:m][/list:o]

Does this fix the problem for you?

Hi Paul, Thanks for the reply.

I’m not sure this will work, as we are using the Vray Physical camera and matching background plates for motion blur.
Also, your right, the error pops up after the Vray render is complete. Vray in 3dsmax doesn’t have the same issue though.

This is a general requirement of V-Ray and other renderers that need to sample the geometry at different times within the shutter interval - the topology may not change between the two samples. XMesh stores the topology on each frame together with a Velocity channel, and extrapolates the positions of vertices within the interval from -0.5 to 0.5 frames around the sample. So if the shutter interval is centered, you will get the same topology within 0.4999 of a frame before and after the sample, but beyond that, the next frame’s sample will kick in and produce an incompatible topology for V-Ray. This is true for both V-Ray in Max and Maya, but it is possible that your V-Ray settings in the two applications are slightly different, or the XMesh Loading Modes are not the same in the two applications. Do you have sub-frames saved? Are you loading Frames or Sub-Frames? Are you retiming?

3ds Max also offers a multi-pass motion blur effect which does not care about the changing topology, so XMesh can produce different topologies on each frame and generate a better looking effect. But in V-Ray, Maya and mental ray renderers, the topology simply may not change within the shutter interval.

We have covered these limitations in the following experiment: thinkboxsoftware.com/xmesh-my-motion-blur/

Thanks Bobo.
My explanation was a bit mixed up.
I realise changing point counts are problematic, but the sample scene that is producing errors is very simple.

Pflow with cubes. Nothing deleted, just a standard flow. I have removed all complicated bits of my project, and just replaced with a simple cube and speed op. So only one event.

Load this into Maya, and even with no motion blur, the Xmesh cache won’t produce a standard velocity pass with Vray.

In the same scene I created a brand new, virgin flow, and this works. Simple cubes, and produces a velocity pass.

So i’m thinking there is something in the PFlow that is causing this error? It’s likely not Xmesh fault.
// Warning: Mesh “xmesh_DOESNT_WORKShape1” has changing number of vertices (1464 expected, 1472 actual). //

But…when i render the dodgy cache in 3dsMax, it works. No motion blur activated, I see a velocity pass.

Here are some renders. Default vray settings, no motion blur.



I can’t speak to what the specific problem is here, but I thought I’d mention that the internal Max and Maya data structures for 3D geometry are different, and the way Maya handles things can sometimes cause problems that aren’t issues in Max. Loaded XMeshes get translated into the internal, native data structures for processing.

This problem is likely caused by a particle birth on the next frame after the one you’re rendering. I notice that the “broken” system has particles emitted in frames 901-1042, while the “works” system has particles emitted in frames 901-1000. Perhaps you are rendering a frame after this range, or you happen to be rendering a frame that has no particle births? (I would expect that the “broken” system would always work when rendering any frame after 1042.)

The Velocity pass has the same mesh topology requirements as motion blur. To fix the velocity pass, please try the steps I described above to fix motion blur.

If you enable Camera motion blur, then V-Ray will use your Camera motion blur settings to create the Velocity pass. If you do not enable Camera motion blur, then V-Ray will use default settings that can lead to the same “changing number of vertices” problem that you encountered with motion blur.

Yes, our 3ds Max plugin can work with V-Ray’s default settings, while our Maya plugin cannot. We may be able to fix this by using a Motion Vector Color Set in Maya. I’ll see if we can add that in our next release. But if you need a workaround now, please try changing the motion blur settings, as I described above.

ah ha! you are right! frames before 1000 don’t work on both of these. Ok, this makes more sense now! Thanks for all your help. Getting particle data out of 3dsmax in any usable way is very difficult. I’ll have to use the motion blur trick you described!

this doesn’t seem to work. tried lots of combinations, all result in the same ‘changing number of vertices’ error. if I’ve birthed everything before my start frame, it’s all fine. back to 3dsmax i think.

last resort…PFBaker in 3dsmax. Then cache these…

What version of Maya and V-Ray are you using? I’d be happy to take a look, if you’d like to send us a copy of your scene file with those changes applied.

(I should mention that I expect our alternative fix, based on motion vector color sets, should be available for you to test in a week or so.)

Edit: Our alternative fix is in XMesh MY 1.3.3. To use it, either:

  1. Re-create your XMesh Loader using our “load” shelf icon, or
  2. Select your existing loader’s mesh shape node, and change its Mesh Controls -> Motion Vector Color Set to velocityPV.
Privacy | Site terms | Cookie preferences