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` 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.

### How wardrobe tracking really works

In code, the node turns `character_memory` into a live per-person table.

Think of it as:

- one entry per tracked person
- each entry holds a list of currently worn items and persistent description items
- every beat can edit that table before the shot prompt is built

Simple example:

```text
Maya = she, silver hair, grey shorts, red jacket
Jon = he, tall, black jeans, work boots
```

At the start of the chain, the node reads that as:

- Maya is currently wearing `grey shorts` and `red jacket`
- Jon is currently wearing `black jeans` and `work boots`
- `she` and `he` are also used to resolve pronouns in beat prose

Then for each beat, the node does this:

1. Read any beat directives like `wardrobe:`, `exit:`, `enter:`, `seconds:`, `continuity:`.
2. Update the live state first.
3. Rebuild that beat's prompt from the updated state.
4. Render the shot.
5. Carry the new state forward to the next beat.

That means wardrobe is not stored in the rendered frames. It is stored in code as a mutable state table, and the prompt for each new beat is rebuilt from that table.

### `character_memory` syntax

You can write one person per line or separate people with `;`.

These all work:

```text
Maya = she, silver hair, grey shorts, red jacket
Jon = he, shaved head, navy overalls
```

```text
Maya: she, silver hair, grey shorts, red jacket; Jon: he, shaved head, navy overalls
```

Single-person unnamed form also works:

```text
she, silver hair, grey shorts, red jacket
```

Practical advice:

- put identity traits here only if you want them re-applied every beat
- put changeable clothing here rather than in the anchor paragraph
- declare pronouns for multi-character scenes so prose like `she removes her jacket` can be matched to the right person

### Beat-level `wardrobe:` directives

`wardrobe:` edits the live wardrobe table for that beat.

Supported forms:

```text
wardrobe: Maya = grey shorts, white vest
wardrobe: Maya += sunglasses
wardrobe: Maya -= jacket
```

Meaning:

- `=` replaces that person's tracked outfit/items
- `+=` adds item(s)
- `-=` removes matching item(s)

With two or more people, only the named people are changed. Everyone else keeps their current state.

You can update more than one person at once:

```text
wardrobe: Maya -= jacket; Jon += hard hat
```

Unnamed single-subject shorthand also works:

```text
wardrobe: += sunglasses
wardrobe: -= jacket
```

### What `auto_wardrobe` really does

When `auto_wardrobe` is on, the node also scans beat prose for removal actions.

Examples it tries to understand:

- `she takes off her jacket`
- `Maya slips out of her boots`
- `his shirt falls to the floor`

If the item is already in that person's tracked wardrobe, the node removes it from the live state before it builds the shot.

Important limits:

- this is mainly for removals, not additions
- additions and swaps are still best done with explicit `wardrobe:` lines
- quoted dialogue does not count, so `"take off your jacket"` does not remove the jacket
- if the subject is ambiguous, results can be weaker or broader than a named directive

Best practice:

- use prose removal when it is simple and obvious
- use `wardrobe:` when you need exact control

### `exit:` and `enter:`

These control who is considered present in later beats.

Examples:

```text
exit: Jon
enter: Jon
```

What they do:

- `exit:` marks that character as gone after the current shot
- `enter:` allows them back into later shots

The node can also detect some exits from plain prose, but explicit `exit:` is safer when timing matters.

### Other beat directives

These are the beat-level directives the node knows how to read:

- `seconds:` or `duration:`: request beat length
- `wardrobe:`: edit tracked wardrobe/state
- `exit:`: remove a character from later beats
- `enter:`: bring a character back
- `continuity:`: override shot-to-shot carry behavior
- `ref_mode:`: override reference placement for that beat
- `ref_noise_aug:`: override reference strength for that beat
- `anchor_add:`: append extra persistent text to that beat only
- `overall_soundscape:` or `soundscape:`: beat-level ambient sound override
- `non_diegetic_music:` or `music:`: beat-level score override

### `auto_wardrobe`

Lets the node detect clothing removals directly from beat prose.

Used together with `character_memory`:

- `character_memory` says what someone is currently wearing
- `auto_wardrobe` listens for prose that removes something already on that list
- `wardrobe:` is the manual override when you want exact control

### `auto_props`

Lets the node carry props and objects across beats.

What that means in code:

- when a beat introduces a prop, the node remembers it
- later beats that say `the van` or `the wrench` can be bound back to the earlier prop instead of inventing a fresh one
- repeated prop mentions inside one beat are also deduped to reduce duplicate-object errors

### `lock_restraints`

Keeps restraint items persistent until explicitly removed.

This is intentionally stricter than normal wardrobe removal.

If a restraint is tracked:

- plain prose will usually not auto-remove it
- the node assumes it persists until you explicitly say something like `wardrobe: Maya -= handcuffs`

That is because a restraint is treated more like a plot state than casual clothing.

### `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`
- beat-level `seconds:` or `duration:`
- `megapixels`
- `vram_headroom_gb`
- `allow_res_backoff`

### The Short Version

`shot_seconds` is the socket-defined maximum.

A beat-level `seconds:` line wins for that beat.

If a requested length is too much for the hardware, the node keeps it and lets the render fail instead of quietly shrinking it.

### 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, estimate the beat length from its content.
3. Snap the result to H3's frame grid.

### `shot_seconds`

Global per-shot maximum.

Important:

- This does not mean every beat will be exactly this long.
- It means beats are sized against this socket value when the node needs a maximum.

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

### 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.

It is not silently shortened by the node. If you ask for more than your hardware can handle, the render can fail.

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

### If the shot length feels wrong

Check these in this order:

1. Check beat count first. One beat always means one shot.
2. Check whether the beat has `seconds:` or `duration:`.
3. Check whether global `shot_seconds` is lower than the beat request.
4. Check `plan_only` to see the actual planned frames/seconds.
5. If it is still shorter than requested, you are likely hitting the H3 frame cap or VRAM budget.

Simple rule:

- `seconds:` asks
- `shot_seconds` caps
- H3 and VRAM can cap again

If a beat genuinely needs much longer screen time, split it into multiple beats on purpose instead of trying to force one oversized shot.

## 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
- if the beat already has real refs, the previous frame is added like another soft reference rather than a hard start frame

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
- this is the least forceful continuity mode

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_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.

### Character Reference Node: what the fields actually do

`Dumas Character Reference` packages one image plus metadata into one `REFERENCE` socket.

What the long-videos code actually uses:

- `image`: the real reference image H3 sees when that slot is selected for a shot
- `name`, `character_id`, `alias`: used for character-name matching in beat text
- `description`: injected as persistent appearance text when that character ref is matched
- `wardrobe`: injected as persistent wardrobe text when matched, and also used to seed `character_memory` if the long-videos node field is blank
- `general`: injected as extra character notes when matched
- `gender`, `age`, `nationality`, `occupation`, `height`, `accent`: turned into one "Character facts" sentence when matched

What this means in practice:

- the image and the text metadata are separate channels
- a character image can still condition a shot even if its metadata was not injected into the beat text
- wardrobe from character refs is only promoted into live tracked wardrobe state when `character_memory` is empty

### When character data gets used

There are three different moments:

1. Shot ref routing chooses whether the character image is attached to that beat at all.
2. Text matching decides whether the character metadata is injected into that beat text.
3. Chain-state seeding decides whether the character ref wardrobe becomes the starting `character_memory`.

The important detail is that these do not always happen together.

Character image conditioning:

- happens according to `ref_mode`
- can be forced with `<Picture N>`
- can also be pulled in by naming the character in the beat

Character text metadata injection:

- happens only when the beat explicitly tags the slot with `<Picture N>`
- or when the beat mentions the character by `name`, `id`, or `alias`

Character wardrobe seeding:

- happens once at chain setup
- only if the long-videos `character_memory` field is blank
- only for character refs that actually contain wardrobe text

### Location Reference Node: what the fields actually do

`Dumas Location Reference` is simpler. It packages one environment image plus environment metadata into one `REFERENCE` socket.

What the long-videos code actually uses:

- `image`: the real location reference image H3 sees when that slot is selected for a shot
- `description`: injected as location context when that location ref is matched
- `general`: injected as location notes when that location ref is matched
- `name`, `location_id`, `alias`: used for location-name matching in beat text and as labels in injected sentences

Important difference from character refs:

- location refs can now be matched from location names or aliases in beat prose
- explicit `<Picture N>` tags are still the strongest way to force an exact slot on an exact beat

### When location data gets used

Location node data has two separate paths:

1. The location image can be attached to shots through normal ref routing.
2. The location text metadata is injected when the beat tags that slot with `<Picture N>` or names the location by `name`, `id`, or `alias`.

So location references are no longer tag-only, but tags are still the safest exact-routing tool.

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
- names can now pull matching location refs into the real image-conditioning list too
- location refs are still often tagged because they are about where the shot happens
- character refs are often named because they are about who is in the shot

### Scenarios

### Scenario: one hero character, no location ref

Setup:

- `ref_1` = Maya character reference
- beat text says `Maya crosses the road and looks back`
- `ref_mode = auto ref2v`

What happens:

- Maya's image is attached to the shot
- Maya's character metadata is injected because the beat names `Maya`
- if `character_memory` is blank, Maya's `wardrobe` field also seeds the live wardrobe tracker at chain start

### Scenario: two characters plus one tagged location

Setup:

- `ref_1` = Maya character reference
- `ref_2` = Jon character reference
- `ref_3` = warehouse location reference
- beat says `Maya argues with Jon near the loading bay <Picture 3>`

What happens:

- Maya and Jon can be matched by name, so their character metadata can be injected
- the warehouse location metadata is injected because `<Picture 3>` tags it
- the image refs used on the shot still depend on `ref_mode`

Why this pattern works well:

- character refs can be driven by names
- location refs usually need explicit tags when you want the environment text to be stated clearly

### Scenario: location image works, but location notes do not seem to

Setup:

- `ref_3` = cafe location reference
- beat says `They sit in the cafe window booth`
- no `<Picture 3>` tag

What happens:

- the word `cafe` can now match the location ref by name or alias
- that means the location image and location text context can both be pulled in even without a tag
- `<Picture 3>` is still better if you want exact manual slot routing on that specific beat

What to do:

- add `<Picture 3>` when you want to force that exact location slot on that exact beat

### Scenario: character face is partly right, but identity is weak

Setup:

- character refs are connected
- beat prose uses `she` and `he`, but never names the characters
- `character_memory` contains clothing and height-like facts

What happens:

- the beat can still pick up some tracked wardrobe/state language
- but the strongest character-ref match path is weaker because the beat is not naming the people
- that can produce "same role, wrong face" results

What to do:

- name the characters in the beat, or tag their slots explicitly
- keep `ref_noise_aug` high
- use `every shot` when identity matters more than soft continuity

### Scenario: character wardrobe from the ref node does not update later

Setup:

- character ref has wardrobe filled in
- long-videos `character_memory` is also filled in with different clothing

What happens:

- the long-videos `character_memory` wins as the live starting wardrobe state
- the wardrobe field inside the character ref is still usable as injected descriptive text when matched, but it does not replace the explicit `character_memory` sheet

What to do:

- put the canonical changing outfit in `character_memory`
- treat character-ref wardrobe as a fallback/default seed, not the main changing state source

### If faces drift or people turn into random lookalikes

Check these in this order:

1. Make sure each character has a proper character reference slot connected.
2. Make sure the beat names the character, or tags the slot explicitly with `<Picture N>`.
3. Use `plan_only` and inspect the ref placement summary.
4. Try `ref_mode = every shot` if identity is more important than fluid continuity.
5. Raise `ref_image_size` to `max` if the card can handle it.
6. Keep `ref_noise_aug` high if you want closer identity matching.

Important distinction:

- location refs can work even when character identity is drifting
- that usually means the scene reference is being used, but the character image refs are not being applied strongly enough or often enough

For multi-character scenes, naming matters a lot. The node can pull named character refs into the actual conditioning list, but only if it can match the beat text to the right character.

## 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: Latent Upscale

This is the optional latent refinement stage, used before decode.

The long-video node now expects a separate `Dumas H3 Latent Upscale Params` node for this stage.
Wire that node into the `latent_upscale_param` input when you want the shot to be upscaled and lightly
re-sampled before decode.

What this really means:

- the node renders the beat once
- the sampled latent is upscaled in latent space to the target size
- the conditioning is rebuilt at that target size
- the node then runs a short refinement pass over the upscaled latent with the sampler, scheduler, step count, denoise, and megapixel target you picked on the latent-upscale params node
- if the target is larger than the spatial tile size, that refinement pass is processed in spatial batches using the same tile defaults as the upstream latent-split node
- the spatial stitch mode follows the upstream overlap controls, including `linear`, `smoothstep`, `overwrite`, and `midpoint`

Good starting point:

- use the `model` mode when you want the strongest latent detail recovery
- use the interpolation mode when you want a cheaper resize-only path
- start with `euler_ancestral`, `simple`, `2` steps, and `0.2` denoise
- leave width and height at `0` unless you want an exact override; otherwise `megapixels` drives the target size
- leave the spatial tile inputs at their defaults first: `512x512` tiles, `64` overlap, `0` fade width, `earlier` overlap mode
- keep `linear` blend first unless you want to reproduce a specific upstream stitch style

The important part is that this stage is still a latent pass, not a pixel-space resize:

- it happens before decode
- it can change structure more than a normal image upscale
- it is the place to recover detail without adding another full detail-pass toggle

If you do not wire the helper node, the long-video node skips latent upscale entirely and renders as before.

## 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`

