article cover

Trying Painter node series in a Wan2.2 Action Workflow

1-Minute Tutorial Sharing Challenge

At the beginning

This time, I wanted to test three Painter nodes in a way that actually meant something inside a real workflow, not just as isolated experiments:

  • PainterI2V
  • PainterLongVideo
  • Painter Sampler Advanced

Instead of testing them separately in small examples, I built a full multi-stage Wan2.2 action workflow around them and kept refining it until the result felt stable enough to publish as a workflow report.

I also decided not to use any LoRA for this project. Since the point of this report is to introduce the Painter nodes themselves, I wanted the final result to show what these nodes can do on their own, rather than letting extra style or motion support take the spotlight.

The final workflow uses a four-stage structure with 85 / 65 / 65 / 85 frames, a Wan2.2 High/Low model pair, PainterSampler on every stage, and a staged decode / sharpen / reuse flow between segments. In the current version, Act 1 uses PainterI2V, while Acts 2, 3, and 4 use PainterLongVideo. The workflow also keeps a common resized base image through ResizeLongestTo and PainterImageLoad, and uses CLIP Vision guidance for later stages.

[Public Workflow Link Here]

Why I Wanted to Try These Nodes

What I usually care about in Wan2.2 I2V workflows is not just whether the subject moves.

That is the easy part.

What matters more is whether the motion still feels convincing once the video is split into multiple connected scenes. A single shot can look fine on its own and still fall apart once you try to connect it to the next one. That is where a lot of workflows start to break:

  • motion becomes too weak,
  • framing suddenly drifts into close-ups,
  • the character slowly loses consistency,
  • pacing changes too much between segments,
  • or transitions simply feel awkward.

That is why these three Painter nodes interested me. They looked like they could solve different parts of the same overall problem.

  • PainterI2V seemed promising for stronger stage-level motion.
  • PainterLongVideo seemed useful for continuity and long-form flow.
  • PainterSampler seemed practical for keeping a Wan2.2 High/Low workflow readable.

So instead of asking which one was “best,” I tried building a workflow where each one had a clear role.

The Workflow I Ended Up With

The final sequence is built like this:

  1. Act 1: the character drops the raised leg and throws a short rapid punching combination
  2. Act 2: the punches stop, and the character launches into a large jump
  3. Act 3: while airborne, the character performs a single stretched high kick
  4. Act 4: the character descends, lands, and settles into a guarded final pose

In practice, this became a hybrid setup.

PainterI2V is used where I wanted a stage to feel immediate and forceful.

 That is why it is used for the first action beat.

PainterLongVideo is used where I wanted continuity more than pure aggression.

 That is why it handles the later connected stages.

And underneath all of that, PainterSampler is used on every stage so the Wan2.2 High/Low model structure stays manageable instead of turning into a mess.

Between stages, the output is decoded, lightly sharpened, and passed forward as the next stage’s image input. In the current version, I settled on light CAS sharpening between stages rather than a stronger Unsharp Mask approach, because repeated Unsharp processing tended to make clothing and body shading feel flatter over time.

How Each Node Felt in Practice

PainterI2V

What it does

 PainterI2V is a stage-oriented motion enhancement node for image-to-video generation. In practical use, it feels like a node for making a single segment commit more clearly to an action beat. In this workflow, it is used in the opening stage, where the character drops the initial raised-leg pose and immediately goes into a short, sharp punching sequence.

How it felt to use

 PainterI2V worked best when I kept the prompt simple and direct. The more I tried to make the prompt “cinematic,” the easier it became for the model to do the wrong thing instead — zooming in, softening the action, or holding the pose too long.

Once I reduced the instructions to something cleaner and more structural, PainterI2V became much more dependable.

The most obvious control point here was motion_amplitude. When it felt too low, the stage became soft and a little hesitant. When it went higher, the action became more decisive and readable. The difference was fairly easy to feel. Compared to PainterLongVideo, PainterI2V gave a stronger impression that motion_amplitude was directly pushing the action forward.

That said, even with PainterI2V, making kicks feel truly fast was still harder than making punches or pose changes feel sharp. In my tests, kicks tended to become readable before they became truly violent. So I ended up using PainterI2V more as a node for clear action beats than for extreme speed.

In short, PainterI2V felt strongest when I wanted:

  • a clear pose change,
  • a direct attack beat,
  • and a stage that should feel active immediately.

PainterLongVideo

What it does

 PainterLongVideo is a continuity-oriented node for multi-stage video generation. Rather than simply “adding more motion,” it helps preserve motion flow, scene coherence, and character presence across connected segments. In this workflow, it is used for the later stages: the jump, the airborne continuation, and the landing sequence.

How it felt to use

 PainterLongVideo was the node that made the workflow feel like one sequence instead of several disconnected clips.

