Nodes/ComfyUI-Texturaizer/Apply ControlNets (Texturaizer)
ComfyUI Node

Apply ControlNets (Texturaizer)

Fire every ControlNet Blender configured, in one node

By LatentSpaceDirective·Created 2 years ago·Updated 8 months ago· 21
Apply ControlNets (Texturaizer)
  • cn_data
  • positive
  • negative
  • vae
  • positive
  • negative

A normal ComfyUI workflow wires one ControlNet Apply node per ControlNet. Stack three ControlNets - say a depth pass, a canny pass, and a pose map - and you've got three of those nodes chained in a row, each with its own strength and start/end step fields. Texturaizer's answer is to collapse the whole stack into one node: hand it the ControlNet data Blender exported and it applies however many ControlNets are in there, in one shot.

How it works - and why it exists

Texturaizer's Blender side lets you configure ControlNets per render (the README calls out "Advanced AI Compatibility: Full support for LoRA models, ControlNet, and style/image prompts" as one of the pack's headline features), and that configuration - which conditioning types, which strength, which start/end step, which preprocessed image - gets exported as a dictionary. Texturaizer_GetCNData reads that dictionary out of Blender's export, and Texturaizer_ExtractCNData can pull one entry out of it by index if you want to inspect or handle a single ControlNet manually. This node skips the manual step: it takes the whole ControlNet dictionary and applies every entry in it directly to your conditioning, internally doing the work that a chain of ControlNetApply nodes would otherwise do one at a time. It's the "just make it happen" node in a pack that otherwise hands you data piece by piece.

The inputs and outputs that matter

  • cn_data - the ControlNet dictionary, typically wired straight from Texturaizer_GetCNData's controlnets output.
  • positive / negative - your existing conditioning, going in.
  • vae (optional) - some conditioning workflows need VAE access for the underlying ControlNet application; wire in your VAE if your setup calls for it.

Outputs are the modified positive and negative conditioning, ready to go straight into your KSampler. There's no strength or step-range input on this node itself - those live inside the cn_data dictionary per ControlNet, which is exactly why it's meant to be assembled upstream (by Blender, or by hand if you're building cn_data yourself) rather than tuned live on this node.

Installing it

ComfyUI Manager → search Texturaizer → Install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/LatentSpaceDirective/ComfyUI-Texturaizer

then restart ComfyUI. No models bundled - every ControlNet checkpoint referenced inside cn_data still needs to be a real file in your controlnet folder, loaded via Texturaizer_CachedCNLoader or a standard ControlNet loader elsewhere in the chain.

Where people get burned

Because the strength and step controls live inside cn_data rather than on the node's face, debugging a bad ControlNet result here means going upstream - checking what Blender exported, or what Texturaizer_ExtractCNData reports for the entry you suspect, rather than fiddling with sliders on this node. And the general ControlNet caution still applies underneath all of it: pushing every ControlNet's strength high and holding it through the full sample tends to fight the prompt for control of the image, exactly like it does with a manually wired stack - the standing community advice is to release a condition once composition has formed rather than holding it through every step, and that's still your call to make in however you (or Blender) populate cn_data, this node just executes what it's handed.

CategoryTexturaizer

Inputs (4)

NameTypeDefaultDescription
cn_dataDICTIONARY
positiveCONDITIONING
negativeCONDITIONING
vaeoptVAE

Outputs (2)

NameTypeDescription
positiveCONDITIONING
negativeCONDITIONING