Get Json Data (Texturaizer)

If you're using the Blender side of Texturaizer, this is the node that opens the door. Blender's addon writes out a JSON blob describing whatever you're rendering - per-object prompts, material settings, LoRA and ControlNet configs, the lot - and Get Json Data is the one node in the pack that reads it whole. Every other "Get X Data" node here (models, LoRAs, ControlNets, IPAdapter, Kontext, material tiling, image passes) is really the same read, just filtered down to one field. Wire this once and feed its output into the rest, and you only touch the disk a single time per run instead of a dozen.

How it works

Point it at a directory (or leave it blank) and it goes looking for the JSON file Texturaizer's Blender addon dropped there, parses it, and hands the whole thing back as a dictionary - no interpretation, no filtering, just the raw payload. The data_optional input exists for the opposite direction: if you already have that dictionary from somewhere else in your graph, pass it in and the node skips the disk entirely and passes it straight through. This "read from disk, or take what you're handed" shape is the pattern every other Texturaizer getter uses, and it's why data_optional shows up on nearly every node in this pack - read once at the top of your graph, fan the same dictionary out to a dozen specialized extractor nodes, and none of them has to hit the filesystem again.

The inputs and outputs that matter

Both inputs are optional, which matters because it means the node still does something sensible with nothing wired in:

• directory_optional - a path string. Leave it empty and the node falls back to whatever Texturaizer's Blender preferences call the "global directory," wherever the addon is currently writing its export to.
• data_optional - a dictionary. Wire in an upstream json_data output here (or anything else shaped the same way) and the node uses that instead of touching disk.

The output is json_data - the whole dictionary - plus data_hash, which the author's own tooltip flags as purely for debugging: a fingerprint of what got loaded, handy for confirming a downstream node actually saw fresh data after you changed something in Blender. It's not meant to be wired anywhere.

Installing it

Same as the rest of the pack: ComfyUI Manager → search Texturaizer → Install, or by hand:

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

Restart ComfyUI either way. The README doesn't call out any extra Python dependencies or bundled model downloads for the node pack - it's glue code that expects your usual checkpoints, VAEs, LoRAs and ControlNets to already be sitting in your ComfyUI model folders.

Where people get burned

Be honest with yourself about what this node is for. It's built for the Blender workflow, not standalone use. Drop it into a bare ComfyUI graph - on comfy.icu, say, with no Blender addon anywhere near it - and an empty directory_optional means it's looking for a "global directory" that only exists because the Blender-side addon configured it. Without Blender in the loop you'd have to hand-build a matching JSON file and point this node at its folder yourself, and the exact schema Texturaizer expects isn't spelled out in the README - you'd be reverse-engineering it from what the other getter nodes expect to find. If you are running the full Blender pipeline and this comes back empty, check the addon actually exported before you queued the prompt - that's a far more common cause than anything on the ComfyUI side.