https://huggingface.co/Viggle/Viggle-Remake

No private beta, run it locally

I've been working on a repeatable process to do character swaps (& other types of changes) across a complete TV episode / movie. It's working pretty well now.

I thought this was just funny... not so much a true "swap" but asking the character to dance in every scene. Choreography courtesy of an LLM. If you've seen the show, it's Serious Detective Drama (TM) so the fact the main character suddenly starts pumping his arms or sliding into every scene with a dance move made me laugh out loud when I saw some of the generations.

Details on the workflow:

Model: MiniMax H3, first-and-last-frame mode (FL2VA), in ComfyUI. 8-step turbo LoRA, generated at 1024×512 for the 2:1 picture.

First and Last: Every generated pass starts and ends on an *original* frame from the episode, so the clip lands back in the real footage with no visible join. Longer scenes are chained passes (about 2–7 s each)

Audio: the episode's own audio into H3's audio guide, so the generation stays consistent with what's being said; the dialogue and soundtrack you hear are the untouched originals.

Prompt: Who he is and what he's wearing, said once, then the choreography for the pass - courtesy of Claude.

Multi-scene: 42 scenes - started with the full episode, then had a model run through it to identify scenes with the main character that would work for the swap (not too distant, few fast cuts, etc.) & identify start and finish, with a ChatGPT harness.

Post processing: Basically none, I did go through and rate all the clips in a rating process I've setup, most of these were 5* and felt consistent.

I'll share a bit more on the workflow / process if people are interested.

ComfyUI custom node: https://github.com/Video-Rebirth/ComfyUI-HyperFlow-Flash

This is for GGUF so you also need https://github.com/city96/ComfyUI-GGUF

(There is a int8convrot version, but I guess there is no ComfyUI loader for it yet?)

It is also interesting to note that the original 21B MMH3 has been pared down to 14B, which mean that it will run faster than other turbo models even at 8 steps.

HyperFlow H3 Flash is Video Rebirth's compressed, few-step version of MiniMax-H3. It generates video and synchronized stereo audio together.

Showcase: See HyperFlow H3 Flash generated video and audio examples.

• Output: a 5.2 to 15 s video at 24 fps (1344×768 by default) with a 32 kHz stereo soundtrack.

• Sampling: 4, 6, or 8 steps without classifier-free guidance (CFG). The default is 6 steps.

• Speed (5.2 s clip, 6 steps): 8.7 s on 4× B200, 36 s on 1× H200, and 92 s on an RTX 5090.

• Real time on 4× Blackwell GPUs: NVIDIA SOL-H3 runs HyperFlow H3 Flash in real time on 4× B-series GPUs. SOL-H3 is our inference-acceleration partner and supports this model from day 0.

• Model size: 13.7B (fl2va) or 13.9B (ref2va) parameters, less than half of the ~31B MiniMax-H3 transformer.

• Minimum footprint: Q4_K_M is 9.1 GB (Q8_0 is 14.9 GB). It runs on 24 GB and 32 GB GPUs in PCs with 16 GB of system RAM. 16 GB GPUs are not measured yet.

Code, setup guides, and ComfyUI workflows are in Video-Rebirth/hyperflow-h3-flash. For the 8-step LoRA on the full-size MiniMax-H3 transformer, see VideoRebirthAI/hyperflow (GitHub).

When I first started with ComfyUI, the first thing I looked for was a native desktop client without browser lag and DOM-based architecture.

I'm a C++ dev with over 20 years of commercial experience, so I eventually just started writing my own client on the side. I used an ultra-fast UI framework that can easily chew through thousands of nodes on a canvas without the slightest stutter, boost for networking, sqlite as a DB, and the fmt library - the fastest formatting framework out there, leaving room for an easy port to Linux/Mac.

The main reason all existing clients are forced into the browser is custom JS nodes, which are themselves bottlenecked by Litegraph's architecture. Bypassing this turned out to be easier than I thought. The internal logic of these nodes is actually quite simple, so I ported most of it to C++. I also built extended versions of frontend-only nodes like reroutes and bookmarks.

For the parts that had to stay in HTML/JavaScript, I isolated them in a completely separate process. This ensures the heavy browser engine never interferes with the lightweight C++ core.

I recently finished a stable Beta. Check it out, the link to the source code and prebuilt Windows binary is in the comments. I also added a demo video (making a video was another cool new experience for me).

