Substance Renderer
Where Your Materials Actually Become Textures
- input_image_1
- input_image_2
- input_image_3
- input_image_4
- texture_paths
- texture_images
- organized_outputs
- render_log
- output_directory
This is the node the pack is really about. If you've got a .sbsar material - one you cooked yourself, or a free archive pulled from Adobe's Substance 3D asset library - SubstanceRenderer is what turns it into an actual PBR texture set: diffuse/albedo, normal, roughness, metallic, height, AO, emission, and opacity maps sitting in a folder, ready for a game engine or a renderer. The other nodes in this pack are supporting cast; the Renderer is where the work gets done.
How it works
Like its sibling nodes, it doesn't contain any Substance engine. It shells out to sbsrender from Adobe's free Substance 3D Automation Toolkit and runs sbsrender render --input thing.sbsar --output-path ./textures --output-format png ..., passing every setting through as a CLI flag. Parameters become --set-value param@value entries, resolution becomes an $outputsize override, and any connected ComfyUI images get written to temp PNGs and handed in as --set-entry inputs. Predictable, no API key, and the logs you get back are the real CLI's own output.
The inputs that matter
sbsar_file_path- the.sbsarto render. Required.output_directory- where maps land. Required.output_format(png / tiff / exr / jpg / tga / hdr) andbit_depth(8 / 16 / 16f / 32f) - required, and worth setting deliberately. PNG at 8-bit is the sensible default; go 16-bit or EXR if a downstream tool needs the precision.resolution- output size in pixels, 256–4096, default 1024 (the tooltip calls it "width and height"). Double it only when you actually need to; render time and memory go up fast.parameters- a JSON object of parameter overrides. This is where you'd drop the output of the pack's Parameter Controller.return_images- whether to also load the textures back into ComfyUI as an IMAGE tensor. On by default.input_image_1throughinput_image_4with matchinginput_image_N_paramfields - the interesting feature. Wire any ComfyUI IMAGE output into a slot, name the Substance parameter it should drive (saydiffuse_input), and the renderer feeds your generated image into the material as an input texture. That's the hook for AI-generated content driving procedural materials.
The outputs
texture_paths- JSON list of every file that came out.organized_outputs- the same files grouped by map type (diffuse, normal, roughness, metallic, height, ambient_occlusion, emission, opacity) based on filename patterns. This is the output you actually want to read when you're wiring things up.texture_images- the maps as a ComfyUI IMAGE tensor. Two honest caveats here. First, it's one batch containing all maps stacked together, not separate per-map outputs - so if you wire it into a preview you'll see a strip of images, and you can't easily grab the normal map alone from it. Second, if loading fails the code quietly returns a dummy black tensor instead of erroring. If you're building on this node, treat the files andorganized_outputsas the source of truth, not the tensor.render_logandoutput_directory- the CLI output and the resolved output folder.
Installing and troubleshooting
Same story as the whole pack: install via ComfyUI Manager (search "Substance Designer Integration") or git clone https://github.com/jasonjgardner/comfui-substance-designer-integration into custom_nodes/, then restart. No real Python deps to worry about - the actual requirement is the Substance 3D Automation Toolkit installed and on your PATH (or in one of the auto-checked install dirs, or pointed to via config.json). The toolkit download needs an Adobe account but is free.
Common pain points: memory errors - drop memory_budget (default 2000 MB), lower the resolution, or render at 8-bit; parameter errors - your JSON is probably malformed or you guessed a parameter name wrong, so check it against what the Substance Info Extractor reports; black or missing images - remember the dummy-tensor fallback and check render_log plus the actual output folder rather than trusting the preview.
The pack is young, AI-generated code with a thin community footprint, so don't expect elaborate docs. But the core promise - turn a .sbsar into a real texture set inside a ComfyUI graph - is exactly what this node delivers, and the input_image slots are the genuinely fun part if you're trying to drive procedural materials with generated imagery.
Inputs (22)
| Name | Type | Default | Description |
|---|---|---|---|
| sbsar_file_path | STRING | — | |
| output_directory | STRING | ./textures | — |
| output_format | COMBO | png | 6 options: png, tiff, exr, jpg, tga, hdr |
| bit_depth | COMBO | 8 | 4 options: 8, 16, 16f, 32f |
| output_nameopt | STRING | — | |
| graph_selectionopt | STRING | — | |
| output_selectionopt | STRING | — | |
| parametersopt | STRING | {} | — |
| preset_nameopt | STRING | — | |
| cpu_countopt | INT | 00–32 | — |
| memory_budgetopt | INT | 2000512–16384 | — |
| resolutionopt | INT | 1024256–4096 | Output texture resolution (width and height) |
| return_imagesopt | BOOLEAN | true | — |
| verboseopt | BOOLEAN | false | — |
| input_image_1opt | IMAGE | First input image for material parameters | |
| input_image_1_paramopt | STRING | — | |
| input_image_2opt | IMAGE | Second input image for material parameters | |
| input_image_2_paramopt | STRING | — | |
| input_image_3opt | IMAGE | Third input image for material parameters | |
| input_image_3_paramopt | STRING | — | |
| input_image_4opt | IMAGE | Fourth input image for material parameters | |
| input_image_4_paramopt | STRING | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| texture_paths | STRING | — |
| texture_images | IMAGE | — |
| organized_outputs | STRING | — |
| render_log | STRING | — |
| output_directory | STRING | — |