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.

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:

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:

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

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

Single-person unnamed form also works:

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:

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:

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

Unnamed single-subject shorthand also works:

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:

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
• 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:

seconds: 8

or

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

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:

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

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

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:

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.