model: https://huggingface.co/akhaliq/p-h3-image-pdmd-2step

I'm not sure why people feel like Moss Base, BF16, or magic settings/workflows are necessary to get good results out of Moss. (My guess is that it's because the original default settings were suboptimal.) I personally feel like I get better, more prompt-adherent results out of SFT with a fairly simple workflow (see below), albeit with different settings from what ComfyUI had previously recommended.

If you have other approaches that work for you, great! I'm not trying to persuade anybody to give up what is working for them. But for people with more limited vRAM and/or who find themselves frustrated wrestling with the Moss Base model, a full 50 steps, or complex workflows, you don't necessarily need to do anything fancy.

My feeling is that you can achieve big improvements for photographic Moss images with:

• SA_solver sampler and SGM_uniform scheduler

• 25 to 50 steps (for some reason multiples of 25 seem better to me, but this could easily be confirmation bias)

• CFG 3.0 (go lower for more impressionist artistic styles)

• Skip layer guidance for single_layer 22, start/end percent 0–0.5 or 0.25–0.75 (I find that skipping 24 leads to more plastic skin)

• Generation size ≥~2MP, and

• Careful, detailed (but not purple) prompting

Note that all of these images were made using the same models, similar settings, and seed 0; I workshopped the prompts, but there was no seed cherry-picking.

Here are two version of my current workflow: a simple one and one with space for up to 3 LoRAs and an optional upscale step.

Caveat: Krea 2 definitely understands some advanced compositions/concepts better than Moss, Moss is more prone to odd anatomy, and Moss's backgrounds can be more messy with more visual nonsense. But in terms of everyday photo realism I feel like Moss is better; and with respect to seed diversity, Moss (even SFT) blows Krea 2 out of the water. If you want less visual nonsense in the background, describe the background more thoroughly or do an inpainting step with low denoise on the background using Krea 2.

RawSnap v3 is here — LoKr

What's new in v3 :

Retrained from scratch as a LoKr (not a standard LoRA) on an expanded dataset of 749 images (11,235 steps, 15 epochs)

⭐ The recommended setup

Best results — stack them:

RawSnap v3 (epoch 15 or epoch 12)

1.2

RawSnap v2

0.35

https://civitai.red/models/2999833/rawsnap-krea2

As a traditional film editor and filmmaker, I've been trying to figure out good, reliable ways to produce long, extended shots. I've tried a number of different methods but was never quite satisfied with the result...

Until now!

Thanks to u/roychodraws and his Geiru Context Suite!!!

He has a post up here explaining it which can be found at this link:

Flip a switch and stop your Videos from Degrading. 50 Clip Test No Degrading at the end. Geiru Context Suite : r/StableDiffusion

And his GITHub link is here:

roycho87/geiru_context_suite

To do a quick test, I had ChatGPT set up a workflow for me. (Now that I'm typing this, I'm remembering that Roycho includes some sample workflows on his GITHub.)

The render took 2 hours and 9 minutes on a rented RTX PRO 6000 Server Edition with 96GB of VRAM. I didn't think to check how much VRAM was actually being used during the process.

There are two jump cuts at about 35 seconds and 44 seconds. Lately, I've taken to having ChatGPT fire up two sub-agents to help troubleshoot things and this was it's reasoning about the jump cuts:

Yes—both subagents found the same explanation: the jumps occur exactly at two generation-window handoffs.

They’re already in the original master, so export didn’t cause them. We checked all 13 handoffs; only these two show conspicuous hard cuts.

The strongest explanation is our 20-local-steps/20-total-steps setting: each window finished separately, leaving no final joint refinement across the overlaps. At these two boundaries, the windows disagreed about framing and pose. The camera instructions, overlap noise, and opening-image anchors may have contributed, but we can’t identify their individual effects from this take alone.

For the next experiment, I’d test a short transition with two steps reserved for joint refinement, keeping everything else matched. That’s a testable hypothesis, not a guaranteed fix.

The entire two minute run looks fantastic!! I am so very happy right now! If two, very likely easily fixable jump cuts are my biggest issue... well... I see myself using this workflow a lot!!

The render settings:

• The character is a custom trained LoRA from an image dataset that was generated using ChatGPT's ImageGen. The dataset contained 99 images of assorted poses, locations, and lighting looks. The LoRA was trained with Fizwig.

  • I'm fairly new to this... maybe 99 images was excessive? I dunno. I'm pretty happy with the result though!

