diff --git a/H3_LONG_VIDEOS_GUIDE.md b/H3_LONG_VIDEOS_GUIDE.md index f653dc7..b923c21 100644 --- a/H3_LONG_VIDEOS_GUIDE.md +++ b/H3_LONG_VIDEOS_GUIDE.md @@ -177,18 +177,189 @@ What this really means: - 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. @@ -339,6 +510,24 @@ 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. @@ -471,6 +660,7 @@ 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: @@ -491,6 +681,7 @@ 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: @@ -713,6 +904,24 @@ What to remember: - 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 +### 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 ``. +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. @@ -1072,3 +1281,55 @@ That is the quickest way to see: - 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.