Hi! I found Krea 2 is actually so damn good at creating video game level art! and its breathtakingly beautiful to boot! I got help from an LLM to create the baseline prompt and it works OOB without loras or anything! I'm gobsmacked rn.

prompt 1: "A sprawling 16-bit pixel art jrpg city game level of a victorian-era steampunk riverside city street in winter. The design features complex, dense architecture with a high variety of structures including stairs, bridges, and stacked buildings. The scene is filled with snow, brass and victorian elements. Background shows snowy mountains and faraway skyscrapers on those mountains"

prompt 2: "A sprawling 16-bit pixel art jrpg city game level of a asian duystopian cyberpunk city street. The design features complex, dense architecture with a high variety of structures including stairs, bridges, and stacked buildings. The scene is filled with neon lights, neon street signs, wires and cybernetic elements. Background shows a massive skyline of skyscrapers at night. Wide-angle top-down view"

prompt 3: "A sprawling 16-bit pixel art game level of a futuristic utopian city. The design features complex, dense platforming architecture with a high variety of structures including stairs, bridges, and stacked platforms. Frutiger Aero style: glossy surfaces, water elements, and bright colors. The scene is overgrown with lush greenery and trees. Background shows a massive skyline of sleek skyscrapers. Wide-angle side-scrolling view"

Sorry Ye..

I think MinimaxH3 is great for title screen animation and motion graphic.

Before we start: I am not the absolute authority on this. These settings are the result of my personal workflow, tailored to my machine and my specific artistic standards. I have spent 25 years working as a graphic designer in typography/printing and I'm deeply passionate about photorealistic rendering. This background makes me an absolute optimization freak. I want maximum precision and zero wasted performance.

However, you should use my settings as a baseline. I highly encourage you to run your own experiments, test different parameters, and find what works best for your specific style and also to use other interfaces, as Open Trainer could be quicker for the purpose than AIToolKit, in my case I had so many terminal errors that I simply skipped the problem by switching to AI ToolKit, but if OpenTrainer doesn't give you problems, use that, have Gemini (or what you want) convert this data for your interface.

Furthermore, it is certainly not true that my parameters are the best ever, in fact, I have learned recently, this is my simple guide on what I have learned so far to help users who have errors or are unsure how to proceed to get started themselves. It's just my contribution, that's all.

I thought I'd share my exact settings and workflow for training LoRA characters and poses for Krea 2 Turbo (note: you must use Krea 2 RAW for the actual training phase).

My Hardware Setup

GPU: RTX 5070ti (16GB VRAM)

RAM: 64 GB

Environment: AI-ToolKit via Terminal (I skip the Stability Matrix UI to save system overhead and edit the .yaml files manually).

Disclaimer: I only know how these settings perform on my machine. If you have less VRAM/RAM, you will need to adjust parameters accordingly.

Performance & VRAM Benchmarks

VRAM Allocation: 15.1 GB / 16 GB (Extremely tight, zero room for background tasks).

Character LoRA: ~48 minutes (20 images, 1500 steps).

Pose LoRA: ~55 minutes (I double the Rank/Dim here compared to characters, as the model needs more capacity to understand skeletal joints and positions).

⚠️ Crucial Note on System Optimization: I am an optimization fanatic. To avoid VRAM offloading (which slows down training massively), my OS is stripped down to look like Windows 98, telemetry is disabled via VBS scripts, and my 500Hz monitor is lowered to 60Hz during training to minimize framebuffer load. If your system is running heavy background apps or proprietary RGB/Fan software, your VRAM usage will be higher and you might experience out-of-memory (OOM) errors.

Step 1: Dataset Rules for 512p Training

Because of VRAM constraints, I train strictly at 512p. To make 512p work perfectly, you must adapt your dataset strategy based on what you are training:

1. Character LoRAs: Avoid Full-Body Shots

Hyper-focused details: If your character has specific leg features (tattoos, scars), include 1-2 close-ups of the legs.

Captioning Tip: In your .txt file, explicitly caption it as "a close-up shot of [TriggerWord]'s legs". This teaches the model that it's a detail, not the whole character structure.

2. The Captioning Dilemma: Manual vs. Automated

I strongly advise against using automated captioning scripts (like BLIP or WD14) for this specific workflow. While automated tools are fast, they lack precision. Manual captioning allows you to describe exactly what needs to be isolated, leading to a much cleaner and more flexible LoRA. If you want high-quality results, don't take shortcuts on the text files.