Without it, I could still get isolated action shots, but the whole sequence felt broken apart. The timing shifted too much, the character drifted, and transitions looked more like separate generations stitched together than one evolving action.

PainterLongVideo improved exactly those things:

  • transitions became smoother,
  • movement felt more continuous,
  • the character stayed more stable,
  • and the overall pacing felt more unified.

However, it also had a very clear personality.

Compared to PainterI2V, the impact of motion_amplitude felt less direct. Increasing it still changed the result, but not in the same sharp, immediate way. The node felt much more influenced by the overall continuity structure than by raw amplitude alone.

On the other hand, motion_frames felt very important. This was the parameter that most clearly affected how strongly one stage carried into the next. When motion_frames was higher, transitions felt smoother, but motion also became more even and controlled. When it was lower, cuts felt more distinct and the action had a better chance of keeping some rise and fall.

That tradeoff became one of the most interesting parts of using PainterLongVideo:

  • higher motion_frames = smoother continuity, but more motion averaging
  • lower motion_frames = less carryover, but more noticeable stage separation

So for me, PainterLongVideo became less of a “make it faster” node and more of a make it hold together node. It was especially useful once I accepted that its strength was continuity, not raw explosiveness.

In short, PainterLongVideo felt strongest when I wanted:

  • better stage-to-stage flow,
  • more stable character continuity,
  • and a sequence that feels connected instead of stitched.

Painter Sampler Advanced

What it does

 PainterSampler is the sampling backbone in this workflow. It handles the Wan2.2 High/Low model structure in a much cleaner way than manually splitting that logic across separate parts of the graph. In this workflow, every stage is run through PainterSampler using the Wan2.2 High/Low pair.

How it felt to use

 This node is less dramatic than PainterI2V or PainterLongVideo, but it ended up being one of the most practically useful ones.

Once the workflow grew into four stages with repeated decode, image reuse, CLIP text, CLIP Vision, and stage-specific prompts, the sampling layer could have become very hard to manage. PainterSampler helped keep that structure readable.

It also made the workflow feel more realistic to maintain. That matters a lot once a graph stops being an experiment and starts becoming something you actually want to publish and explain.

So while PainterSampler is not the node that gives the most visible “wow” effect by itself, it is one of the reasons the overall workflow feels controlled instead of chaotic.

In short, PainterSampler felt strongest when I wanted:

  • a cleaner Wan2.2 High/Low structure,
  • a more readable staged graph,
  • and a workflow that still makes sense after hours of iteration.

What Took the Most Work

Most of this workflow was built through repeated correction.

A lot of the struggle came from things I did not want the model to do:

  • zooming in when I wanted full-body framing,
  • preserving the initial raised-leg pose for too long,
  • converting action prompts into the wrong action,
  • throwing large jumps out of frame,
  • or flattening clothing and body shading across multiple stages.

One of the biggest lessons was that prompt writing became more reliable once I stopped trying to make everything sound stylish. The model responded better when I separated the tasks clearly:

  • pose change,
  • motion instruction,
  • framing instruction,
  • and transition instruction.

That meant using structural lines such as:

  • the punches stop immediately,
  • both feet clearly leave the ground,
  • the body is still airborne at the first frame,
  • the landing does not happen immediately.

Those kinds of lines helped much more than decorative cinematic wording.

Another lesson was that sharpening between stages matters more than I expected. Earlier versions used Unsharp Mask, but in this workflow it sometimes caused the clothing and body shading to feel flatter over time. CAS was not perfect either, but it felt easier to control once I kept it mild and limited to earlier transitions. The current version uses small CAS values between stages, with the final transition effectively neutralized.

What the Final Workflow Actually Shows

I would not call this workflow perfect, but I do think it demonstrates something useful.

It is not just a graph containing three Painter nodes.

 It shows that these nodes become much more effective once they are given different jobs.

  • PainterI2V gives stronger and clearer action beats.
  • PainterLongVideo makes those beats connect into one sequence.
  • PainterSampler makes the full Wan2.2 High/Low setup much easier to build and maintain.

That ended up being the real value of this test.

I started out wondering which Painter node would be the most useful by itself.

 I ended up learning that the more important question was what role each one should.

Once I stopped forcing one node to do everything, the workflow finally started to make sense.

Final Thoughts

For me, this workflow became less about “which node is strongest” and more about workflow balance.

PainterI2V was the node I trusted when I wanted motion to hit.

 PainterLongVideo was the node I trusted when I wanted the sequence to hold together.

 PainterSampler was the node that made the entire High/Low structure practical enough to keep using.

That combination was what finally worked.

So if you are building multi-stage Wan2.2 I2V workflows, especially action-oriented ones, I think these three Painter nodes are absolutely worth trying together.

Not because they magically solve everything, but because they each solve a different part of the problem — and once those parts are assigned properly, the workflow becomes much easier to control.

Thanks!

99
0 comment
57
39
99
0
0/1000