DOGMA V50 Scene VLM Instruction
The prompt you write for the VLM, not the model — and it's the one that decides everything
- instruction
In a VLM-driven tile pipeline the instruction you give the vision model is more load-bearing than anything you say to the sampler. Get a vague inventory and every downstream stage - SAM segmentation, category crops, per-category prompts - inherits the vagueness. This node exists to write that instruction in one fixed, parseable shape.
Nothing else in the graph is as cheap and as underestimated.
What it emits
One string, built around your project context, ending with Output GROUP lines only. The contract:
GROUP|category|kind|prompt
GROUP|cars|OBJECT|1970s Italian cars on a road
GROUP|buildings|STRUCTURE|1970s Italian apartment buildings and balconies
- Up to six groups. Not an image description - a prioritised plan, because six is what the downstream crop/plan node can consume.
kindmust be OBJECT, STRUCTURE or SURFACE. That single field changes sampling behaviour later: structures and surfaces get a different denoise factor and a different stitch sigma from objects.promptis 3–10 words, a phrase describing that category in its actual context, not a restatement of the category.- A useful category list is handed over explicitly: cars, bus, trucks, people, buildings, grass, trees, road, water, animals, furniture, machinery, products, clothing, food.
- Banned as editable groups: sky, haze, fog, text, logos, signs, brands, defects. Sensible - those are exactly the regions where a mask-based restore is least welcome.
- "Include small repeated cars or people if they are genuinely visible", which is the opposite of the usual "only large obvious objects" bias. Small repeated instances are what a detail pass at 4 steps handles best.
And the clause that matters most across the whole pack:
Never add an object merely because the project context suggests it.
That's the same rule every composer enforces on the output side, pushed one step upstream so the VLM doesn't put it in the inventory in the first place. On an LLM-encoded model, context is an adjective; the moment a VLM treats "1970s Milan" as evidence, you get a plan asking SAM to segment a bus that isn't in the photo. Which would be harmless - except the plan nodes have fallback rows, so an invented category can end up with a real mask and a real generation.
Inputs and outputs
One required input: project_context (STRING, multiline). One output: instruction (STRING). Wire it into whatever text input your VLM node uses for its question. There are no settings, and the output is deterministic - same context in, same instruction out.
Install
ComfyUI Manager → search DOGMA Nodes, or:
cd ComfyUI/custom_nodes && git clone https://github.com/axior/ComfyUI-DOGMA-Nodes
Restart ComfyUI. No pip dependencies (requirements.txt is # No external dependencies.), no local models for this node - the VLM it's talking to comes from another pack. Note that the DOGMA README doesn't describe these v50 nodes; they register from dogma_semantic_v5641.py at import, and the source is the only documentation that exists.
Where it bites
Compliance is not guaranteed. The sibling plan node that parses this instruction is deliberately format-tolerant: it scans the whole VLM response for keywords, then falls back to a hardcoded category list - a "1970s Milan"-flavoured one, cars-people-buildings-grass-sky-road, or a generic alternative. So a non-compliant VLM doesn't error, it silently produces a plan you didn't ask for. If your tiles start restoring the wrong categories, check whether the VLM actually emitted GROUP| lines before touching anything else.
Six groups is a hard ceiling and the priority ordering downstream is fixed: objects first, then one structure, then two surfaces. Ask for ten and you lose four.
The project context is doing double duty. It has to be specific enough for the VLM to qualify what it sees (era, place) and vague enough not to be read as an inventory. "1970s Italian street photography in Milan" works. "1970s Milan with lots of cars and buses" is an instruction to find cars and buses.
Banned categories are the right instinct and easy to override - because if you edit the instruction, you own the consequences downstream. The banned list isn't a suggestion about what's visible; it's about what's editable.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| project_context | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| instruction | STRING | — |