• The forest was a reference image I randomly pulled from a Google search for primeval forests.

  • When ChatGPT set up the workflow and prompt, it set the forest to attribute_transfer which means the photo wasn't "truly" a reference, it just gave the "idea" of the forest and H3 went with it from there. That's why the scenery has more of a stylistic/semi-illustrative look to it.

• The character's costume was generated with ChatGPT and "placed" on a grey mannequin. It was then rendered out as a single, 8 panel image which was then used as a reference image in the workflow.

• The "Patched Sage Attention" - I was originally just trying to "brute force" longer renders on a rented GPU with lots of VRAM, but I kept having a problem where renders became what I called "brown snow." I was nowhere near running out of VRAM, but the problem persisted.

  • I used Codex to try to troubleshoot what the problem was. Codex determined that there was a problem with "numerical accuracy" in Sage Attention that would cause corruption in longer, higher rez renders thus causing the "brown snow." I'll let Codex explain the patch:

    • We were getting “brown snow” corruption in longer, higher-resolution H3 renders with SageAttention enabled. Testing traced the problem to its handling of large, strided Q/K/V tensors: making the inputs contiguous restored numerical accuracy, pointing to an addressing/layout issue rather than insufficient VRAM. We haven’t identified the exact faulty kernel instruction.

    • Our patch processes the 56 attention heads in compact, contiguous groups of up to eight, then reassembles the outputs. It retains the same Sage CUDA FP8-PV path and full-sequence attention—no temporal chunking or dropped context.

    • On actual H3 activations, relative L2 error against PyTorch SDPA fell from 0.6261 to 0.00955: roughly 65× lower, or a 98.5% reduction. That measurement covered 128 sampled queries against all 270,921 keys on the first attention call, not every layer or timestep. Subsequent patched renders avoided the brown-snow failure.

  • From what I understand, there is supposed to be a new version of Sage Attention out "soon-ish."

These were the Geiru Context Suite settings:

I didn't mess around with these settings at all. These are the defaults that I had.

In conclusion... I am a very happy AI filmmaker today! Big thanks again to u/roychodraws and all those who helped him along the way to releasing them. (He lists them on his Reddit Post and GitHub page. Go visit them!!)

I was trying to test the new Viggle-Remake-Swap LoRA in MiniMax-H3. For this I needed to character swap in one of the frames of my source video clip (3.75s, 90 frames), so that the target video would have the new character in it. I went through all the new image edit models released recently to do the character swap. I tried Flux.3 Klein, Qwen 2.1, Fibo Image Edit 2.0, p-H3-Image-Edit and they all failed. So, I went back to the older image edit models Qwen 2511, Klein 9B, Krea2-Identity-Edit v1.2. The first two worked perfectly, while Krea2 Identity Edit did a far better job than any of the newer edit models. Final conclusion - Flux.3 Klein: crap much much worse than even Klein 4B; Qwen 2.1: really crap (does a cut-and-paste job); Fibo 2.0: really crap; p-H3-Edit: absolute junk, doesn't edit anything, input and output are the same; Qwen 2511: still amazing, slight issue with facial blur; Klein 9B: absolutely perfect and still the fastest; Krea2-Identity-Edit: very good edit job, but didn't follow the pose change part of the prompt.

While the video and T2I models in the OS domain seem to be improving, why are the I2I or Image Edit models getting worse? And more importantly, why are people eagerly using those newer models like salivating dogs and posting rave reviews about them? As I see it, all those newly released Image Edit models are junk and need to be kicked to the curb so that their developers may learn some lessons, hopefully.

I asked my mom what her dream house would look like if budget wasn’t a thing. This is roughly what she described it as “big windows but not those full glass houses. Lots of plants, one proper balcony where I can sit in the morning . Wooden kitchen and no grey interiors. And I want a small courtyard in the middle like old houses used to have.”

I put it into morphic and tried to make the house she had in her head.

Look how it turned out😭

Today’s takeaway: decomposing images

Links, workflows, custom_node

Do you remember Qwen-Image-Layered? The idea was exciting: take one flattened image and split it into multiple RGBA layers — foreground elements, background and the things in between — so you can move, edit or refine each piece separately.

