DumasNodes/H3_LONG_VIDEOS_GUIDE.md

# Dumas H3 Long Videos Guide

This guide explains `Dumas H3 Long Videos (FL2VA + REF2VA)` in simple language.

The node does two jobs at once:

- It turns one prompt with several beats into a chain of H3 shots.
- It can condition those shots from a first frame, character references, location references, or both.

Think of it like this:

- `prompt` decides what happens.
- `shot_seconds`, `per_beat_length`, and beat-level `seconds:` decide how long each beat is allowed to be.
- `first_frame` and the handoff system decide continuity.
- `ref_1` to `ref_9` decide identity and location reference conditioning.

## How The Node Thinks

The node builds the final video one shot at a time.

1. It splits the prompt into beats.
2. It decides how long each beat should be.
3. It decides which reference images and/or handoff frame each beat should carry.
4. It samples each beat.
5. It joins the beats into one video.

That means many settings do not act alone. They work together.

## Group 1: Main Inputs

These are the inputs you always start with.

### `model`

The H3 diffusion model.

### `clip`

The H3 text encoder.

### `vae`

The H3 video VAE.

### `audio_vae`

The H3 audio VAE.

### `prompt`

This is the main shot description.

How it is used:

- First paragraph: the persistent anchor, unless `anchor_override` is filled in.
- Later paragraphs: the beat list.

What belongs here:

- character identity
- camera direction
- action
- dialogue
- scene events

What does not belong in the anchor paragraph:

- clothing that needs to change later

Put changeable clothing in `character_memory` or a beat-level `wardrobe:` line.

### `resolution`

This chooses the shape, not the size.

Examples:

- `16:9`
- `21:9`
- `1:1`

### `megapixels`

This chooses the pixel budget.

Simple rule:

- `resolution` picks the shape
- `megapixels` picks how big that shape is

Higher values give:

- more detail
- more VRAM use
- usually shorter safe shot lengths

Lower values give:

- less detail
- less VRAM use
- usually longer safe shot lengths

### `steps`

Main-pass sampling steps.

Default H3 usage is built around about `20` steps.

### `cfg`

Leave this at `1.0` unless you are deliberately experimenting.

This node is built around H3's CFG-free behavior.

### `sampler_name`

Main-pass sampler.

Usually leave this at the default unless you have a known reason to change it.

### `scheduler`

Main-pass scheduler.

Usually leave this at the default unless you have a known reason to change it.

### `seed`

The base seed for the chain.

With `vary_seed_per_shot` off, all beats use the same base noise field for better continuity.

## Group 2: Prompt Structure And Beat Splitting

These settings decide how the prompt becomes beats.

### `anchor_override`

If this is filled in, the node does not consume the first prompt paragraph as the anchor.

Use it when:

- you want every prompt paragraph to be a beat
- you want the persistent look controlled separately from the beat text

### `beat_split`

This controls how the prompt box is split into beats.

- `auto`: blank lines first, then multi-line paragraphs can still split line by line
- `each line`: every content line becomes a beat

What this really means:

- A beat is one shot.
- If the node accidentally reads two actions as one beat, it tries to do both in one shot.
- If it accidentally reads one action as two beats, it creates an extra cut.

So this setting is really about:

- how many shots the node will make
- where the cuts happen

### `character_memory`

Persistent wardrobe and style memory for tracked characters.

Good for:

- clothing that should stay stable
- clothing changes you want to control clearly

What this really means:

- The anchor is the permanent identity and scene language.
- `character_memory` is the persistent clothing and worn-item memory.
- If you put clothing in the anchor prose, the node keeps restating it forever.
- If you put clothing in `character_memory`, the node can change or remove it later.

### `auto_wardrobe`

Lets the node detect clothing removals directly from beat prose.

### `auto_props`

Lets the node carry props and objects across beats.

### `lock_restraints`

Keeps restraint items persistent until explicitly removed.

### `exposed_terms`

Persistent terms for exposed body states when you need them described consistently.

### `prevent_nudity`

Stops the node from explicitly stating a nude state in the prompt.

## Group 3: Beat Duration And Timing

This is the most important group to understand.

These settings work together:

- `shot_seconds`
- `per_beat_length`
- beat-level `seconds:` or `duration:`
- `allow_oversize_shots`
- `megapixels`
- `vram_headroom_gb`
- `allow_res_backoff`

### The Short Version

`shot_seconds` is a ceiling, not a promise.

A beat-level `seconds:` line is a request, not absolute law.