The node always moves completed shot data off the GPU and clears memory between beats.

This is hard-coded for long-chain stability.

### `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 a longer shot.
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
- put `seconds:` on a beat when you want a specific length

### 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 an OOM if you ask for more than H3 or your hardware 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.

## Troubleshooting Patterns

### If the chain feels too cut up

Try these first:

- use `continuity: keyframe carry` on beats that should feel like the same take
- use `continuity: handoff ref` when you still want continuity but do not want a strict hard-start frame
- avoid `hard cut` unless you want a real reset
- keep `vary_seed_per_shot` off if you want smoother chaining

Simple continuity reading:

- `hard cut` means start fresh
- `keyframe carry` means begin from the previous ending frame
- `handoff ref` means remind the next shot what the last frame looked like
- `soft carry` means carry only lightly, especially when refs are already in charge

### If wardrobe changes do not stick

Check these first:

1. Make sure the clothing lives in `character_memory` or `wardrobe:`, not only in the anchor paragraph.
2. For multi-character scenes, declare names and pronouns clearly.
3. Use explicit `wardrobe:` lines for adds and swaps.
4. Use named `wardrobe:` directives when two characters share similar clothing.

Good pattern:

```text
Maya = she, silver hair, grey shorts, red jacket
Jon = he, black jeans, work boots

Maya unzips the jacket and tosses it aside.
wardrobe: Maya -= jacket
```

That gives the prose action and the exact state change together.

### If you want to understand what the node is remembering between beats

The main persistent state buckets are:

- `anchor`: permanent scene/style text that is stamped on every shot
- `active wardrobe`: current per-person tracked clothing/items
- `departed`: characters who have left the scene
- `removed`: garments removed so they can also be scrubbed from anchor text
- `props`: important introduced objects that can be carried forward
- `stripped` and exposed-state markers: body-zone state after removals

The shot prompt is rebuilt every beat from those buckets. That is why a chain can keep wardrobe, props, exits, and continuity logic coherent across many beats when the state is written clearly.