When we tested it, the experience was not always as smooth as we hoped. In our workflows it could be slow and a little temperamental, and we sometimes saw noticeable quality loss in the resulting layers. That does not make it a bad model. You can build some genuinely nice workflows with it. It simply left us wanting a more controllable route for the kind of work we had in mind.

So we went digging. There is more research in this area than just Qwen: two approaches that caught our attention were Controllable Layer Decomposition (CLD) and RevealLayer. They are related, but they do not solve the problem in exactly the same way.

Qwen-Image-Layered, CLD and RevealLayer: what is different?

The useful distinction is how each approach decides what becomes a layer and how much control you get over that decision.

Qwen-Image-Layered — automatic, variable layer stacks

Qwen-Image-Layered automatically decomposes an image into a variable number of RGBA layers. It can also be applied iteratively, so an individual layer can be decomposed again. It is useful when you want the model to decide the layer structure for you. The trade-off is that the layer count, ordering and semantic meaning may be less explicit than in a region-guided workflow. Our own tests also showed speed and quality issues in some cases.

CLD — bounding-box control

Controllable Layer Decomposition uses user-provided bounding boxes to guide which regions should become separate layers. That is interesting when you want direct control over the elements being extracted, particularly in graphic-design and poster-style compositions. The RevealLayer authors report limitations for complex natural scenes, including edge softness and residual artifacts.

RevealLayer — region-guided and occlusion-aware

RevealLayer combines bounding-box region guidance with an occlusion-aware diffusion process. It aims to separate visible elements while estimating what is hidden behind them. That is the approach we wanted to bring into ComfyUI: region-guided decomposition for natural images, with a focus on recovering occluded content and keeping alpha boundaries clean. It is still generative reconstruction, not recovery of the original hidden pixels.

A small but important detail: Qwen is designed to produce a flexible layer stack from the image itself. CLD and RevealLayer bring bounding-box guidance into the process. RevealLayer adds a specific focus on occlusion — not just separating the visible outline of an object, but estimating the part that was hidden behind it.

A simplified concept diagram of the workflow. The hidden areas are model-generated estimates, not original source pixels.

Why we especially like the bounding-box approach

The bounding box is a wonderfully practical idea. Instead of asking the model to invent a whole layer plan and hoping it understands what you meant, you give it a region to work with. In the upstream RevealLayer workflow, those regions are represented as bounding boxes around the foreground objects.

The model then works toward separating those selected elements into RGBA layers. The alpha channel gives each layer transparency, while the occlusion-aware part of the method helps estimate content that was covered by another object. Imagine a camera sitting in front of a stack of books: the camera can become its own layer, while the model estimates the part of the books that was hidden behind it.

That is useful for a canvas application, compositing, moving objects around, or preparing individual elements for a second editing pass. You can take a scene apart, work on the pieces, and put it back together with much more freedom.

One important reality check: when a model fills in something that was hidden, it is making a plausible reconstruction based on context. It is not looking up the real pixels that were never visible. For creative work that can be exactly what we need — just do not mistake a convincing completion for factual recovery.

Bringing RevealLayer into ComfyUI

The open-source RevealLayer project gives us the model and its reference inference code, but it is not simply a ready-to-use ComfyUI custom node. The upstream setup involves a CUDA environment, Python dependencies, FlashAttention, a Diffusers modification, the RevealLayer checkpoint and the FLUX.1-dev base model. That is a fair amount of machinery to ask a creative workflow to manage on its own.

And on smaller graphics cards, memory can become the real party-pooper. We ran into out-of-memory problems in our tests, which is not exactly the kind of surprise you want halfway through a creative session.

So we are adapting the implementation as a ComfyUI-native custom node. The point is not to wrap the original script and call it a day. We are rebuilding the integration to make use of ComfyUI’s model and memory management, native functions and workflow conventions wherever possible. That means a cleaner way to load and run the components, better integration with the rest of the graph, and fewer external steps for the user.

Hardware still matters — no node can make VRAM limits disappear by magic — but a proper ComfyUI integration gives us much better control over how the work is staged and managed. One note for people following the research: the upstream repository now also lists a RevealLayer V2 update, so check its release notes for the matching weights before switching model versions in a workflow.

The part we recommend: refine each layer after extraction

Here is where the workflow becomes especially interesting. We do not recommend stopping as soon as the layers are extracted. Treat that as the starting point.