The final beat length is limited by:

- H3's hard single-shot max
- the VRAM budget
- the current resolution and pixel budget

### Exact Decision Order

For each beat, the node decides length like this:

1. If the beat has `seconds:` or `duration:`, use that as the requested length.
2. Otherwise, if `per_beat_length` is on, estimate the beat length from its content.
3. Otherwise, use the global shot ceiling.
4. Clamp that result to the global `shot_seconds` ceiling if one is set.
5. Clamp again if H3 or VRAM will not allow that size.
6. Snap the result to H3's frame grid.

### `shot_seconds`

Global per-shot ceiling.

Important:

- This does not mean every beat will be exactly this long.
- It means no beat is allowed to be longer than this, unless other limits clamp it first.

If left unconnected or set to `0`, the node uses the largest safe shot length it can budget automatically.

### `per_beat_length`

When on, the node estimates beat length from the beat content if there is no explicit beat-level `seconds:` line.

That means:

- short simple beats become shorter shots
- more complex beats become longer shots

When off:

- every beat uses the full global ceiling unless that beat has its own explicit `seconds:` line

### Beat-Level `seconds:` Or `duration:`

Inside a beat, you can write:

```text
seconds: 8
```

or

```text
duration: 8
```

This has the highest priority for that beat.

But it can still be clamped down if:

- it exceeds the global `shot_seconds` ceiling
- it exceeds H3's hard max shot length
- it exceeds the VRAM budget and `allow_oversize_shots` is off

### `allow_oversize_shots`

This only affects forced global `shot_seconds`.

When off:

- too-long requests are clamped down to what fits

When on:

- the node will try to honor the requested global ceiling even if it exceeds the safe VRAM budget

Trade-off:

- slower renders
- possible spill to system RAM
- possible OOM

This does not bypass H3's hard max shot size.

### `vram_headroom_gb`

This reserves VRAM safety margin before the node decides the safe shot length.

Higher headroom:

- safer
- shorter shots

Lower headroom:

- longer shots
- more crash risk

### `allow_res_backoff`

If a render does not fit, the node can step the resolution down instead of failing immediately.

This can save a render, but it also changes the effective size of later shots.

### What Actually Makes A 20-Second Beat

In the current node, a beat does **not** automatically become 20 seconds just because it says `seconds: 20`.

Why:

- H3 has a hard single-shot frame cap
- the node also respects a VRAM budget

So `seconds: 20` means:

- "try for 20 seconds"
- then clamp it to what H3 and VRAM allow

If you need around 20 seconds of action, you usually need:

- two beats
- or a different workflow structure

## Group 4: Continuity And Shot Chaining

These settings control how one beat connects to the next.

What continuity means here:

- Beat 1 renders a shot.
- The node can take the end of that shot and feed it into beat 2 in different ways.
- That carry-over is what makes a chain feel like one continuous take instead of a series of disconnected clips.

There are two main kinds of carry-over:

- a real keyframe anchor
- a softer "use this as a reference image too" carry

The real keyframe is stronger for continuity.
The reference-image carry is weaker, but can coexist more safely with some ref setups.

### `first_frame`

Optional opening keyframe for shot 1.

If empty, the first shot begins from text/reference conditioning alone.

What this really means:

- This is only for the start of the chain.
- It does not control later shot transitions unless beat 1 hands its final frame forward.
- If you want the opening shot to start from a specific composition or pose, use this.

### `trim_seam`

Drops the first frame of each later shot.

Use this to avoid showing the same handoff moment twice.

What this really means:

- The next shot often begins by reproducing the frame it was handed.
- If you keep that frame, you see the same instant twice.
- Trimming the seam hides that duplicate frame and makes motion feel smoother.

### `handoff_offset`

Hands an earlier frame to the next shot instead of the literal last frame.

Useful when:

- a shot ends with an open mouth
- the next shot starts with awkward lip motion

What this really means:

- The literal final frame of a shot can be a bad frame to continue from.
- Example: a character is mid-word, mouth wide open.
- If the next shot starts from that exact frame, the new shot can begin with ugly mouth motion.
- Offsetting by a few frames lets the node hand forward a cleaner pose.

### `vary_seed_per_shot`

Changes the seed between beats.

Usually leave this off for a continuous take.

Turning it on makes cuts feel more separate because micro-detail resets between beats.

What this really means:

