missing groups

Deprecated XMesh Maya Beta Bug Reports
1

We are exporting thinking particles data from max to maya using xmesh.

When bringing the object into maya, all groupId nodes and shadergroups are properly connected, however the group components are not defined in the mesh… so none of the materials are actually assigned to any faces.

Any ideas? I thought this was working, as we have used this before, but this is a changing topology cache, which might upset the system… We are rendering out of maya for this high priority show, and if we cant get xmesh to work, we will have to reshade these assets in max asap. (the show comes on air in about 3 weeks, so we dont have a lot of time to figure out a fix)

2

This is the way im testing for the component info:

import maya.api.OpenMaya as OpenMaya
selectionList=OpenMaya.MSelectionList()
selectionList.add('xmesh_Thinking001_1')
object=selectionList.getDependNode(0) 
depNodeFn=OpenMaya.MFnDependencyNode ( object );
attrib = depNodeFn.attribute( "outMesh" )
origOutMesh= OpenMaya.MPlug( object, attrib )
origOutMeshFn=OpenMaya.MFnGeometryData(origOutMesh.asMObject())
for i in range(origOutMeshFn.objectGroupCount):
    iID = origOutMeshFn.objectGroup(i)
    comp = origOutMeshFn.objectGroupComponent(iID)
    compFn = OpenMaya.MFnComponent(comp)
    print "%d id=%d count=%d" % (i, iID, compFn.elementCount)

The output i get:

0 id=6679 count=0
1 id=6680 count=0
2 id=6681 count=0
3 id=6682 count=0
4 id=6683 count=0
5 id=6684 count=0
6 id=6685 count=0
7 id=6686 count=0
8 id=6687 count=0
9 id=6688 count=0
10 id=6689 count=0
11 id=6690 count=0
12 id=6691 count=0
13 id=6692 count=0
14 id=6693 count=0
15 id=6694 count=0
16 id=6695 count=0
17 id=6696 count=0
18 id=6697 count=0
19 id=6698 count=0
20 id=6699 count=0
21 id=6700 count=0
22 id=6701 count=0
23 id=6702 count=0
24 id=6703 count=0
25 id=6704 count=0
26 id=6705 count=0
27 id=6706 count=0
28 id=6707 count=0
29 id=6708 count=0
30 id=6709 count=0
3

I think we found the issue. The matIDmap file that was generated on export does not have an entry for all the material IDs that the mesh is using. It only lists the IDs for what the multi sub material had, instead of the IDs that the topology has.

This is bad, because this means that the consistency of the topology export/import (the material ID metadata of the faces) depends on the shading of the object. Ideally, the matIDmap would have ‘default’ entries for any/all material IDs that don’t have a corresponding material for them. That way the component information is not lost when importing into maya.

4

The current export functions in max provide ways to clear and set the material ID mapping. Is there also a way to query the accumulated mapping information? That would allow us to write a matIDmap file with the appropriate number of IDs.

5

Sorry for my slow reply, I was away yesterday.

I assume you’re saving a single particle system?

The first thing that comes to mind is we could make a utility that reads an xmesh sequence, and writes a matIDmap file with a stand-in material for every material ID used in the sequence. We could make such a utility today. Would this work for you?

I’ll need to review what we’re doing currently. After that I’ll get back to you about our other options.

6

The current approach uses this function to identify what material ID mapping the xmesh would be using:

XMeshSaver_MaterialUtils.getMaterialFromNodes()

I think there are two problems:

  • The IDs carried by the xmesh data depend on the id mapping file. It shouldnt, the ID mapping file should just help in setting up the appropriate shading names for the independently maintained ID/component information of the topology
  • The getMaterialFromNodes function does not work reliably for TP materials. In our case, the TP material had a total of 59 nested IDs, but the function only returned 13. The code there is quite complicated so i didnt try to troubleshoot why its failing, but here is a code snippet that “flattens” a TP material:
						local theTPMaterial = theTPToSave.material
						local iMatCount = 0
						if (theTPMaterial != undefined) do
							iMatCount = (getNumSubMtls theTPMaterial)
						local theMaterial = MultiMaterial numsubs:iMatCount
						local matIDList = #()
						for m = 1 to iMatCount do
						(
							setsubmtl theMaterial m (getsubmtl theTPMaterial m)
							append matIDList m
						)
						XMeshSaverUtils.ClearAllMaterialIDMapping()
						XMeshSaverUtils.SetMaterialIDMapping theTPToSave matIDList matIDList
7

Unfortunately I don’t think we’ll be able to change this in the time frame that you require. However I am interested in improving our material handling, so perhaps we could discuss this after we’ve solved your immediate problem?

No, currently the XMesh Saver does not accumulate mapping information. You could do this yourself in script (disable the XMesh Saver’s material ID mapping; for each frame, examine the mesh, and keep track of the material IDs that it uses), or we could make a utility that does this for an existing xmesh sequence (see the end of this post).

Would it be possible for you to please send us a scene file that includes such a material?

I assume you’re saving a single particle system?

I believe this is the easiest workaround: we could make a utility that reads an xmesh sequence, and writes a matIDmap file with a stand-in material for every material ID used in the sequence. Would this work for you?

8

I solved our immediate problem by making sure the material has the same number of sub materials as the mesh has material IDs, so the emergency has passed!

Sorry, i meant accumulated material ID information. That is being collected if im not mistaken, otherwise it would not be able to cache it out.
Also, this seems to be a maya import only problem, as i can import the ‘bad’ data back into max and all the material IDs are present. They only go missing if i import the mesh into maya, and the matID file did not have the right number of IDs listed.

Yes and yes. You will need TP5 for the material most likely.

Since i already fixed our particular issue, no worries about finding a workaround, we could just focus on a long term solution