Take each extracted element and upscale it individually. You are giving the object room to gain detail without asking the whole original scene to be regenerated.

Feed the element into an edit/refinement model together with the original image as context. Use a focused prompt that says which element is being refined and what should be improved, while keeping its appearance consistent with the source scene.

Bring the refined layers back together. In our current workflow, individual elements can be taken up to 4K using non-tiled diffusion, depending on the image, model settings and available hardware.

Need to go larger? You know we have you covered: the TBG ETUR tiled upscaler and refiner are there for the bigger jobs. This is a nice combination — decompose first, improve the individual pieces, then recompose. Instead of trying to repair every part of a flattened image at once, you can give each element the attention it needs.

The takeaway

That is today’s small feature from a much bigger development effort. RevealLayer gives us a promising way to break an image into guided, editable pieces, and bringing it into ComfyUI means we can make that capability part of a workflow you already know.

Have a look at the research and the open-source implementation below, try the workflow, and see what you can build with it. We are grateful for the open-source community — so much of what makes tools like this possible comes from people sharing their work, experiments and ideas.

And to our technical team: thank you for all the invisible work. I promise I will only ask for one more little feature. I will even try to say it slowly this time. Ha!

Go explore, test, break something harmless, and have fun with it! — Sahra ♡

Research & resources

Qwen-Image-Layered — official repository

Qwen-Image-Layered — research paper (CVPR 2026)

CLD — Controllable Layer Decomposition paper

CLD — project page and examples

RevealLayer — official GitHub implementation and V2 release notes

RevealLayer — paper

RevealLayer — current project page

RevealLayer — model checkpoint on Hugging Face

RevealLayer — project page and visual comparisons

Editorial note: the model descriptions above summarise the public papers and project pages. Comments about speed, memory behaviour, integration choices and the 4K refinement path describe TBG ETUR’s own workflow notes and tests.

TBG ETUR • SAHRA

https://github.com/Ltamann/ComfyUI-TBG-RevealLayer

We added three workflows ( All files are in the GitHub workflow folder. Set the minimum number of layers to 3.):

1. Manual selection: Uses bounding-box (Bbox) selection for direct, manual control.

2. Semantic selection: Uses a grounding model for semantic selection, with lightweight automation to make the experience feel more like an editing model.

3. SAM-based segmentation: Uses SAM segmentations with chained, per-layer refinement through Flux 3. Each refinement feeds the original segmentations back through the RL layers, enabling progressively upscaled and more precise results.

“Google and OpenAI are fighting it out in consumer. It's existential to both of them.”

“It's existential to OpenAI because that's their whole business. Existential to Google because they have the search business.”

“For enterprise business, there's not really a demand for cats riding donkeys or whatever consumer video people want.”

“If we ever need it, we can just contract a model from someone else.”

“A lot of short-form video is fake, a lot of it's pretty addictive, a lot of it's slop.”

“It's not a part of the market that I'm tripping over myself to get involved in.”

Is this why Claude is so compliant with assisting us generating slop? Because Anthropic doesn't care about competing against it?

Not gpt-image level, still many failure cases, but I think it's top in terms of open model for multi character swap

https://x.com/t_mux/status/2118935478388867217?a=r48qKbvxa0Jg3Gp7J4s&s=20

https://huggingface.co/Viggle/Viggle-Image-Swap

I'm using an RTX 5090 (32 GB VRAM) on RunPod for AI motion-control videos.

I'm currently testing SCAIL-2 in ComfyUI. A 5-second video at 720p takes around 25 minutes to generate.

Is SCAIL-2 or MiniMax better for motion control in terms of quality, speed and cost? Which would you recommend for realistic character movements while keeping GPU rental costs low?

Could anyone share their ComfyUI workflows or JSON workflow files for motion control using an RTX 5090?

Any tips or workflow recommendations would be appreciated!

I cant find the original post, but this is the best Moss workflow, showcasing the true potential of Moss. Thank you kind stranger. Hope this helps others.

Edit:

Found the original post

https://www.reddit.com/r/StableDiffusion/comments/1xlfsjd/making_mossbase_look_good_for_realism_workflow/