- The overall person and scene can still be "the same" in a broad sense.
- But tiny details like skin texture, cloth texture, grain, and little surface quirks will refresh at each beat.
- So this is often the difference between:
  a true continuous-feeling chain
  and
  a sequence of visually related separate shots

### Beat-Level `continuity:`

You can override continuity for one beat inside the beat text.

Examples:

```text
continuity: hard cut
continuity: keyframe carry
continuity: handoff ref
continuity: soft carry
```

What each option really does:

### `continuity: hard cut`

The next beat starts fresh.

In practice:

- do not carry the previous shot forward as a keyframe
- do not treat the previous shot as a continuation anchor
- let the new beat begin like a new setup

Use it when:

- you want a deliberate cut
- the previous shot ended in a bad transition state
- wardrobe/state changed and you do not want the old frame dragging that state into the next shot

### `continuity: keyframe carry`

The next beat starts from the previous frame as a real anchor.

In practice:

- the node tells the new shot to start from that exact handed-forward frame
- this is the strongest continuity mode

Use it when:

- you want the new beat to feel like the same take continued
- you care more about continuity than about allowing the new beat to re-compose itself freely

Risk:

- if the carried frame is bad, awkward, or mid-transition, the next shot inherits that problem

### `continuity: handoff ref`

The previous frame is carried as an extra reference image instead of as the strict starting keyframe.

In practice:

- the new shot is shown the previous frame as guidance
- but it is not forced to literally begin from it

Use it when:

- you still want some continuity
- but a real keyframe carry is too rigid
- or the shot is already heavily reference-conditioned and you want a softer transition

Trade-off:

- smoother than a hard cut
- weaker than a true keyframe carry

### `continuity: soft carry`

Carry the previous shot only if the new shot is not already using references.

In practice:

- if the beat has no ref images, the handoff can carry forward
- if the beat is already ref-conditioned, the shot is allowed to begin more independently

Use it when:

- you want a sensible default
- you want continuity where it fits
- but you do not want every ref-conditioned beat forced too hard to the last frame

### When To Use Which One

Use this mental model:

- `hard cut` = new shot, start fresh
- `keyframe carry` = continue the same take
- `handoff ref` = remind the new shot where it came from
- `soft carry` = continue when convenient, back off when refs already dominate

### How continuity settings work together

The final transition is shaped by all of these together:

- `first_frame`
- `trim_seam`
- `handoff_offset`
- `vary_seed_per_shot`
- beat-level `continuity:`
- whether the shot is also carrying character/location refs

Example:

- `keyframe carry` plus `trim_seam` plus stable seed usually gives the smoothest chain
- `hard cut` plus different seed gives the most separate-looking next shot
- `handoff ref` is the in-between option

## Group 5: References And Identity

These settings decide how reference images are used.

### `ref_1` To `ref_9`

These are the real reference slots.

Feed them with:

- `Dumas Character Reference`
- `Dumas Location Reference`

Each slot has a stable picture number:

- `ref_1` = `<Picture 1>`
- `ref_2` = `<Picture 2>`
- and so on

### `ref_image_1` To `ref_image_9`

Legacy compatibility aliases for older graphs.

You should prefer `ref_1` to `ref_9` in new work.

### `ref_mode`

Controls which beats receive the reference images.

Modes:

- `auto ref2v`: if tags exist, use them; otherwise condition every shot
- `where tagged`: only tagged shots get refs, with first-shot fallback when no tags exist
- `first shot`: references only on shot 1
- `every shot`: references on every shot
- `every shot + handoff ref`: references on every shot plus previous frame as an extra soft ref

What this really means:

- `ref_mode` decides when H3 actually sees the reference images.
- This is not just about prompt words. It controls whether the images themselves are part of the conditioning for that beat.

### `auto ref2v`

Best general default.

What it does:

- if the prompt uses `<Picture N>` tags, those tags control placement
- if there are no tags anywhere, all connected refs are used on every shot

Why this exists:

- single-character chains often want identity support on every beat
- forcing tags for every shot would be annoying

### `where tagged`

Strict explicit routing.

What it does:

- if tags exist, only the tagged shots get those refs
- if there are no tags at all, it falls back to first-shot behavior

Use it when:

- you want exact manual control
- you do not want every beat pulling every ref

### `first shot`

Use refs only to establish the look at the start.

What it does:

- beat 1 gets the refs
- later beats rely on continuity from the chain itself

Use it when:

- you want the look established once
- then want later shots to flow from the chain rather than keep reasserting the refs

Risk:

- identity can drift later if continuity alone is not strong enough

