Nodes/ComfyUI-Texturaizer/Cached ControlNet (Texturaizer)
ComfyUI Node

Cached ControlNet (Texturaizer)

Load a ControlNet once, reuse it across repeated renders

By LatentSpaceDirective·Created 2 years ago·Updated 8 months ago· 21
Cached ControlNet (Texturaizer)
    • CONTROL_NET
    control_net_name

    Same idea as the pack's Cached Checkpoint loader, applied to ControlNets instead: load the file, hand back a CONTROL_NET object, and keep it resident so a repeated request for the same ControlNet doesn't re-read the file from disk. In a workflow that's firing render after render with the same ControlNet stack held constant - the normal case when you're iterating from Blender rather than hand-queuing single prompts - that saves real time, especially since ControlNet files aren't small.

    How it works

    It's functionally identical to ComfyUI's stock Load ControlNet Model node: pick a filename, get back a loaded ControlNet you can apply to your conditioning. The "cached" part is about what happens on the next call - if the requested ControlNet name matches what's already loaded in memory, it skips the disk read entirely rather than deserializing the file again. This is the loader you'd pair with Texturaizer_ApplyControlNets or Texturaizer_ExtractCNData when you're assembling ControlNets by hand rather than letting Texturaizer_ApplyControlNets handle everything from cn_data internally.

    The inputs and outputs that matter

    • control_net_name - the ControlNet filename, an enum populated from your ComfyUI/models/controlnet folder, same as any stock ControlNet loader.

    Output is a single CONTROL_NET, which wires into a ControlNet Apply node (or wherever your workflow applies conditioning against spatial structure) exactly like output from any other ControlNet loader.

    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 with the pack - this loads whatever ControlNet files you've already put in place, and the file itself still has to match your base model's architecture. A ControlNet trained for SDXL doesn't load on Flux and vice versa; every 2025-26 base needs its own ControlNet trained from scratch, so double-check you've got the union or per-architecture model that actually matches whatever checkpoint Blender is pointing at.

    Where people get burned

    The architecture mismatch above is the single most common ControlNet failure across the whole ecosystem, not something specific to this node - but it's worth restating here because Texturaizer's whole design is Blender picking the checkpoint and the ControlNet independently, and nothing in this pipeline validates that the two actually match before you hit generate. If a render comes back with the ControlNet seemingly ignored, check that the file control_net_name resolves to was actually trained for the base model you're running, not just that the filename looks plausible. And as with the Cached Checkpoint loader, the caching benefit itself mostly evaporates on a serverless setup like comfy.icu where each run starts a fresh container with nothing warm in memory - there, this node behaves close to a plain ControlNet loader.

    CategoryTexturaizer

    Inputs (1)

    NameTypeDefaultDescription
    control_net_nameCOMBO0 options:

    Outputs (1)

    NameTypeDescription
    CONTROL_NETCONTROL_NET