license requests

Deprecated XMesh Maya Beta Bug Reports
1

Hi there,

It seems like the maya saver keeps pinging the license server for every export call. Our export process does individual exports for each object, because we need them organized a certain way (every object in their own folder, the filename is very explicit per object, each object might have a different worldspace/local space parameter, sampling, plus we handle some material metadata per object as well).

The problem is that it seems that every single call checks the license server, adding an overhead to the export process. We have assets with 20-23.000 objects, which means 23.000 license checkouts/returns (or so it seems). Is there a way that a license grabbed could be held for a couple of seconds, and each new export command would extend that time?

Also, if we could encapsulate single samples into a single file, that would cut down on the files we generate massively.

cheers,
laszlo

2

Yes, that’s definitely possible.

Do you know which function you are using to export? For example, saveXMesh or saveXMeshSequence?

Could we change the export function so that you don’t need to make so many calls instead? For example, in older builds, we had to call saveXMeshSequence once for each output sequence. We changed it so that the path and object lists are now array parameters, so it can save multiple sequences in one pass. We could make the world/object space flag and time step parameters into arrays too.

Would you want a single file to hold all data for an entire frame sequence? Or just the data for a single frame?

If it’s just the data for a single frame: currently we de-duplicate data between frames. For example, for a mesh sequence with consistent topology, we write the face data just once, and reference that same face data in every frame. Would you want the same de-duplication, so one frame file will reference data in another frame file? Or should each frame file be self-contained, with no reference to other files?

3

We are using saveXMeshSequence, with different pathnames / object sets. The rest of the parameters tend to be uniformly the same in most cases.

Currently we are passing in just the string for the filename, and it seems to be working on the current selection. How would we need to tweak it to pass in an object set / filename list?

As for the encapsulation, my preference would be 1 sample = 1 file. So every frame would be a single file, also keeping the de-duplication. So say, frame 1 would have the face / topology data, frame 2+ could reference frame 1’s sample for those channels.

4

Here is the saveXMeshSequence synopsis for reference:Synopsis: saveXMeshSequence [flags] Flags: -cm -channelMap String -fr -frameRange Float Float -mm -materialIDMap String (multi-use) -o -objects String (multi-use) -p -path String (multi-use) -s -step Float -vis -visibleOnly -ws -worldSpace

saveXMeshSequence has a required -path(-p) flag. This flags controls the output XMesh file path. This flag is multi-use: you can use it multiple times to save more than one XMesh sequence.

saveXMeshSequence takes an optional -objects(-o) flag. -objects is a multi-use string flag. -objects must be used either the same number of times as -path, or not used at all. Each -objects use is a comma-separated string containing object names (e.g., “pCube1,pSphere1”). If you do not use this flag, then it will save your current selection.

If you use -path and -objects more than once, then each use of -objects is saved to the corresponding use of -path. The first -objects list is saved to the first -path, etc.

Similar to -objects, -materialIDMap(-mm) must either be used the same number of times as path, or not at all.

For example, say I have a sphere (pSphere1), a cube (pCube1) and a plane (pPlane1). I want to save the cube and sphere to one sequence (“c:/temp/cube_and_sphere_.xmesh”), and the plane to another sequence (“c:/temp/plane_.xmesh”).

In MEL: saveXMeshSequence -p "c:/temp/cube_and_sphere_.xmesh" -o "pCube1,pSphere1" -p "c:/temp/plane_.xmesh" -o "pPlane1";
In Python: maya.cmds.saveXMeshSequence(p=["c:/temp/cube_and_sphere_.xmesh","c:/temp/plane_.xmesh"], o=["pCube1,pSphere1","pPlane1"])

Alright, thank you for your feedback!

5

I have tried the multiple objects at once export, but maya crashed to desktop. Is there any debug logging i could look at?

6

I should say, the crash to desktop happened with a production file. I also did a simple teapot test which worked fine.

7

Unfortunately, I don’t think there is any debugging information that will help you currently.