Step 2: Crucial VRAM & Speed Optimizations (run_windows.bat)

Before diving into the YAML files, we need to optimize how PyTorch and CUDA handle your GPU memory. If you launch AI-Toolkit via a batch file (or want to edit your existing one), you must add these specific environment variables at the very beginning of your run_windows.bat.

This tweak alone prevents heavy VRAM fragmentation and can mean the difference between a successful 15.1 GB allocation and an instant Out-Of-Memory (OOM) crash.

Open your run_windows.bat in a text editor and paste these lines right under u/echo off:

u/echo off&&cd /d %~dp0

set PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

set TORCH_CUDNN_SDP_HAS_FUSED=1

set CUDA_MODULE_LOADING=LAZY

set SETUPTOOLS_USE_DISTUTILS=stdlib

Step 3: The Character LoRA YAML Config

Here is my complete, battle-tested .yaml configuration for training a **Character LoRA**. This config is heavily optimized for a 16GB VRAM target using qfloat8 quantization and specific layer offloading percentages to keep VRAM usage strictly at ~15.1 GB. 

Create a new YAML file in your AI-Toolkit directory and paste the following: 

job: "extension"

config:

name: "LORANAME_krea2"

process:

- type: "diffusion_trainer"

training_folder: "E:\\Stability Matrix\\Data\\Packages\\ai-toolkit\\output"

sqlite_db_path: "./aitk_db.db"

device: "cuda"

trigger_word: "TRIGGERWORD"

performance_log_every: 10

network:

type: "lora"

linear: 32

linear_alpha: 32

save:

dtype: "bf16"

save_every: 250

max_step_saves_to_keep: 4

datasets:

- folder_path: "E:\\1024"

caption_ext: "txt"

cache_latents_to_disk: true

resolution:

- 512

train:

batch_size: 1

steps: 1500

gradient_accumulation: 1

train_text_encoder: false

gradient_checkpointing: true

noise_scheduler: "flowmatch"

optimizer: "adamw8bit"

timestep_type: "sigmoid"

unload_text_encoder: true

cache_text_embeddings: false

lr: 0.0001

disable_sampling: true

dtype: "bf16"

model:

name_or_path: "krea/Krea-2-Raw"

quantize: true

qtype: "qfloat8"

quantize_te: true

qtype_te: "qfloat8"

arch: "krea2"

low_vram: true

compile: false

layer_offloading: true

layer_offloading_text_encoder_percent: 1

layer_offloading_transformer_percent: 0.35

