Substance Batch Processor

Rendering one material at a time is fine for a test. When you've got a folder of thirty .sbs graphs to cook and render, or you want to see a material under a dozen different parameter sets, doing it node-by-node gets old fast. SubstanceBatchProcessor is the pack's automation layer: point it at a directory, pick a mode, and it fans out across files - or across variations of one file - with a thread pool doing the grunt work.

What it actually does

It's a wrapper that calls the same underlying tools as the Substance Cooker and Substance Renderer (sbscooker and sbsrender from Adobe's free Substance 3D Automation Toolkit), just in bulk. Given an input_directory and an operation_mode, it globs files matching file_pattern, then runs them through a ThreadPoolExecutor with max_workers parallel workers. There are three modes: cook_only (.sbs → .sbsar), render_only (expects .sbsar files already on disk), and cook_and_render (the full pipeline, the default). No API, no key - just a lot of subprocess calls.

The inputs that matter

• input_directory and output_base_directory - where files come from and where everything lands. Required.
• operation_mode - the mode above. Most people want cook_and_render.
• batch_parameters - the interesting one. It's a JSON array of parameter sets, and each set becomes a rendered variation of the material. Three objects in the array, three texture sets out. This is how you brute-force a search across roughness/metallic/tiling values.
• file_pattern - defaults to *.sbs, which makes sense for cooking; flip it to *.sbsar if you're in render_only mode.
• max_workers (1–8, default 2) - parallel worker count. More isn't automatically better; you're usually I/O- or memory-bound long before you're CPU-bound.
• output_format, bit_depth, optimization_level - the shared render/cook settings, same meaning as in the single-file nodes.
• organize_by_material - groups each material's outputs into its own subfolder, which you want on the moment the batch grows past one file.

The outputs

All four outputs are JSON strings, and they're the honest accounting you want from a batch job: processed_files lists what each file did, batch_summary gives the stats (how many succeeded, how many failed), error_log lists whatever broke, and output_structure maps the folder layout that resulted. There's no image output here - this node is for automation and reporting, not for previewing. Wire batch_summary or error_log into a text-display node to watch the run.

Installing and common issues

Same install as the rest of the pack: ComfyUI Manager (search "Substance Designer Integration"), or git clone https://github.com/jasonjgardner/comfui-substance-designer-integration into custom_nodes/ and restart. No meaningful Python deps - the real requirement is the Substance 3D Automation Toolkit installed with sbscooker/sbsrender on the PATH or in an auto-detected location.

Where people get burned: cranking max_workers because more sounds better - the README itself warns about I/O limits, and batch renders are memory hogs, so start at 2 and watch your system. Mixing file patterns and modes - leave *.sbs with cook_and_render, but remember render_only needs archives, not graphs. And failing fast: the batch continues on error by design (check error_log rather than assuming a clean run), so a typo'd parameter name in batch_parameters will silently produce failed entries instead of stopping the whole job. Read the log.

One framing note, same as the other nodes here: this is a young, AI-generated pack with basically no community footprint, and the "batch" is a straightforward thread-pool wrapper - nothing cleverer hiding behind it. But for its narrow job - cook and render a folder of materials, or a material across many parameter sets - it works, and it saves you from babysitting dozens of single-node runs.