Messages

1

Substance Automation Toolkit - Product Support - Re: Error on sbs.writeDoc

 on: June 29, 2021, 12:54:13 am 

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.

2

Substance Automation Toolkit - Product Support - Re: Error on sbs.writeDoc

 on: May 25, 2021, 09:14:13 pm 

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.

3

Substance Automation Toolkit - Product Support - Re: Error on sbs.writeDoc

 on: May 20, 2021, 03:05:53 am 

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.

4

Substance Automation Toolkit - Product Support - Error on sbs.writeDoc

 on: May 17, 2021, 09:14:39 pm 

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!

5

Substance Automation Toolkit - Discussions - Re: Applying Preset to a Sub-Graph

 on: March 31, 2021, 11:15:36 pm 

Thank you, this does work.

I tried it this way originally, but it did not seem to respect the preset.  This turned out to be a problem with some of the presets embedded in the sbs file.  Once the presets were corrected applyPreset worked as it should.

Diagnosed by running through the process manually- some presets were not applying data when they were selected in the sub-graph.

6

Substance Automation Toolkit - Discussions - Applying Preset to a Sub-Graph

 on: March 25, 2021, 06:22:45 pm 

Hello,

I am writing some SAT tools to generate textures automatically using template graphs.  Normally, when applying a preset file to a graph, I would use sbsmutator to apply the preset file to the sbs before rendering.

However this time I have to apply a preset to a node within the graph.  That node being an instance of another .sbs file.  This can be done through the Designer UI, by simply selecting the node and loading a preset from the 'instance parameters' menu.

The only solution I have right now is to use sbsmutator to edit the file the sub-graph is sourced from.  This is not ideal, as that file is an exclusive checkout in our version control. Meaning only one instance of the code could ever run at a time, since it requires possession of an exclusive file.

Do you have an example of applying a preset file to a sub-graph through SAT?