That being said, you can enable debug logging by using the xmeshLogging command. Log messages appear in Maya’s “Output Window”.

MEL: xmeshLogging -loggingLevel 5; Python: maya.cmds.xmeshLogging(loggingLevel=5)

I’d be happy to debug the crash, if you could send us a scene file that reproduces the problem. You can send us files using our ticket system.

8

Hm… nothing is logged, just crash :-\

Seems like a stack overflow

First-chance exception at 0x76da303a in maya.exe: 0xC00000FD: Stack overflow.
Unhandled exception at 0x76da303a in maya.exe: 0xC00000FD: Stack overflow.

Too long arrays? Im exporting a couple hundred objects, each with a unique pathname

9

Are you using MEL or Python?

I ran the following Python script, which saves 2000 sequences, without error:[code]shapes = []
paths = []

for i in range(2000):
result = maya.cmds.polySphere()
shapes.append( result[0] )
paths.append( ‘c:/temp/test/test’ + str(i) + ‘_0000.xmesh’ )

maya.cmds.saveXMeshSequence(p=paths, o=shapes)[/code]Would you happen to notice anything different in your setup that might cause this problem?

10

I had something like this:

            vPaths = []
            vMaterialIDMap = []
            vObjsToExport = []
            
            for iIndex,sObject in enumerate(sObjects):
                sFileName = '%s/%s/%s_.xmesh' %(sDir, str(sObject.split(':')[-1]), str(sObject.split(':')[-1]))
                vPaths.append(vPaths)
                vObjsToExport.append(sObject)
                vMaterialIDMap.append(sShadingGroupAssingment)
                
            sChannelMask = 'Velocity,MaterialID,SmoothingGroup,TextureCoord,Mapping2,Mapping3,Mapping4,Mapping5,Mapping6,Mapping7,Mapping8,Mapping9,Mapping10,Mapping11,Mapping12,Mapping13,Mapping14,Mapping15,Mapping16,Mapping17,Mapping18,Mapping19,Mapping20,Mapping21,Mapping22,Mapping23,Mapping24,Mapping25,Mapping26,Mapping27,Mapping28,Mapping29,Mapping30,Mapping31,Mapping32,Mapping33,Mapping34,Mapping35,Mapping36,Mapping37,Mapping38,Mapping39,Mapping40,Mapping41,Mapping42,Mapping43,Mapping44,Mapping45,Mapping46,Mapping47,Mapping48,Mapping49,Mapping50,Mapping51,Mapping52,Mapping53,Mapping54,Mapping55,Mapping56,Mapping57,Mapping58,Mapping59,Mapping60,Mapping61,Mapping62,Mapping63,Mapping64,Mapping65,Mapping66,Mapping67,Mapping68,Mapping69,Mapping70,Mapping71,Mapping72,Mapping73,Mapping74,Mapping75,Mapping76,Mapping77,Mapping78,Mapping79,Mapping80,Mapping81,Mapping82,Mapping83,Mapping84,Mapping85,Mapping86,Mapping87,Mapping88,Mapping89,Mapping90,Mapping91,Mapping92,Mapping93,Mapping94,Mapping95,Mapping96,Mapping97,Mapping98,Mapping99'
            cmds.saveXMeshSequence(
                        worldSpace=bExportWorldSpace,
                        frameRange=(iStart, iEnd),
                        step=lSamples,
                        channelMap=sChannelMask,
                        path=vPaths,
                        materialIDMap=vMaterialIDMap,
                        objects=vObjsToExport
                        )

on average, the output path is about 100-150 characters long

11

Thank you! I have reproduced the problem.

I believe this line:

vPaths.append(vPaths)
[/code]Should be replaced with something like:[code]
vPaths.append(sFileName)
12

Oh. LOL.
erm.

walks away silently

Sidenote: could it warn of the bad parameter? Ill fix this asap hehe

13

Yes, it looks like we get access to the data before the crash, so I think this should be possible. I’ll add this to our todo list.