Camera Pose Qwen Panel

Anyone who's written "the camera slowly orbits to a high angle" into a text-to-video prompt and watched the model ignore it knows the frustration: natural-language camera control mostly doesn't land. Camera Pose Qwen Panel attacks that from the other direction. It's a three-slider widget with a little 3D ball preview that spits out a formatted camera pose description you can paste straight into a prompt or feed into a node that conditions on camera language. No model, no API, no key - it's pure deterministic formatting, and that's exactly why it works.

The name nods at the Qwen camera-pose style (the structured "front view, eye level, medium shot" vocabulary Alibaba's Qwen2-VL family uses for camera estimation). This node produces that same dialect of text, so it drops into workflows already tuned to that format. You're not invoking Qwen - you're speaking its language.

How it works

Three inputs, that's the whole node:

• azimuth (0–360°) - where the camera sits around the subject
• elevation (-30° to 90°) - how high the camera is looking from
• zoom (0–10) - distance, where 10 is a close-up

The node clamps everything, normalizes the angle, and runs it through a lookup ladder: azimuth becomes one of eight directions (front view, front right side view, right side view, …), elevation becomes one of five bands (low angle, eye level, high angle, very high angle, bird's-eye view), and zoom becomes a shot size (wide shot, medium-wide, medium, medium-close, close-up). The output description looks like:

front view, eye level, medium shot (horizontal: 0, vertical: 0, zoom: 5.0)

Because it's a rule-based mapping, the same numbers always produce the same string - no sampling, no hallucination, nothing to tune. You can drive it from anywhere: hardcode values, animate them with keyframes, or chain it after a node that outputs a pose. The one output that matters is description (STRING); the node also passes back azimuth, elevation, and zoom as floats in case something downstream wants the raw numbers.

Where it sits in a workflow

The obvious use is text-to-video camera control: wire description into a prompt template that already understands "shot" vocabulary, and you get repeatable framing instead of hoping the model guesses. Pair it with the pack's Gaussian Viewer Select and you have a nice loop - fly a camera around a 3D scene, then reuse those exact angles as the prompt for a generation. It's also handy for anyone building camera-conditioned pipelines who wants to inspect exactly what "azimuth 135" means before committing it to a prompt.

Install

Same pack as Gaussian Viewer Select:

cd ComfyUI/custom_nodes
git clone https://github.com/supart/comfyui_gaussian_splat
cd comfyui_gaussian_splat
pip install -r requirements.txt

Restart ComfyUI (and hard-refresh the browser). ComfyUI Manager also has it under comfyui_gaussian_splat. Dependencies are numpy, torch, plyfile, Pillow - nothing exotic.

Common gotchas

The biggest trap is expecting more than it does. This is a formatter, not a camera controller - nothing in ComfyUI moves because you moved the slider. If your video model ignores shot vocabulary entirely, this node won't fix that; it just makes your prompt unambiguous. Second, remember the zoom direction is inverted from intuition for some people: higher zoom means closer (close-up), lower means wider. And negative elevation is a low angle, positive is looking down from above. Get those two backwards and your "bird's-eye close-up" suddenly means something else entirely. Keep the values modest and read the description string - it tells you exactly what the model will see.