Scene Entity - Fantasy

First thing to know, and it saves you a node: you don't need this to generate fantasy scenes. The Scene Weaver - Fantasy node is complete on its own, and its slot 1 already carries a full creature's worth of detail. Scene Entity exists for the two things the Weaver can't do - describing a second subject just as richly, and building one creature you carry across many scenes instead of re-rolling it.

It describes exactly one thing: silhouette, material, colours, markings, close-range wear, appendages and how many, emitters and how many and what colour they glow, armament, sensors, apertures. Then it hands that to a scene.

The outputs, and why there are two

• entity_text - the entity as it will read inside a scene, as prose. Wire it to a Show Text node to read it. It is not a full prompt: no setting, no action.
• entity - a SCENE_ENTITY payload for one of the Scene Weaver's optional entity_1_in … entity_4_in sockets.

Nothing else. The entity deliberately carries no environment, no situation and no relations, because the scene owns all three. That's the design, not a gap: an entity that brought its own "standing in a castle courtyard" would fight whichever scene you wired it into.

The socket is the same type across every genre. A fantasy entity wires into a Fantasy, Sci-Fi or Horror Scene Weaver; a sci-fi entity wires into a fantasy scene. A crashed starship in an enchanted forest is a supported feature. It's a dedicated socket type rather than a string, too, which stops you plugging an entity into a text box and wondering why nothing changed.

How it works

Every field is Random / a value / None, same as the Weaver's. kind governs the rest - it scopes the options and the labels of every field beneath it, across dragon, mythic beast, giant-kin, small folk, hybrid folk, folk, spirit or elemental, undead, construct, structure, vessel and artifact. That's why you can't get a unicorn hauling cargo, or a gatehouse arch on a pixie.

Wire it into a scene and four rules apply:

• A field you locked is a choice. It beats that slot's own widgets and beats a coherence rule, and the rule's reasoning is reported in prompt_json._meta, so nothing is overruled silently.
• A field left on Random is a draw. The scene first picks a place that can hold the whole wired subject, and only re-draws a drawn field when no place can - naming what it re-drew on the node face.
• Situation and relations never come from the entity. What the thing is doing stays the scene's call.
• A wired slot gets the scene's top detail allowance - the same budget slot 1 gets - but it's a promotion, not an exemption. How much a slot speaks is capped by what kind of thing it is: a creature or a person carries its whole component list, a tower or a galleon only its silhouette. A structure with every widget locked can still read short.

One more detail: this node has no Peaceful/Conflict filter, correctly, because the filter is a property of the scene the entity lands in. And the readout shows exactly what the entity will contribute to a one-entity scene, so it doubles as a preview.

Why bother

The reuse case is the real one. A diffusion model has no internal concept of a character - no this creature in the weights, only statistical patterns - so the only thing carrying your frost troll between scenes is the words describing it. Lock the fields that made it work, keep the seed, and it comes back. That's consistency without training a LoRA.

Install

ComfyUI Manager: search SceneWeaver. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/EnragedAntelope/comfyui-sceneweaver

Keep the folder named comfyui-sceneweaver and restart. No dependencies - standard-library Python, no requirements.txt, nothing to compile - but it needs ComfyUI 0.25.0+ (it's built on the newer comfy_api.latest node API) and Python 3.10+. Both nodes appear under conditioning/sceneweaver.

Your own creature types and materials go in a user_options.json beside the pack - gitignored, so it survives a git pull - with fantasy values in a "fantasy" section.

python scripts/builtin_options.py subkind --kind dragon --pack fantasy

Where it goes wrong

You wired an entity and the scene ignored that slot's widgets. That's the feature: the wire replaces the slot's descriptive widgets. Situation and relations still come from the scene node.

Your locks looked "overruled." They weren't - a lock beats a rule. What you're seeing is a drawn field being re-drawn to fit; prompt_json._meta names the rule and the reason.

A detailed monster came out short. Kind-based cap: people and creatures speak their whole component list, buildings and ships don't.

user_options.json additions did nothing. Fields like form, material and markings are overridden by every kind, so a _default pool for them is never read - add them under a kind name. The console tells you when you've got it backwards.

Old ComfyUI. Below 0.25.0 you get an import error on comfy_api.latest instead of a node.