Klein4&9 MultiAngle Prompt

Klein4&9 MultiAngle Prompt is a text-builder, not a magic camera. You pick a vertical angle, a viewing direction, and a shot size from dropdowns, and it assembles a grammatically correct English description of that camera setup, prepends it to your prompt, and hands you a STRING to feed into your text encoder. That's the whole job - no API, no key, no model files, no dependencies. The pack name references BFL's Flux 2 Klein 4B/9B, and if that's the world you live in, this is aimed squarely at you.

Why reach for it? Because "name the physical camera" is genuinely the highest-leverage phrase there is in modern prompting, and it's a pain to type well every time. Most people get lazy and write low angle shot - which is a coin-flip. This node writes the full sentence: "Rotate the angle of the photo to a bottom-up low angle direct front view shot of the subject, with the camera positioned below and facing front…" That reads like the caption data an LLM encoder was actually trained on, which is exactly the point.

How it builds the prompt

The mechanism is dead simple, and you can read the whole thing in nodes.py - it's a couple of dictionaries and a string join. Internally it stores 24 pre-written angle descriptions (3 vertical × 8 horizontal), each a full sentence, plus 7 zoom descriptions. When you hit Generate it:

1. Looks up the angle sentence for your vertical_angle + horizontal_view combo.
2. Looks up the zoom sentence for your zoom_level (or nothing, if you picked the neutral option).
3. Joins those camera lines together, appends your base_prompt as a separate block, and joins everything with newlines.
4. Always ends the string with a trailing newline, which matters more than it sounds like - it makes the output drop cleanly into string concatenation or further prompt-processing nodes.

The output is one STRING that wires straight into a CLIP Text Encode / text encoder node. On SDXL-lineage models it's just descriptive sentences, which is fine. On LLM-encoded models - Klein, Z-Image, Anima, the Flux 2 family - block-structured instructions like this land hard, because those encoders were trained on real captions, not comma-separated tags.

The inputs that matter

Only four, and all are required in the schema:

• vertical_angle - Top angle, Eye level, Bottom angle. The up/down height of the camera.
• horizontal_view - eight directions: front view, front-left view, left side view, back-left view, back view, back-right view, right side view, front-right view. Note the "strict profile" options are just the side views; it's a clean 360° sweep.
• zoom_level - seven options from extremely close up through full body to extremely wide. The standout is as is without prompt, which adds nothing about distance - genuinely useful when you want an angle change without the model re-framing the subject.
• base_prompt - the multiline box with a big default about keeping the subject's identity, clothes, and facial features identical. That default is aimed at editing/re-posing workflows, and you'll usually replace it with your actual subject description.

Installing it

There's no dependency tree here - no requirements.txt, no model downloads, nothing to break. Clone it and restart:

cd ComfyUI/custom_nodes
git clone https://github.com/thezveroboy/ComfyUI-klein4-9multiangle

Then restart ComfyUI and look for Klein4&9 MultiAngle Prompt under the prompt/multiangle category. Since the pack is indexed on comfy.icu, ComfyUI Manager should find it by searching "klein4-9multiangle" too - same thing, same restart.

Where it shines and where it won't save you

The honest caveat is right in the README: this node is pure prompting, based on the model's own training data - it is not a LoRA, and no angle you select will force a result. Text is a hint; the model decides. Where people get burned is expecting dropdown→obedience on a model that doesn't know what three-quarter back-left means, then blaming the node.

Two things actually move the needle:

• Run it on a model that understands instructions. On Klein, Z-Image, or any Qwen-encoded model, block-structured camera prose works well. On an SDXL checkpoint it's just fancy words and the effect is much weaker - don't expect a Pony model to rotate around a subject.
• Pair it with a multi-angle LoRA for real rotation work. The community's multi-angle LoRA scene (the Qwen-Edit multiple-angles LoRAs, for example) is built exactly for "rotate the camera around this one subject," and the README says the same thing: this node works more effectively when you combine it with a suitable angle LoRA.

Otherwise, expect consistency to come from the rest of the workflow - same seed, img2img or editing context, and your base_prompt pulling its weight. Use it to stop retyping camera prose across a hundred variations, not to substitute for ControlNet or a LoRA. For that job, it's the one I'd reach for.