Nodes/ComfyUI-AdvancedCameraPrompts/Advanced Camera Control Prompt Generator
ComfyUI Node

Advanced Camera Control Prompt Generator

Turn a 3D scene's camera into shot-type prompts the MultiAngle LoRA actually understands

By jandan520·Created 10 months ago·Updated 10 months ago· 35
Advanced Camera Control Prompt Generator
  • camera_info
  • prompt
  • camera_json
focal_length_mm50
object_scale_meters1.00
custom_description

The name sounds like it needs a PhD and a GPU cluster. It doesn't. The Advanced Camera Control Prompt Generator is a pure-math node that reads the camera from ComfyUI's built-in Load 3D node and turns it into a cinematography prompt like high angle medium shot (camera distance 2.5 m 50mm FOV 40°). No models to download, no API key, no inference. Just math and json.

Why you'd reach for it

Camera framing in 2026 runs on LoRAs, not ControlNet. dx8152's Multiple-Angles LoRA for Qwen-Image-Edit-2509/2511 moved "shoot this subject from a new angle" to a prompt-level control - the KB's qwen-image-edit panel calls it the thing that "turned camera framing into a slider." But that LoRA eats text, and hand-writing believable shot language for every frame is exactly the fiddly part people get wrong. This node sits between your 3D scene and that LoRA: set up the camera where you want it, and it writes the description for you, grounded in the actual position and target instead of a vibe.

It's also just good practice for anyone doing 3D-to-2D workflows. Naming a camera, a lens, and a framing is the single highest-leverage prompt move there is (the KB's prompt-engineering doc makes that case hard), and this node generates that language from geometry instead of from your memory of film terms.

How it works

You wire the camera output of a Load 3D or Load 3D - Animation node into the camera_info input. That node hands over a dict with position, target, and zoom, and the node does the rest:

  • Distance in grid units is converted to meters (1 grid unit = 4 m) and the pitch/yaw between camera and target are computed.
  • FOV comes from your focal length using the full-frame formula 2 × atan(sensor / (2 × focal)) on a 36×24 mm sensor.
  • Shot type is picked from distance, focal length, and FOV ranges - or, if you set object_scale_meters, from a framing calculation that figures out how much of the frame your subject fills.
  • Angle type comes from tilt thresholds: eye level, high angle, the low-angle ladder, bird's eye, plus dutch from roll.

One honest caveat, straight from the author: the generated text only expresses pan and tilt. No rotation, no trucking - because the LoRA renders a moving camera as a trucked object instead, so that motion was deliberately left out. And exact degrees/FOV are informational; the author says the LoRA doesn't interpret them precisely. It's a nudge, not a rigged camera.

Inputs and outputs that matter

Three optional inputs, and you'll only touch two:

  • focal_length_mm (default 50, range 1–1000) - drives FOV and shot classification.
  • object_scale_meters (default 1.0) - set this to your subject's real height and the shot type gets computed from framing instead of raw distance. This is the one that fixes "why does it call this a wide shot."
  • custom_description - text appended to the end of the prompt. Handy for scene-specific additions.

Outputs: prompt (a STRING you wire into your edit model's prompt/positive input) and camera_json (a STRING with all the numbers, if you're logging or batch-processing).

Installing it

ComfyUI Manager → search "AdvancedCameraPrompts", or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/jandan520/ComfyUI-AdvancedCameraPrompts.git

Restart ComfyUI. There's no requirements.txt to install and nothing heavy - the real requirement is a recent ComfyUI, because the Load 3D node it reads from is native core (it landed in late 2024). Old installs won't have the LOAD3D_CAMERA type and the input won't exist.

Where people get burned

The launch thread is honest about the rough edges. A C4D user reported their 72° camera tilt read as 46°, and the author's answer is the whole story: different DCCs use different axis conventions (Maya vs 3ds Max vs Blender), and the reference object's scale changes the reading. If your angles look wrong, it's usually the export, not the node. The node also assumes an eye-level reference height, so cameras exported at odd heights drift. And importing animated cameras into Load 3D - Animation is flaky - community reports say it mostly reads keyframed geometry, not camera tracks, so treat this as a still-scene tool until that improves.

Categoryprompt/camera

Inputs (4)

NameTypeDefaultDescription
camera_infoLOAD3D_CAMERA
focal_length_mmoptFLOAT501–1000
object_scale_metersoptFLOAT1.000.01–100
custom_descriptionoptSTRING

Outputs (2)

NameTypeDescription
promptSTRING
camera_jsonSTRING