### `every shot`

Use refs every time.

What it does:

- every beat gets the refs again

Use it when:

- identity drift is the main problem
- you would rather keep the face stable even if the chain feels more cut-based

Risk:

- transitions can feel less like one continuous take

### `every shot + handoff ref`

Use the references every time and also carry the previous shot as another soft reference.

What it does:

- keep identity pressure high
- still remind the next beat what the previous shot looked like

Use it when:

- you want both identity support and some transition support
- but you do not want a hard keyframe carry

### `ref_image_size`

Controls how large the reference is encoded.

- `match`: cheaper, usually enough
- `max`: stronger identity/location fidelity, slower and heavier

What this really means:

- `match` keeps the ref conditioning lighter and cheaper
- `max` gives the model a larger, richer reference encoding

If faces are drifting and the card can handle it, `max` is one of the first things to try.

### `ref_noise_aug`

Controls how literally the model follows the reference image.

Higher:

- cleaner
- more literal
- more likely to reproduce the reference closely

Lower:

- softer
- more approximate
- more likely to drift

What this really means:

- high values say "follow this reference closely"
- lower values say "take this more as guidance"

So this is one of the main identity-strength knobs.

### Beat-Level `ref_mode:` And `ref_noise_aug:`

You can override these inside a beat.

Examples:

```text
ref_mode: every shot
ref_noise_aug: 0.95
```

### How The Ref Settings Work Together

The node uses reference data in two different ways:

- the image itself for real visual conditioning
- the text metadata for prompt context

Character refs can now contribute actual image identity when the beat names the character, not just when you explicitly tag the picture slot.

Simple usage patterns:

- one character, no special routing: use `auto ref2v`
- one location plus named characters: use character names in the beat and tag the location when needed
- exact slot control: use explicit `<Picture N>` tags

What to remember:

- tags control explicit slot placement
- names can pull matching character refs into the real image-conditioning list
- location refs are often tagged because they are about where the shot happens
- character refs are often named because they are about who is in the shot

## Group 6: Audio And Sound

These settings shape the soundtrack behavior.

### `global_soundscape`

Persistent ambient sound for the whole chain.

Examples:

- rain
- room tone
- crowd murmur
- engine hum

### `non_diegetic_music`

Background score that the characters do not hear.

### `auto_soundscape`

Lets the node derive an ambient bed from the prompt/anchor.

Modes:

- `off`
- `fill if blank`
- `always`

### `auto_silence_nonspeech`

Adds prompt-side silence control to beats with no quoted dialogue.

What this really means:

- the node tells H3 "nobody is speaking here"
- this helps stop random mouth motion and random voice babble
- but it is still only prompt guidance, not a hard guarantee

### `allow_nonspeech_vocals`

Allows screams, gasps, sobs, and similar non-dialogue sounds in otherwise non-speaking beats.

What this really means:

- you still do not want speech
- but you do want human vocal sounds
- this is the "let them cry, gasp, scream, groan" option

### `mute_nonspeech_audio`

Hard mutes the audio for non-dialogue beats.

This is the deterministic anti-babble switch.

Trade-off:

- you also lose the generated ambience for those beats

What this really means:

- if the beat has no dialogue, the node can zero that beat's audio
- this is the most reliable way to stop H3 inventing speech
- but it also deletes any nice incidental ambience H3 might have generated for that beat

### `mute_fade_ms`

Smooths the edges of audible shots next to muted ones.

### How The Audio Settings Work Together

There are two layers:

- prompt-level guidance
- hard muting

That means:

- `auto_silence_nonspeech` is the polite request
- `mute_nonspeech_audio` is the hard enforcement

If you want the safest anti-babble setup:

- leave `auto_silence_nonspeech` on
- leave `mute_nonspeech_audio` on

If you want distress sounds like sobbing or gasping:

- leave `auto_silence_nonspeech` on
- turn `allow_nonspeech_vocals` on
- usually leave `mute_nonspeech_audio` off for those shots

## Group 7: Model Sampling And Flow Shifts

These settings are for H3's internal scheduling.

### `apply_model_sampling`

Applies the H3 video/audio sampling schedule inside the node.

Usually leave this on.

### `shift_video`

Video flow shift.

### `shift_audio`

Audio flow shift.

These two belong together.

If you change `shift_video`, you usually need to change `shift_audio` in proportion.

## Group 8: Detail Pass

This is the optional second pass.

### `detail_pass`

Enables the refinement pass.

