Author Topic: Python API is only for sbs creation/modification, not rendering?  (Read 4730 times)

I've currently got my own python script to modify the XML in the .sbs files directly, it involves reading some information for batch processing and updating the filepath for bitmap assets. The Substance Automation Toolkit was new at the time I wrote that and the documentation was lacking due to my newness to Substance Designer.

Documentation looks like it's improved quite a bit, and it will be easier to migrate my code to using the Python API now, especially for the new features I want to add to the batch tool. From what I can see it's not suitable for rendering? Do I still use the batch tools like sbsrender for this? Do I still need to use sbscooker for creating the sbsar?

Support said that batch tools were no longer supported, but they seem to still be the same tools provided with Substance Automation Toolkit? Is there an intention to later provide API to these tools via the Pysbs API?

The Automation toolkit includes both the python API for editing SBS files and the command line tools for cooking, rendering and baking. In order to render out textures you need to use the batch tools.
There are samples in the package showing this (variations, texture_mat). The next release of the python API will include python functions to invoke the batch tools without building the command line yourself.

I think I came across those which used a separate Python file or something? Being new to Python and Substance at the time, they were not clear to me(smaller examples might have been easier to follow I guess), I can't recall what docs were like for that approach of using the batch tools. I believe I referenced it, some gist example and the output/generation from some GUI tool on Github that created the CLI command to learn/understand how to use sbscooker and sbsrender.The command line arg docs weren't clear enough for some areas I was having trouble, seemed to be a problem for others too when googling queries. Some example snippets would be helpful, though a proper Python API also helps as an alternative :)

Here is some examples:

--engine <arg>
    Switch to specific engine implementation. format of <arg> : <dynamic_library_filepath> or <engine_version_basename_substring> e.g.: ogl3, d3d10pc, ...

Doesn't indicate what default is, or what options are due to the eg/ellipsis. I believe default is CPU SSE2 or something(can't remember the string for it). I learned that you can find these listed in a combobox within Substance Designer UI or look for the library files to see where they are, an example of using the command would also have been useful. `<arg> : <dynamic_library_filepath_or_engine_string...> wasn't clear. ` --engine d3d10pc`, ogl3 doesn't appear to be supported on Windows, user must discover the available options instead of having a reference of what Allegorithmic offers per platform?

--set-value <arg>
    Set value to a numerical input parameter. Format of <arg> : <input_identifier>@<value>.

Similar with outputsize which is exposed by default, ` --set-value $outputsize@11,11` where 11 gives `width,height` and maps to a value of 2048px(default max on CPU rendering, as well as bitdepth limitations, took a while to figure that all out). I learned how to use this command thanks to the GUI tool via Github from memory. There was a similar option for setting size of nodes I think(input/output specifically?) but I didn't seem to have much luck getting that to work.

I was pleasantly surprised to find the .sbs file was XML when I tried to view it in an editor, I could make more sense out of the structure there than I could the docs at the time. It's great that the docs have been improving, the Pysbs API is really nice to use :)

Thanks for your feedback.

I agree that the command line options are not always great and sometimes too low level (your intent is typically to use the best available engine which happens to be different on different platforms etc.) . At some point not too far in the future I want to make command line documentation and error/warnings much better so you can catch the types of issues described.

For maximum resolution, the first thing to get right is making sure there are errors/warnings letting you know when things are going wrong rather than getting results inconsistent with your inputs. There is a big confusion around setting outputsize when the graph is not set to be relative to parent with scaling 1 as well.

Expect these things to get better and don't be shy if you run into more issues.