🆒 SuperPBR ORM Split

The ORM that falls out of SuperPBR Material is a packed texture - one RGB image carrying three different material properties. That's the efficient way to store it and the annoying way to use it, because Blender, Unity, Unreal, Substance and most baking tools each want a different arrangement of separate or differently-packed maps. 🆒 SuperPBR ORM Split is the twenty-line node that unpacks it.

The packing convention, because getting it backwards is the classic mistake

R is occlusion (AO). G is roughness. B is metallic. Not an arbitrary order - it's the channel layout the SuperMat model was trained to emit, which is why it doesn't have a "swap channels" switch.

The output side is dead simple: occlusion, roughness and metallic, three IMAGE outputs. Mechanically the node slices one channel and replicates it across RGB, so each output is a grayscale image you could equally have made with a Channel Split and a couple of merges. The reason to use this node instead is that it encodes the convention, so you can't get the order wrong and it keeps working when the pipeline changes underneath you.

It accepts the ORM straight from SuperPBR Material or the one that came back out of Tile Stitch - both are the same object type and the same channel order, so swapping between a small single-pass workflow and a tiled one doesn't require rewiring.

The one thing in here worth the read

The author's own tooltip on occlusion is the best sentence in the pack:

"Ambient occlusion (R channel). Blender renders its own AO at render time - use this for baking/export or subtle base-color darkening, not as a direct Principled input."

That's correct, and it's the mistake almost everyone makes on their first PBR material. The Principled BSDF has no AO input. People hunt for one, find the AO node, and wire it up expecting contact shadows. What actually happens is that occlusion is a lighting result your renderer already computes for free once real geometry and real light are in the scene, so feeding a baked map into the shader doubles the darkening in crevices and flattens the whole thing. Keep AO for the times you're handing a texture to an engine that wants baked AO, or for multiplying very lightly into base colour when you want a contact-shadow look that pure lighting won't give you - a decal, a scan, a flat card.

Roughness and metallic are the opposite: those go straight into the shader. Wire roughness into Roughness and metallic into Metallic and the relight is instantly believable, because those two maps are what make a surface behave like a surface instead of like coloured paper.

Practical notes

Save the grays as PNG, not JPEG. Roughness and metallic are data, not photographs, and JPEG's lossy compression and chroma handling will smear values you then have to live with inside a shader. And if you're pulling these into Blender, set the image colour space to Non-Color - the moment a roughness map gets treated as sRGB, your mid-grey 0.5 becomes something noticeably different in linear space.

The node does no remapping, no gamma correction and no inversion: it slices and expands. So don't route an output through a colour-correction node "to fix it" unless you can see what's wrong, and if you're saving a single-channel map to disk, remember ComfyUI's SaveImage writes a three-channel image with identical channels, which is exactly what every engine's grayscale slot wants anyway.

Install

ComfyUI Manager → search the pack title, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Hullabalo/ComfyUI-SuperPBR.git

Restart. No model files, no dependencies - this node is pure tensor slicing and will happily run on a CPU-only install with nothing else from the pack loaded. You only need the Material node's outputs if you want something to feed it.