This isn’t a common error, at least not in recent memory. In the past, you may have seen this if you tried to open a scene that wasn’t in a valid project, but Softimage no longer has a problem with that. To reproduce this error, I had to delete the system folder while I had a scene open.
A customer recently reported that random machines on the farm were reporting this error. They have custom shaders installed in a workgroup, and the workgroup lives on a network drive that is accessible to all machines on the farm.
So, what is this SPDL registry thing?
It’s a file named spdl.xsiindex, and it’s a cached index of all the shader spdl files. Softimage creates/updates this SPDL registry at startup (so you can delete it to force the recreation of a new file).
You can find the file in %XSI_USERHOME%\Application. Actually, the file is named “spdl.MACHINE.xsiindex”. We had to add the machine name to the file name to prevent issues with concurrent access. However, I would think that if you ran multiple instances of xsibatch on the one machine, you might still have problems.
There’s also a MTL2UA0150CWY.xsishaderdefcache file to deal with the new-fangled, non-SPDL shaders.
I’ve never seen this one before: “Verifying the failed access to ‘tools.vbs’ took 155 seconds.”
155 seconds? It seemed like forever…
A customer reported that he couldn’t import or export dotXSI, and that he got this message in the history log:
# INFO : 4011 - Import/Export .xsi: The dotXSI.dll (NT) or libdotxsi.so (IRIX) is missing or the class is not registered.
From past experience I was pretty sure this was a PATH problem, but just in case I also suggested running runonce.bat to make sure everything was registered:
It turns out the problem was indeed the PATH environment variable: it was missing C:\Program Files\Common Files\Softimage.
To check the PATH, click Start and open the Control Panel. In the Control Panel window, type “environment” in the Search box, and then click Edit the system environment variables
Our first CrowdFX-related case in Product Support!
A customer reported that CrowdFX wasn’t working. When he opened a sample CrowdFX scene, he got all these “plug-in is not installed” errors [Hey, that’s the same error I blogged about yesteday, but this time it’s something different–Steve]
// ERROR : 2356 - This plug-in is not installed: CrowdFX_RigProxy
// ERROR : 2356 - This plug-in is not installed: CrowdFX_SkeletonsCloud
// ERROR : 2356 - This plug-in is not installed: CrowdFX_ActorProxy
// ERROR : 2356 - This plug-in is not installed: CrowdFX_ActorsProxies
// ERROR : 2356 - This plug-in is not installed: CrowdFX
OpenScene("C:\\Program Files\\Autodesk\\Softimage 2013\\Data\\XSI_SAMPLES\\Scenes\\ICE\\CrowdFX_Walk_Along_Paths.scn", null, null);
The real clue was an error logged at startup:
// ERROR : Traceback (most recent call last): // File "<Script Block 2>", line 55, in XSILoadPlugin // in_reg.RegisterMenu(C.siMenuTbICECrowdFXActorsID,"Actors_Menu",False,True) // File "C:\Python26\lib\site-packages\win32com\client\__init__.py", line 168, in __getattr__ // raise AttributeError, a // AttributeError: siMenuTbICECrowdFXActorsID // - [line 54 in C:\Program Files\Autodesk\Softimage 2013\Addons\CrowdFX\Application\Plugins\CrowdFX_Plugin.py]
First, this shows the customer is using the version of Python 2.6 installed on the system (not the version shipped with Softimage). More importantly, it shows that the CrowdFX constants, like siMenuTbICECrowdFXActorsID, are missing.
For Python, all the Softimage constants like siMenuTbICECrowdFXActorsID are cached in the Python install folder. For example, the Softimage constants are cached in the folder C:\Python26\Lib\site-packages\win32com\gen_py\269C4D8C-E32D-11D3-811D-00A0C9AC19A9x0x1x0\__init__.py
The solution in this case was to zap (delete) the gen_py folder, forcing Softimage to regenerate the generated type info cache.
Third-party renderers, like Arnold or Maxwell, don’t support rendermap so you’ll get this error if you try to do a rendermap. In a recent case, the customer told us that he figured out that “the Maxwell render add-on was causing a conflict. Any old models I made with the add-on installed were affected, but new models created without the add on will bake textures just fine.”
Sometimes customers ask questions like this about the error reports:
Is there a way we can subscribe to the CER reports? like if i enabled it could we get reports that mean something to us? or is it always going to be low-level debug info for developers only?
Well, the CER reports are mostly low-level details, like call and thread stacks, that are useful only to our developers. But sometimes these can provide an obvious clue (for example, Softimage is crashing while parsing an addon XML file). Other times they don’t tell a non-developer like me [or maybe you] much.
Call stack
Thread stack
CER reports are basically call stacks (like the one I sent before) and crash dump files (which are saved in the user folder after a crash). The reports do also include some info about the OS and the graphics card, which can be useful to the support agent.
Our internal CER tools do some grouping of crash reports based on the area of the code where the crash happened, which can be useful as an aggregate measure. You can read more about CER here.
If you want to view the CER files, you can do that before you send or cancel the report. Just click View Report Details. You can even grab the report files if you want: some are in your Softimage user folder, and others are in the %TEMP% folder (in a XSI_Temp subfolder that is removed when XSI.exe exits).
A customer reported that on some machines, he would get this error when he opened a certain scene:
// ERROR : 2356 – This plug-in is not installed: FaceConnections
This means that the scene contains some Face Robot properties, but the Face Robot workgroup is not loaded. This can happen, for example, if you enable Face Robot in a scene, then disable Face Robot and save the scene. This leaves some some Face Robot elements left in the scene.
Any time you load this scene into an instance of Softimage where Face Robot is disabled (eg Softimage is not connected to the Face Robot workgroup), you’ll get this error.
To fix this, use the scene explorer to find the Face model and delete the Face model. The Face model has a FaceConnections property, and when Face Robot is not enabled, you will get that error at startup.
I’ve been asked several times about “Licensed number of users already reached” errors that appear in the LMTOOLS debug log file for render farm nodes that are running xsibatch.
If you have more than one render node running xsibatch, it is normal to see “Licensed number of users already reached” in the logs.
There are five Batch licenses (for brevity, I’ll call them B1, B2, B3, B4, and B5 because the real license names are like 79000SFTIMASIB1_F).
Each machine will take one of these Batch license.
xsibatch always tries to check out B1 first, then B2, then B3, and so on.
For example:
The machine “example1” starts xsibatch, and checks out the “B1” license.
The second machine “example2” starts xsibatch and tries to check out “B1” but cannot, because the B1 license is already in use.
So “example2” tries to check out the “B2” license.
This is what we see in the LMTOOLS debug log file:
14:47:29 (adskflex) OUT: "79000SFTIMASIB1_F" render@example1 14:47:29 (adskflex) OUT: "85563SFTIMSIB1_2011_0F" render@example1 14:48:19 (adskflex) DENIED: "79000SFTIMASIB1_F" render@example2 (Licensed number of users already reached. (-4,342)) 14:48:19 (adskflex) DENIED: "85563SFTIMSIB1_2011_0F" render@example2 (Licensed number of users already reached. (-4,342)) 14:49:00 (adskflex) OUT: "79100SFTIMASIB2_F" render@example2 14:49:00 (adskflex) OUT: "85563SFTIMSIB2_2011_0F" render@example2
In “render@example1”, “render” is the name of the user, and “example1” is the name of the machine.
eX-SI 