What this really means:

- the node renders the beat once
- then runs a second sampler pass over that result
- the goal is to polish, not to invent a whole different shot

### `detail_sampler_name`

Sampler for the refinement pass.

### `detail_scheduler`

Scheduler for the refinement pass.

### `detail_steps`

Extra steps for the refinement pass.

What this really means:

- more steps gives the second pass more opportunity to change the image
- that can help detail
- but after a point it stops being "cleanup" and starts becoming "rewrite"

### `detail_denoise`

How strongly the refinement pass is allowed to rewrite the beat.

What this really means:

- low denoise = polish what is already there
- high denoise = let the second pass substantially alter what is already there

### How The Detail-Pass Settings Work Together

The detail pass starts from the first-pass result and tries to polish it.

Gentle settings:

- low to medium `detail_steps`
- low `detail_denoise`

Aggressive settings:

- high `detail_steps`
- high `detail_denoise`

Aggressive settings can improve texture, but they can also:

- change faces
- pull away from references
- break continuity

That is why this group should be read as one combined strength control:

- `detail_pass` decides whether the second pass exists
- `detail_steps` decides how long it keeps working
- `detail_denoise` decides how free it is to change things
- `detail_sampler_name` and `detail_scheduler` shape how that rewrite behaves

Good starting point:

- `detail_pass = on`
- `detail_sampler_name = euler`
- `detail_scheduler = beta`
- `detail_steps = 4` to `8`
- `detail_denoise = 0.20` to `0.35`

## Group 9: Performance, Decode, And Upscale

These settings help the job fit in memory and decide what happens after sampling.

### `decode_tile_frames`

Temporal tiling for VAE decode.

Useful when decode is the memory bottleneck.

### `decode_tile_size`

Spatial tiling for VAE decode.

Useful on tighter cards at larger resolutions.

### `cleanup_between_shots`

Moves completed shot data off the GPU and clears memory between beats.

Good default for long chains.

### `upscale`

Optional post-pass upscale mode.

### `upscale_model`

Upscale model when `upscale = model`.

### `upscale_target_short_edge`

Resize target for the final output.

### `upscale_batch`

How many frames are upscaled at once.

### How These Settings Work Together

Use them in this order:

1. Get the render stable.
2. If decode fails, use decode tiling.
3. If shot length is too short, reduce pixel cost before forcing oversize.
4. Only upscale after the base render is working.

## Group 10: Overlay Controls

These settings affect only the final frames, not the model prompt.

### `watermark_text`

Text watermark added after rendering.

### `watermark_position`

Watermark placement.

### `watermark_size`

Watermark size.

### `watermark_opacity`

Watermark transparency.

### `watermark_margin`

Watermark edge spacing.

### `intro_text`

Opening title text.

### `intro_position`

Title placement.

### `intro_seconds`

How long the title stays fully visible before fading.

### `intro_fade`

Fade length for the title.

### `intro_size`

Title size.

### `overlay_font`

Font used for overlays.

### `overlay_stroke`

Outline thickness around the text.

## Group 11: Safety And Geometry Guards

These are prompt-side stabilizers.

### `subject_count_guard`

Helps stop accidental character duplication.

### `anatomy_guard`

Helps stop extra limbs and hand duplication.

### `motion_guard`

Helps keep movement smooth and physically continuous.

### `contact_guard`

Helps keep multiple bodies aligned correctly in contact scenes.

### `solidity_guard`

Helps stop bodies clipping through objects.

### How The Guard Settings Work Together

These are best treated as stabilizers, not magic fixes.

Recommended pattern:

- leave most on `auto`
- only force `on` when you know that failure mode is likely

## Quick Recipes

### Simple One-Character Ref2V Chain

- one character ref in `ref_1`
- `ref_mode = auto ref2v`
- no explicit `<Picture 1>` tags needed
- `per_beat_length = on`

### Two Characters Plus One Location

- character refs in two slots
- location ref in another slot
- name the characters in the beats
- tag the location slot explicitly when location control matters

### Exact Per-Beat Timing

- use `shot_seconds` as a safe ceiling
- put `seconds:` inside beats that need exact control
- check `plan_only` first
- expect clamping if you ask for more than H3 or VRAM allows

## Best Way To Check What Will Really Happen

Use `plan_only`.

That is the quickest way to see:

- beat count
- planned shot count
- actual per-shot lengths
- clamps
- ref placement
- continuity choices

If the plan looks wrong, the render will too.