Error on sbs.writeDoc

[wcrouch]

One of the sbs files that I am writing automation code for throws an error when I attempt to save it.  I have reduced my code to simply opening & saving the file and the error persists, implying something is wrong with the sbs file.

For example, running this:

Code: [Select]

sbsDoc = substance.SBSDocument(aContext, sbsfile)
sbsDoc.parseDoc()
sbsDoc.writeDoc()
Results in a 160+ line traceback error that loops through the same 4 modules in pysbs.  Below is the end of it.  ([toolsdir] does not appear in the traceback, that is my edit)

Code: [Select]

  File "[toolsdir]\python\3.7\Lib\site-packages\pysbs\sbscommon\values.py", line 625, in write
    aSBSWriter.writeSBSNode(aXmlNode, element, 'treelist')
  File "[toolsdir]\python\3.7\Lib\site-packages\pysbs\api_decorators.py", line 54, in wrapper
    return function(*args, **kwargs)
  File "[toolsdir]\python\3.7\Lib\site-packages\pysbs\sbswriter.py", line 90, in writeSBSNode
    aSBSObject.write(self, aNewNode)
  File "[toolsdir]\python\3.7\Lib\site-packages\pysbs\api_decorators.py", line 54, in wrapper
    return function(*args, **kwargs)
  File "[toolsdir]\python\3.7\Lib\site-packages\pysbs\sbscommon\values.py", line 569, in write
    for element in self.mElements:
TypeError: 'NoneType' object is not iterable

It's like the class SBSTreelist in values.py gets handed a bunch of empty data and cannot handle it.

As I mentioned I think something is wrong with the sbs, but I'm unsure what to look at.  What's stranger is that running the command line tools, such as sbsmutator, have no problem editing the file.  It's just pysbs that has an issue.  Any advice or wild guesses are appreciated!

[wcrouch]

Adding to this, it's clearly because of the linked meshes in the file.

Problem persists if I delete all graphs from the sbs and run the code.  If I instead delete all linked mesh resources, I can write out the doc.

I went through all of the meshes and deleted all of them, one by one, until I was able to write the doc out again.  Every one of the 29 linked meshes causes the problem, except one.  There is a single mesh that can stay in the file and then sbs.writeDoc() can complete.

It seems to be the first mesh that was imported, if that says anything useful.  There other 28 are all variations of the same geo that the graph will be used with.

[wcrouch]

While I still don't know what was happening, I did get rid of the problem.

I deleted all the meshes from the sbs file, and had my script import & group them all in addition to its other operations. No more issues.

Something about the mesh resources was sour, though I am not sure what.  I also noticed that the order of the hierarchy in the explorer changed.  The 'Resources' group used to be at the top of the explorer within the sbs, but now is at the bottom. 

My wild guess is that during writeDoc() the xml tree was trying to create a node with a dependency that did not yet exist.  Odd that it only was an issue within pysbs, while sbsmutator and substance designer itself had no problem with it.

[Colin.lob]

Hello!
Can you share with me which version do you use?
It looks like an old bug.

[Renan Wang]

I seem to have encountered the same problem, the version number is 11.1.2

[Colin.lob]

Are you able to share the .sbs or to give me precise repro steps?

[wcrouch]

We are using 11.1.2 also.

Reproducing is as simple as the three lines in my original post.  Make a doc object, parse it, write it.  Something about this file triggers the bug in pysbs, since this issue has not occurred anywhere else.  While I can't share the file itself I'll share my other observations:

There are 29 unique meshes linked in the file, all fbx.  What I noticed is that the error would occur if any of the meshes remained in the file, save one.  I deleted each mesh one by one, saved the sbs, and reran the simple parse -> write script until writeDoc() succeeded. There is a single mesh resource that can stay in the file and the error does not occur. If any other meshes exist writeDoc fails.  Removing any other textures or graphs has no effect on the outcome.

To be clear, it's not that only one mesh can be in the file, it's that one specific mesh can be in it.  If I leave one mesh and it's not this specific mesh, writeDoc fails again.  I can't find any notable between this item and the others within the substance UI or the fbx files.

But Looking at the XML, the 'good' mesh has an oddly named package associated with it:

Code: [Select]

"pkg:///Resources/goodmeshdir/goodmesh_geo_0x1F9D0D61980"
Followed by it's identifier & file paths.

None of the 'bad' meshes have 'pkg://' line associated with their names.  Just identifiers & filepaths.  I'm curious if that is relevant.

[Renan Wang]

If there is an FBX in the .sbs file, an error will be reported when the file is parseDoc and then writeDoc. For specific tests, you can create a blank .sbs file. Then load a mesh in the resources to parseDoc and writeDoc.