XMesh Saver: v1.0.3.46594
XMesh Loader: v1.0.4.46595
3ds Max: 13.0 SP2
In recent days we did some tests with XMesh. We realized that XMesh shifts the Material IDs if not all of them are used. We try to keep at least material ID 1 empty for Thinking Particles.
Is there a way to avoid this? Did we miss an option?
I attached a 3ds Max project with a sample scene. Just unzip it to the C drive.
XMeshTest.zip (112 KB)
Yes, XMesh creates new Material ID assignments and packs the Material IDs when saving multiple objects to a single XMesh.
Imagine having two boxes, one with Material IDs 1 to 6 (by default) and another with the SAME Material IDs, but with a completely different Multi-Material assigned to them. If we would not redistribute the Material IDs on the second box, both boxes inside a single XMesh file would have the SAME Ids and thus could not have two different sets of 6 sub-materials.
In addition, Thinking Particles uses a nested hierarchy of Sub-Materials which requires a special TPMultiMaterial to handle which only people with a TP installation would have available. To flatten out a TPMultiMaterial to a regular 3ds Max MultiMaterial, we had to reprocess the IDs to produce the same look.
In your scene, the resulting XMesh has the correct material assignments on the cached boxes, but different Material IDs in the mesh.
Since XMesh was designed to cache the render state mesh and ensure that what you had will render the same, it does the job as designed. Also note that XMesh does the remapping based on the actual materials assigned to the faces, not on the face IDs. So if a box has the same sub-material assigned to all 6 sides, it will use up only one materialID and not 6.
One of the main reasons for this is actually Thinking Particles. When we used XMesh to cache the bridge on Final Destination 5, TP generated a lot of sub-materials with MatIDs in unsupported (by 3ds Max) ranges, like values over 10,000 or more. 3ds Max supports only 1,000 sub-materials in the current version. This was mostly caused by Volume Breaker in my experience. But once we remapped the actually used materials to their corresponding faces, we were left with a nicely compressed small 3ds Max MultiMaterial with no duplication and only very few actual sub-materials.
Thank you for your report!
You can do this indirectly by turning off “Save Material Library” in the XMesh Saver, but then you’d need to handle material IDs and create a multimaterial yourself.
How would you like it to behave ideally?
I just tested it and disabling the “Save Material Library” and then assigning the original MultiMaterial from the test scene to the XMesh manually produced the correct result, since no ID remapping was performed.
Unfortunately, we cannot guarantee that all objects being saved will have the same MultiMaterial assigned to them (like in your case), so we cannot produce a Material Library on output when no ID remapping is performed. We could special-case it so that if all selected objects have the same material, it would be saved and then reassigned to the XMesh Loader, but what should we do if that’s not the case?
Thanks for your quick response!
We will give the disabling of “Save Material Library” a try. It seems to be the solution we are looking for. We want to preserve the material IDs for splitting up the geometry and material for FX work.
It makes totally sense that XMesh shrinks down the Material ID and creates a compact MultiMaterial, but on our last project the materials became so big that it was hard to handle the scenes and assets. At the moment we are figuring out the best way of using XMesh in our pipeline with complex setups.
I will get back to you after some more tests.