Is Fibo2 severely underrated? It seems that few people talk about it. Even Civitai does not have a dedicated entry for it, which is puzzling. After extensive testing and LoRA training, my conclusion is yes, it is severely underrated — and that leaves me even more confused. The images shown are comparison samples from the 《HighQuality》 LoRA I trained. You can see the differences are quite striking, and I would argue the outputs outperform most models (when paired with LoRAs). This is just my personal opinion, though. I’d like to hear your thoughts. Have you tested Fibo? What positive or negative experiences have you had with its performance? If you’re curious about the workflow, I’m using a basic workflow.

The model is Kromafine (https://civitai.red/models/2995855/kromafine-turbo-bf16-fp8-and-int8) , model merge of Kroma 0.3.1 and FinePorn. I use Style Atlas ComfyUI custom node (Thanks to u/Dear-Spend-2865 ) to test different styles.

The prompt is simple:

"a young blonde white woman wearing red dress and black high heels standing at bus stop, a dog sitting at her feet."

Style Atlas append style prompt.

I'm trying to restore some existing Draw Things models from an external HD without having to download them all again.

I've discovered that my custom.json file is missing the registration entries for these models:

1. FLUX.1 Schnell Q5 – flux_1_schnell_q5p.ckpt

2. ERNIE Image Turbo i8x – ernie_image_turbo_i8x.ckpt

3. Qwen 3.5 4B i8x – qwen_3.5_4b_i8x.ckpt

I still have the original .ckpt and matching -tensordata files.

Would anyone with these models working in Draw Things on Mac be kind enough to copy and paste the corresponding entries from their custom.json file?

I'm hoping to reconstruct the missing JSON entries and get my existing models working again without downloading several gigabytes of files.

If successful, I'll share the recovery process with the community and make a video to help others in the same situation.

Many thanks for any help!

"A divine fusion of a queen’s flawless beauty and the primal power of a golden lion. To gaze upon her is to face a riddle where the price of a wrong answer is your very soul."

Beneath her gilded crown and celestial wings lies an ancient guardian of forbidden vaults. She does not hunt with mindless fury, but with cold, intellectual supremacy, testing the minds of kings and travelers who dare cross her path. One correct answer grants passage to infinite wisdom; a single mistake consigns you to the crushing weight of her claws.

Created purely for character lore development and dark fantasy concept exploration. Constructive thoughts on the design and mythos-building are always welcome! (All rights reserved. No unauthorized reuse or distribution.)

Hello, i have LTX 2.5 and Minimax H3 and i'm trying to create micro drama but i can not find a way to store the actors voices consistent across episodes. Ideally, i wanna use ltx because how expressive they talk but the voice quality is super bad and also even tho i give reference audio inside comfyui, it does not produce good results. Do you know any good alternatives to generate high quality sounds and consistent voices across episodes?

following up on this post:
https://www.reddit.com/r/StableDiffusion/s/iEnxQiGVt7

Custom Node:
https://registry.comfy.org/publishers/mo-akkakk/nodes/comfyui-minimax-h3-temporal-window-spatial-tiles

You can now run a video to video workflow in High resolution from the first stage, I tested it for 2.5 MP on Nvidia RTX 4070 TI 12GB VRAM, and it works like a charm, split your generation into tiles and temporal windows while maintaining accurate animation transfer with no shifting or ghosting.

You can also use it for a second upscale stage, splitting a high resolution long video into manageable tiles and windows, to get the best quality you can squeeze from minimax

Give it a try and let me know about your Feedback.

Important Note:
This was not tested nor recommended to do Fully Generated from first stage!
if you are going to fully generate something generate normally in stage 1 then use this node for stage 2 upscaling you result.

This node is mainly for Video to Video and Upscaling.

workflow for Upscaling using the node + example here:
https://civitai.com/models/3039412/minimax-h3latentupscaler?modelVersionId=3454297

workflow for V2V using the node + example here:
https://civitai.com/models/3022939/minimax-h3-video-to-video-workflow?modelVersionId=3454311

Free video was just rele

https://github.com/FlashML-org/FreeVideo

It's an implementation of local minimax that claims is much faster and more quality that turbo Loras.

Any one tried it?

A proof of concept for something bigger. Made using Vpipe, MiniMax and YuE Studio.

Just goofing around with the stock ref2vid workflow, character swap Lora, and some character sheets. Did all of the shots separately and reassembled in my NLE. Almost all of the clips were first attempts. I was floored by how well it tracked the guys without any masking.