OpenDiT Conditioning
Your prompt gets dressed up before OpenSora ever reads it
- opendit_t5_encoder
- opendit_ref
- opendit_cond
OpenSora v3 doesn't work the way you're used to from image models. You don't write a prompt and get a condition; you write a prompt, optionally add a camera direction, an aesthetic score and a motion score, and the model stitches all of that into the actual prompt string before T5 ever sees it. This node is where that happens. It's the text half of the pack, sitting between the T5 loader and the sampler.
How it works
The node does three things in order, and the source spells them out clearly. First it takes your prompt and appends any of the structured controls as literal text - aesthetic score: 6.5., motion score: 3.0., camera motion: pan left. - using OpenSora's own append_score_to_prompts helper. Second, it runs the whole thing through OpenSora's text_preprocessing cleanup (fixing broken text, unescaping, that kind of thing). Finally it pushes the result through the T5 encoder you loaded and hands the embedding to the sampler.
That's why the score inputs exist: they're not sliders the model reads numerically, they're phrases glued onto your prompt. Set aesthetic_score to 0 and it's omitted entirely (the code only appends it when it's above 0) - same for flow_score. camera_prompt is only added if it's not empty. So if you want a boring default, leave flow at 0 and camera blank, and it's a pure text-to-video conditioning.
One more thing tucked in the source: the pack keeps OpenSora's loop-prompt machinery, so prompts can carry the |0| segmented syntax for longer, structured scenes. You can ignore it - most people do - but it's why the node "processes prompt step by step" instead of a straight encode.
Inputs that matter
- prompt - multiline, the actual scene description. Do your normal prompt-writing here.
- camera_prompt - a camera instruction like "pan left" or "zoom in", appended as
camera motion: .... OpenSora follows these surprisingly well. - aesthetic_score - default 6.5, range 0–100. Appended as a score only when above 0. Higher reads as "more aesthetic" to the model; this is OpenSora's own tuning knob.
- flow_score - default 0, and it should stay 0 until you know what you're doing. It steers motion magnitude; crank it and scenes get frantic.
- keep_model_loaded - off by default. When off, the T5 encoder is shuttled back to RAM after encoding to free VRAM. Leave it off unless you're doing back-to-back batches.
- opendit_ref (optional) - wire in the output of
OpenSoraEncodeReferencehere to make this an image-to-video conditioning instead of pure text.
The output, opendit_cond (type OPENDITCOND), goes straight into OpenDiTSampler. It also carries the reference-image latent and mask strategy through when you did image-to-video, so the sampler knows to paste your start frame in.
Installing
Search "ComfyUI-OpenDiTWrapper" in ComfyUI Manager, or:
cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-OpenDiTWrapper
pip install -r requirements.txt
pip install xformers --no-deps
Restart ComfyUI. On the Windows portable build, run pip through python_embeded\python.exe.
Where people get burned
The biggest confusion is the scores. Because they're appended to the prompt, a flow_score of 50 isn't "medium motion" - it's the literal words motion score: 50.0 being jammed in, and the model treats high values as extreme. Start at the defaults and treat 0–10 as the usable band. Also: this node needs the T5 encoder loaded, and if your first run "hangs" here it's almost always the encoder still downloading, not a bug.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| opendit_t5_encoder | OPENDITT5 | — | |
| prompt | STRING | — | |
| camera_prompt | STRING | — | |
| aesthetic_score | FLOAT | 6.50–100 | — |
| flow_score | FLOAT | 0.00–100 | — |
| keep_model_loaded | BOOLEAN | false | — |
| opendit_refopt | OPENDITREF | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| opendit_cond | OPENDITCOND | — |