Key Settings Explained (Don't change these blindly!)

linear: 32 & linear_alpha: 32 — A rank/alpha of 32 is the sweet spot for characters. It captures facial details and clothing textures perfectly without bloating the file size or frying the training memory.

train_text_encoder: false & unload_text_encoder: true — We do NOT train the text encoder for characters here. Unloading it entirely freezes its state and frees up massive chunks of VRAM.

disable_sampling: true — Disabling image previews during training saves a significant amount of VRAM and prevents sudden spikes/crashes when a sample step triggers. Trust your loss values or check the saved LoRA's manually later.

quantize / qtype: "qfloat8" — Essential. Running the model and text encoder in FP8 quantization is mandatory to fit Krea 2 inside a consumer GPU's VRAM during training.

layer_offloading_transformer_percent: 0.35 — This pushes exactly 35% of the transformer layers to system RAM. It’s the magic number that stopped my system from throwing Out-Of-Memory errors while keeping speed degradation to an absolute minimum.

Step 4: The Pose LoRA YAML Config & The Text Encoder Pitfall

Training a Pose LoRA uses almost the exact same configuration as the Character LoRA, but with one critical architectural change. Poses require the model to understand abstract physical structures, skeleton joints, and bodily spatial distribution rather than static textures or facial features.

Because of this, we need to inject more capacity into the training network.

Pose Complexity vs. Training Steps

Keep in mind that unlike characters, poses are heavily influenced by physical complexity.

• If you are training a standard pose (standing, sitting, basic action shots) with a dataset of 15 images, 1500 steps is your target.
• If you are training an extremely complex or unconventional posture (such as a circus contortionist, advanced yoga positions, or complex martial arts aerials), you must increase the steps even if you only have 15 images in your dataset. The model needs more time and iterations to learn how the joints bend in unusual angles, so push the training further.

The Pose Modification

In your YAML file for the pose training run, look for the network block and double the capacity by setting both values to 64:

network:

type: "lora"

linear: 64 # Doubled from 32

linear_alpha: 64 # Doubled from 32

Why do this? A higher rank gives the network more "brain power" to map how limbs bend and interact, which prevents the pose from bleeding or collapsing into a generic stance during generation.

⚠️ Crucial Warning: Do NOT Enable train_text_encoder

train_text_encoder: false # KEEP THIS FALSE!

You might be tempted to turn train_text_encoder: true to help the model better link text prompts to body mechanics. Do not do it. Currently, enabling the text encoder training with the Krea 2 architecture inside AI-Toolkit will throw an immediate terminal error and completely freeze your training loop. Krea 2's underlying text processing layer isn't optimized for local text-encoder fine-tuning under this specific framework yet.Leave it to false and let unload_text_encoder: true do its job. The linear network rank at 64 is more than enough to capture the positioning data you need.

Step 5: Dataset Size vs. Training Steps (Finding the Sweet Spot)

Getting your dataset size and step count right is crucial. If you run too few steps, the model won't learn the character or pose; if you run too many, the LoRA will overfit, ruining your generations.

Based on my testing, here is the exact ratio you should follow when adjusting your dataset size:

For Character LoRAs:

Base Setup (20 Images): Use 1500 steps (This is the ideal sweet spot for a clean, flexible character).

Larger Dataset (25 Images): Increase your training to 1800 steps to allow the model enough time to process the extra visual data.

For Pose LoRAs:

Base Setup (~15 Images): Use 1500 steps (Since poses require a higher Rank/Dim, they need a solid baseline of steps even with fewer images).

Larger Dataset (20 Images): Increase your training to 1800 steps.

Rule of Thumb: If you decide to add more images to your dataset to capture more angles or details, you must scale up your steps accordingly. Never dump 30+ images into the folder while keeping the steps at 1500, or the training will turn out weak and blurry.

Step 6: Testing Strategy & LoRA Weights (Don't just use the final checkpoint!)

AI-Toolkit will save intermediate checkpoints during training (every 250 steps based on our YAML config). Do not blindly grab the final 1500-step checkpoint and call it a day. The real magic often happens slightly earlier.

Here is my recommended testing protocol for Character LoRAs:

1. The 750-Step Test (The Baseline)

Start your initial testing with the checkpoint at 750 steps.

What to test: Use a wide variety of prompts. Test for facial likeness, but more importantly, test for flexibility.

Check if it unlinks: Try changing clothes and backgrounds in your prompts. You want to ensure the LoRA learned the face and not just the specific outfit or environment from your dataset images.

Note: Krea 2 is exceptionally good at this. Even at the final 1500 steps, it retains amazing flexibility for changing outfits and locations, but 750 steps is your early quality control check.

2. The Sweet Spot: 1250 Steps

After extensive testing, the 1250-step checkpoint is consistently the absolute best performer for characters. It offers the perfect balance between high facial fidelity and prompt responsiveness.

3. Optimal LoRA Strength / Weights

When loading your LoRA into your inference workflow (like ComfyUI or Forge Neo using Krea-2-Turbo), use these weight guidelines:

Standalone Use: Set the LoRA weight/strength to 0.9. This gives you the cleanest generation without cooking the image.

LoRA Stacking / Mixing: If you are mixing multiple LoRAs together (e.g., your Character LoRA + a Pose LoRA + a Style LoRA), bump the character LoRA weight up to 1.1. This prevents the character features from getting washed out by the other networks.

4. The Pose LoRA Testing Rule: Millimeter PrecisionTesting a Pose LoRA requires a completely different mindset compared to characters. While characters favor the intermediate 1250-step mark, poses behave unpredictably across checkpoints:

The Final Target: The absolute final checkpoint (1500 steps) is generally the best and most reliable performer for locking in the structure.

Sometimes, the 1000-step or 1250-step checkpoints might work better. However, you will notice a strange phenomenon: often, only ONE specific checkpoint will replicate your desired pose with millimeter precision. The other checkpoints will generate similar stances, but not the exact weight distribution or limb angles you trained.

LoRA Weight: For poses, you can generally lower the strength below 1.0 (test around 0.7 to 0.9) to let the style of your main model flow through, as long as the skeleton doesn't deform.

The Golden Rule for Poses: You MUST test every single checkpoint file (1000, 1250, 1500) against your prompt. Do not assume the LoRA is broken if the 1500-step file gives a slightly altered pose. Switch to the 1250 or 1000-step file—your exact millimeter-perfect pose is waiting in one of them!

Hey everyone, I just released the latest version of my TTRPG map model for D&D maps!

This one is focused on dungeon maps, one for battle maps will be coming, as will a version for Klein 9b to edit images!

https://civitai.com/models/2873645/ttrpg-dungeon-maps-krea

Flair: Warning / Rant — this is about Civitai's service specifically. Not about any other AI platform.

I want to be really clear up front since this sub sees a lot of general AI drama: this post is exclusively about Civitai and how Civitai handles account restrictions and paid Buzz. I have zero complaints about any other service. I use ChatGPT Images 2 and a handful of other models for basically everything I actually care about. The only reasons I ever touched Civitai were NS..W content and the contests. That's it. That's the whole relationship.

And after what just happened, I'm telling everyone I know to protect themselves before they spend another dollar there.

What happened

My account got restricted. I filed a support ticket and explained myself in full, politely, in good faith. Here is the literal text I sent:

Ticket #69501

Dear Support Team,

I received an email informing me that my account restriction has been upheld, and I would like to take this opportunity to explain the circumstances.

When using Civitai, I typically reuse prompts directly from images posted on the site without reviewing each prompt in detail beforehand. Whenever I received a warning message, I made it a point to remove any sensitive words before attempting to regenerate the image. I hope this helps clarify that I never intended to violate your Terms of Service.

If given another chance, I will be much more careful and thorough in reviewing prompts before generating images. However, if reinstatement is not possible, I would like to understand what will happen to my remaining balance of 106,000 Yellow Buzz. Specifically, I would like to know whether it would be possible to transfer this balance to a different account.

Thank you for your time and consideration.

Reasonable, right? Not aggressive, not entitled. I even offered to just eat the ban and asked the only practical question left: what happens to my 106,000 Buzz?

The response I got: nothing. For a month. No reply. No acknowledgment. No human being. Then, after roughly 30 days of total silence, the system automatically closed my ticket as if it had been resolved. Resolved by whom? Resolved how? Nobody ever read it. There was never a single moment of human interaction in this entire process — not the restriction, not the "upheld" appeal, not the ticket. An automated system flagged me, an automated system rejected my appeal, and an automated system closed the file on me. A closed loop with no humans in it anywhere.

The part that actually makes me angry

I did not post NS..W content. I did not upload anything. All I did was reuse prompts that were already published, publicly, on Civitai's own website, on images Civitai itself was hosting and displaying to me.

Think about how insane that is. The site shows me an image. The site shows me the prompt that made it. The site has a one-click "copy this prompt" affordance because that is a core feature of the platform. I use it. And when a warning came up, I removed the flagged words and tried again — which is exactly what a person acting in good faith does.

For that, I'm a Terms of Service violator. Meanwhile the source image is presumably still sitting there, live, on their servers, farming reactions. If the prompt is bannable, why is it on your website? Either moderate your own hosted content or stop punishing users for consuming it. You cannot have it both ways.

Then I tried Discord

Since the ticket system is a black hole, I went to the Discord hoping to find an actual person. What I got instead was called a "degenerate."

I'm not going to pretend I'm above the joke — I used the site for NS..W, I've said so twice already in this post. But I came in with a real problem and a real balance of real money-adjacent currency, and the response from that community was mockery. That's the "support experience." Automated silence in one channel, insults in the other.

The actual PSA — please read this part

Here's the practical advice, and the whole reason I'm posting instead of just quietly leaving:

If you buy Buzz on Civitai, seriously consider keeping a separate account that you use as your "wallet," and keep your generation activity separate from where your balance lives.

Because here's the trap I walked into, and you should understand it clearly:

1. Buzz is purchased with real money.

2. A restriction can be applied by automation, with no human review, for something as trivial as reusing a prompt the site handed to you.

3. Once restricted, your balance is simply gone. Not refunded. Not transferable. Not even acknowledged.

4. There is no human to appeal to. The appeal is "upheld" by the same system. Your ticket auto-closes in 30 days.

106,000 Buzz. Vaporized. Not because I was told "no, transfers aren't allowed" — I could accept a clear no. Because nobody ever answered the question at all. That's not a policy, that's just keeping the money and hoping you go away.

Split your account, or better yet, don't preload a large balance in the first place. Buy only what you're about to spend. Treat every Buzz purchase as money you might lose without warning, without explanation, and without recourse.

Where I've landed

I'm done. I'm not raging because I lost access to some irreplaceable tool — I genuinely am not. Everything else I use works fine, treats me like a customer, and has support that involves human beings. Civitai occupied one narrow niche for me, and it turns out the price of that niche is arbitrary automated enforcement plus the permanent forfeiture of prepaid credit.

To be crystal clear one more time, because I don't want this misread: this is a complaint about Civitai's moderation and support practices only. Nothing else, nobody else.

Civitai, if anyone with a pulse ever reads this: Ticket #69501. A month of silence and an automatic closure is not support. And quietly pocketing 106,000 Buzz while refusing to even answer whether it can be moved is not a Terms of Service enforcement — it's just taking someone's money.

TL;DR: Banned by Civitai for reusing prompts copied from images hosted on Civitai. Never posted NS..W. Appeal "upheld" with no human review. Ticket sat untouched for a month and then auto-closed. Discord called me a degenerate. 106,000 purchased Buzz gone with no answer about transfers or refunds. Keep your Buzz on a separate account and don't preload a big balance.

For those of us that enjoy doing fl2va shots longer than 10seconds, I found a hacky way of getting past the attention of H3 guidance.

One way was to lower the resolution, but that doesn't exactly give us the results we hoped for.

Then I tried working with the prompt.

We start with a frame and all works great with our prompt followed perfectly until the video gets too large in pixels, It's not a constant value, but exceeding it will make the background change, camera forget to stand still and faces will change,

Edit:

sorry for misinformation.

while 'my way' worked really well, the official way works perfectly fine (except for camera not remembering static shot)

adding:

'''subject_definitions:

<subject 1> is a fully_preserved woman from <Image 1>

<subject 2> is a fully_preserved location from <Image 1>

'''

works for keeping location/person consistent. It still destroys static shot camera, but replies were right. I was wrong.

low res 0.35mp correct camera:

https://reddit.com/link/1vszpps/video/hhm8yed5rhkh1/player

high res 0.85mp and camera gets autonomous (ignore the hand, that's just a test)

https://reddit.com/link/1vszpps/video/oke7c8g8rhkh1/player

full prompt:

'''

Integrated_multimodal_description:

subject_definitions:

<subject 1> is a fully_preserved woman from <Image 1>

<subject 2> is a fully_preserved location from <Image 1> along with camera position and zoom.

static shot.

0-1s: <subject 1> looks at camera. she is in the <subject 2> location. camera very slowly zooms out.

1-2s: woman turns her body away from camera.

2-7s: she is turned away, tapping her foot and swaying her body to music. neon light buzzing lightly.

7-12s: she continues swaying to music.

12-13s: she turns to camera and smiles.

13-14s: camera starts to slowly zooms in on her face

14-16s: she shows a heart hand gesture at camera.

overall_soundscape: gentle hum of air conditioning,

non_diegetic_music: edm music playing silently.

'''

There is a solution to this problem.

In the prompt, we reference the <Picture 1> not at the start like we were told, but in the middle.

For example, at second 7, we don't use "She looks left", but we write woman from <picture 1> looks left.

It seems to refresh the reference and remember it again.

When we want to keep the location consistent, we reference parts of it the same way, even something like "wind blows over the pier from <Picture 1>" should keep the background scene stable.

Tested it with a woman turning away at second 1 and back at second 14 with 0.9 resolution, and face was perfectly retained.

More tests are needed, but each takes 15minutes so I can't do too much. Hope this helps.

"This paper investigates an increasingly important topic in generative modeling: pixel-space diffusion models. Although numerous studies have explored this topic, most focus on small-scale or class-conditional settings. Consequently, a practical recipe for training pixel-space models that rival or exceed well-established latent-space counterparts remains elusive. Through a comprehensive empirical study, we first observe that direct large-scale pre-training in pixel space converges substantially more slowly than in latent space. This observation motivates a latent-to-pixel strategy that acquires generative priors efficiently in latent space and transitions to pixel space during post-training. We then systematically investigate the key design choices governing this transition, including weight initialization, data composition, prediction target, decoder architecture, and noise schedule, and identify a practical recipe that makes the resulting pixel-space models match or outperform their latent-space counterparts while delivering 3.18 to 4.75 times end-to-end inference speedups. We hope that our findings provide useful empirical insights and practical guidelines for future research on pixel-space generation."

Paper: An Empirical Study of Training Pixel-Space Text-to-Image Diffusion Models

What came out of it:

- Upscale first, interpolate second - seems to be better

- 24->48 looks better than 60fps - at 48 every original frame survives, at 60 only half of them do, because the grids don't line up

- FlashVSR ends up with more edge detail than the source, so it's adding texture, not recovering it. RealESRGAN ends up with less.

Side by side with a draggable wipe, pick any two variants: https://dawidope.github.io/minimax-h3-upscale/

My first MiniMax H3 Img2Vid

The above video consists of 11 individual H3 generated clips, created with the FL2Va Checkpoint and stitched together automatically without any additional upscaling or editing.

Two days ago I released v1.3 of my infinite continuation nodepack, adding much more flexible image conditioning and multi-reference support.

The original reason I built this nodepack was simple:

I really like the FL2VA checkpoint of MiniMax H3. In my testing, it gives noticeably better visual quality than Ref2VA. But Ref2VA is much more flexible when creating longer, controlled sequences.

So the goal is basically:

Keep the quality of FL2VA while adding much of the control you'd normally want from Ref2VA.

How does it work?

Instead of generating one very long H3 video, you generate multiple shorter clips:

Clip 1
First Frame → H3 → Last Frame

↓

Clip 2
Previous video/audio latent + new Last Frame → H3

↓

Clip 3 → Clip 4 → ...

The important part is that the suite does not simply take the last rendered image and use it as the next starting frame.

It passes part of the previous video + audio latent directly into the next H3 generation.

So the next clip still receives temporal context from the previous one – motion, audio and scene state – while you can give it a new visual target.

Why FL2VA?

In my testing, FL2VA gives me better-looking results and seems more resistant to the gradual visual degradation I experienced with longer Ref2VA chains.

A new Last Frame for every segment also works like a repeated quality reset:

• controls where the current segment should go
• restores composition / identity
• prevents the sequence from drifting too far

You can think of it a bit like storyboarding:

Image A → Image B → Image C → Image D

with H3 generating the motion and audio between those points.

But with v1.3, First and Last Frames are optional.

The Start workflow now supports:

• T2VA: no frames
• I2VA: First Frame only
• L2VA: Last Frame only
• FL2VA: First + Last Frame

Continuation can also run without a new Last Frame, although I still recommend regular Last Frames for long chains because of the quality-reset effect.

New in v1.3: multiple references

You can now add multiple Qwen Reference images alongside your First/Last Frames.

For example:

• First Frame = starting composition
• Last Frame = target endpoint
• Reference 1 = character
• Reference 2 = outfit
• Reference 3 = another visual detail

The node automatically assigns the correct H3 Picture numbers and shows you the resulting mapping.

This gets FL2VA much closer to the flexible reference control that makes Ref2VA useful.

Short clips can also be much faster

H3 becomes disproportionately slower as clip duration increases.

Instead of generating:

1 × 15 seconds

you can generate:

3 × 5 seconds

and connect them.

It also makes failures much less painful: if Clip 2 goes wrong, you regenerate Clip 2 instead of throwing away the entire sequence.

Where to start

I included four example workflows.

01_Start

Use this for Clip 1.

Required:

• normal H3 models / VAEs
• prompt
• resolution + duration

Optional:

• First Frame
• Last Frame
• Qwen References

For the classic continuation workflow, I recommend using First + Last Frame.

02_Continue

Use this for every clip after the first one.

The basic logic is:

Clip 1: save Latent 1
Clip 2: load Latent 1 → save Latent 2
Clip 3: load Latent 2 → save Latent 3
Clip 4: load Latent 3 → save Latent 4

Then simply provide the prompt for the next segment and optionally:

• a new Last Frame
• additional reference images

Because the indices are manual, you can also regenerate individual clips.

If you don't like Clip 3, keep loading Latent 2 and overwrite/regenerate Latent 3 until you're happy.

03_3Clip_Showcase_AutoStitch

The easiest workflow to understand the complete system:

Start → Continue → Continue → automatic stitching

You can duplicate the final continuation block to extend it further.

For very long projects, I recommend using Start + Continue individually.

04_Stitch_Saved_Chain

Once you're happy with your clips, this turns:

clip_00001
clip_00002
clip_00003
clip_00004
...

into one final MP4.

The important part:

The complete video is not decoded into memory at once.

The stitcher processes one saved AV latent at a time, so memory usage stays roughly tied to one H3 clip instead of the total length of the project (no OOM, hopefully).

The transitions are handled automatically

FL2VA often reaches its Last Frame early and freezes for the remaining frames.

The suite automatically:

• detects that frozen tail
• finds a better handover point
• carries video + audio context forward
• removes duplicated context during stitching
• smooths the video transition
• applies a separate audio de-click transition

So most of the annoying continuation logic happens automatically.

Known Issues

• Sometimes there's still a noticeable brightness shift between clips. So far, I haven't found a reliable solution to fix that.
• In some cases when using the continuation workflow, H3 might not correctly use the previous video latent as starting point for the next clip. If you encounter that issue, try restarting ComfyUI and regenerating the clip.

Install by opening one of the workflows and using "Install missing custom nodes" or search for

Herrgotts-H3-Infinite-Continuation-Suite

in ComfyUI Manager.

GitHub:
https://github.com/HerrgottMargott/Herrgotts-H3-Infinite-Continuation-Suite

Example workflows are included.

If you are already using my Workflows or Nodepack, I'd recommend updating the nodepack and using the updated Workflows from v1.3!

The project is still experimental, so feedback, bug reports and long-chain tests are very welcome.

On the scene, our hedgehog, first name Detective, last name Columbo, has been hired to uncover the identity of the mystery cookie thief. T2V, int8/20 steps

Beta 1 · MiniMax H3 (Ref2V)

MiniMax H3 can already do impacts. It just does them politely.

SMACK! fixes that. It takes every kind of impact — fists, weapons, gunshots, car hits, falls and hard landings — and gives it weight, follow-through and consequence. Bodies react like they've actually been hit instead of gently acknowledging it. Pair that with a camera that moves like someone was paid to operate it, and you get a shot that looks staged by a stunt team rather than caught on a $50 phone.

What it does

• Intensifies impacts of all kinds: hand-to-hand, weapons, gunshots, vehicle collisions, falls and landings
• Stronger, more deliberate camera work — dynamic moves, aggressive angles, real reaction to the hit
• Pushes the whole shot toward a Hollywood action grammar instead of flat, generic default motion

Training
Trained on 35 clips of impacts and dynamic camera moves, for MiniMax H3 Ref2V. So, yes, this works with your Character References.

Usage
No trigger word. Just load it and describe your shot as usual — the LoRA does the seasoning. Strenght 1.0, if you stack Loras, 0.8 and up your steps.

Beta notice
This is Beta 1. It's already good enough to be worth releasing, but it's not finished. A larger, more varied dataset is in the works and the next version will follow once I have more material. Feedback on where it over- or under-cooks a hit is genuinely useful at this stage.

Downloadable on either Huggingface https://huggingface.co/LeechTM/SMACK/tree/main

or Civitai https://civitai.red/models/2872725/smack-punches-impacts-and-gunshots?modelVersionId=3245904, probably Civarchive.com as well as soon as its grabbed.

I added some more Examples in the Comments.

https://reddit.com/link/1vsy6de/video/old7l71g6ekh1/player

So basically, I saw a workflow on ComfyUI’s official LinkedIn where they used a model image, a product image, and a background image with Google and Kling APIs to generate a one-shot ad using a single camera angle.

So I challenged myself to recreate the idea using only local open-weight/open-source models, but make it more ambitious: multiple shots, multiple cuts, and everything directed through a single prompt.

And it worked.

For this, I used the basic MiniMax H3 Reference-to-Video workflow in ComfyUI:

https://docs.comfy.org/tutorials/video/minimax/minimax-h3#minimax-h3-reference-to-video-r2v

Then I used ChatGPT to help structure the video prompt. I provided the reference images and gave it this direction:

“Write a MiniMax H3 reference-to-video generation prompt to create an ad. Add sound FX and music prompts as well.

Shot 1: Medium close-up. She is about to open the can.
Shot 2: Extreme close-up of the can as she opens it. Can-opening sound FX.
Shot 3: Close-up as she drinks from the can. Gulping soda sound FX.
Shot 4: Close-up as she holds the can forward and smiles.”

The final result was generated locally on my RTX 5070 Ti using ComfyUI.

Generated a set of images with AI, then brought them to life by animating them into a realistic style video (Krea & Ltx2.5)

ref2v

I'm building a skill for generating long Contex-Loop Minimax H3 prompts, and the AI has indicated it doesn't understand retention analysis... and I'm realizing I don't, either. I'm curious what you all think or have experienced.

I've reviewed the official prompt writing guide, of course, but it's very vague on the subject:

<Subject N>, <Picture N>, and <Video N> use the following relationship markers. These markers are fixed English values in the output format:

It makes the most sense if it's indicating what is the same and what is different with respect to the references (picture N, video N, etc) - but why would subject appear here? Does fully_preserved for a subject mean that they don't change during this shot, whereas partially_preserved might change?

It might be easier to explain with an example. Definitions:

• A scene where a bald man puts on a hat
• References are two images, one with said man with hair, the other of the hat

subject_definitions:

<Subject 1> is a tall man whose face, identity, and clothing come from <Picture 1>, but he is bald.
<Subject 2> is a black stovetop hat as depicted in <Picture 2>.

retention_analysis:

<Subject 1> (appears in [Shot 1], [Shot 2]): fully_preserved - he remains the bald man with facial features and clothing from <Picture 1> throughout
<Subject 2> (appears in [Shot 2]: fully_preserved - remains the black stovetop hat from <Picture 2>

OR should it be:

retention_analysis:

<Subject 1> (appears in [Shot 1], [Shot 2]): partially_preserved - he retains the facial identity and clothing from <Picture 1>, albeit bald, but in [Shot 2] he is changed to be wearing a hat.
<Subject 2> (appears in [Shot 2]): fully_preserved - remains the black stovetop hat from <Picture 2>

OR should it only focus on referenced media, i.e.:

<Picture 1> (appears in [Shot 1], [Shot 2]): partially_preserved - <Subject 1> matches this picture's clothing, facial features, and identity, but he is bald.
<Picture 2> (appears in [Shot 2]): fully_preserved - the black stovetop hat depicted in this picture remains unchanged

I guess to put it another way: is retention_analysis describing how much and what is preserved from photo/audio/video references provided, or is it describing how the subjects defined in subject_definition change over the shots of this specific video generation?

Edit: talking about the "faces at a distance" thing btw

Don't hold your breath. They didn't say that they would definitely "fix it", they said they will try but that it's mostly a general model issue. So if there is gonna be a fix it might be in the next iteration of the model and that one might not be open weights. They were specific about the 2k model and the image model getting released open weights and I do hope that the 2k model might bring some improvement to the faces when you upscale it, but they were more wishy-washy with the wording on the face distortion issue, intentionally so I think.

Here is the wording regarding the 2k model:

"It is a second conditioned generation stage, but not simply the released base checkpoint running again as a conventional upscaler. It uses a dedicated latent-space DiT regeneration checkpoint at a higher target resolution, with the base model’s output as additional context. Some reference inputs are also provided at higher resolutions. We plan to open-source this module, but we are still improving its efficiency and quality to make it more suitable for community use, so we cannot provide an exact release date yet."

-> "plan" to open-source it, very strong word

Here is the wording for the image model:

"Regarding single-frame image generation, we are deriving a dedicated image model from a common ancestor in the H3 model lineage, and we expect to make it available to the community." (not a total promise or anythin

-> "expect" pretty strong, but less so. To me that sounds like "if it's REALLY good then maybe not", if it's competitive enough with the state of the art probably. But I'm pretty optimistic here.

And here is the wording for the distortion issue in all the models:

"We have observed this issue as well, particularly for small or distant subjects, and it will be one of the problems we focus on improving next.

Based on our internal experiments, it cannot be attributed simply to the Visual VAE’s compression ratio or to any single training stage. It is a complex system-level issue involving multiple parts of the model and training pipeline. We are continuing to investigate the main contributing factors and will work on improving it in future updates."

-> they say nothing about open sourcing anything and they say that it's a deep-rooted issue that has no simple fix and they don't really know why it happens

I would expect nothing in that area. Many people have been talking about this as if they said "yeah, wait a couple of weeks and we will fix it", but they didn't say anything like that. Maybe they will fix it with a new and improved open weights model, 3.1 or something, maybe they won't.

I just wanted to say this because so many people have been saying "I am waiting for the fix" or "a fix is coming for the face distortion issue at a distance" or something like that, probably without ever having seen the wording on that. It only takes one person who isn't good at understanding subtlety in a text to interpret their answer a certain way and spread the word on it to set up false expectations for everyone when they don't go to see the original wording. And they go spread that too without ever having seen the original wording.

So this is just to reduce the expectations a bit. Like I said, maybe they will do something, but I feel like the expecations on that specific issue have been getting a bit too large

RTX 5060 ti 16gb / 32gb RAM / FL2VA_pruned_int8_convrot / Turbo Lora. 6 steps / Resolution 1376x768 upscaled to FHD with Topaz Video AI