Can Blender Previz Save Seedance Credits? A Fight Scene and a Camera Path Test

Can planning the action in Blender save some of the tokens we spend generating AI video? That's what we wanted to try.

We subscribe to Claude Code. We subscribe to Codex. We're paying for both subscriptions. Might as well put them to work. If an agent can operate Blender locally, could we use it to arrange the characters and camera, fix what looks wrong, and only then send the result off for video generation?

Every generation costs credits. Submit a scene before you've worked out the action, and you're paying for each round of trial and error. We'd like to do more of that locally: watch the previz move, adjust the camera, try again. The agent still uses our subscription allowance, but changing a move doesn't immediately mean paying for another generated video.

Having tried it, we think this workflow is worth using. We can see the previz's actions and the drawn route in the finished clips, though some details changed along the way. We haven't calculated the savings yet. We have, however, seen where the references help.

Blender to Seedance: last time a blocky cat, this time a fight

In our earlier Blender previz experiment, we checked the positions of a cat, a paper boat, and a storefront.

This time, we gave Seedance the previz video to see how much of the choreography it would follow.

In Blender, an orange character on the left fights unarmed. A teal character on the right carries a sword. They exchange attacks for six seconds. The models don't need much detail yet; we just need to show the action. Then we hand the clip to Seedance 2.5: replace the left character with the character in red, the right one with the woman in purple, and the background with our chosen scene. Follow this fight.

Here's an English translation of the prompt we submitted in Chinese. We've replaced the asset UIDs with readable names.

[Generation goal] Generate a fight video using [motion reference video] as the reference. The fighting should feel powerful, with a sense of impact.

[Motion reference video] is the action guide. [Purple character reference image] is the character on the right in the action guide. [Red character reference image] is the character on the left in the action guide, without a sword, using only punches and kicks. [Scene reference image] is the actual setting.

Replace the setting in the action guide with [scene reference image], the right character with [purple character reference image], and the left character with [red character reference image].

Generate both characters' movements according to the choreography in [motion reference video].

[Restriction] [Red character reference image] must not hold any blades or swords. Use only punches and kicks.

Most of that prompt says what to replace with what. As for the choreography, we handed it over with one instruction: follow the motion reference.

With text alone, we'd have to describe who raises the sword first, which way it swings, how the other person blocks it, and how far apart they stand. Then there's the camera. Blender has already shown all of that, so we left out much of the description. We still have to choreograph the fight, but we can watch it as we make changes, instead of imagining the action while wondering whether a sentence actually explains it.

Does Seedance follow the Blender previz? Mostly, until a punch becomes a kick

We used FFmpeg to extract frames in our earlier article on why extended AI video clips can stutter at the join. Here, we used it again to put the previz and output side by side at the same timestamps.

The generated fight runs at 24 fps. Frame numbers below start at zero, and times were checked against the original file timestamps. We haven't stretched the previz or interpolated frames.

Time / frame in both clips	Blender previz	Generated output
0.500 s / 12	Unarmed guard on the left, sword on the right	Same roles, with a closer camera
1.000 s / 24	Sword arm rises and draws behind the body	The woman in purple reaches the same stage of the motion
2.000 s / 48	Body lowers after the swing	The woman in purple also lowers her body; her legs are outside the frame
2.500 s / 60	Rising and approaching the opponent	The characters close the distance again
3.750 s / 90	The unarmed character punches forward	The character in red kicks
4.000 s / 96	Arm still extended in a punch	Leg still raised in an attack

The sword lift, downward swing, lowered stance, and recovery line up. Then the character in red counters with a kick where the previz has a punch.

A kick doesn't violate our instruction to use “only punches and kicks.” But we did animate a punch. If that particular punch matters to the scene, we'd still have work to do here. The earlier exchange lines up, though. We can see the previz's influence.

Something else caught my attention: the orange and teal models don't appear in the comparison frames. The simple ground plane has become stone paving, a reclining Buddha, and distant mountains. The simplified models' motion carries over while their appearance changes. From this result, we'd guess ByteDance has become fairly good at this kind of replacement. At least we don't see an orange mannequin suddenly turning up in the sampled frames.

The camera has moved closer, too. The previz shows full bodies; some leg movements fall outside the generated frame. We didn't write a long camera prompt, and the exchange still came through. If keeping both characters fully in shot were essential, we'd need to add that requirement.

As for impact, we only wrote one brief request: make the fighting feel powerful. There's room to work on that. We wouldn't jump to saying the model can't do it when we haven't spent much time on the prompt ourselves.

After the reference ends: I left the extra four seconds on purpose

The previz lasts six seconds. I requested ten seconds of output. I wanted to see what would happen after the reference ran out.

They kept fighting. The woman in purple swings her sword; the character in red dodges, blocks, and counters. They return to a standoff near the end.

It adds another exchange after the reference ends. It had already improvised earlier, when the punch became a kick; the extra four seconds let us see how it would keep the fight going.

If we can act out a fight, can we draw the camera path?

A while ago, people were trying another idea: draw a line on an image and see whether a video model follows it with the camera. We tried it with a harbor scene. Start beside the little blue boat, skim the water around the white boats, enter the waterfront buildings, then climb toward the church. Here's the route.

Original image

Without the line, there's quite a bit to explain. There are two white boats—which side do we go around? Which opening on shore should we face afterward? The church is up above, but do we fly straight toward it or pass through the lower buildings first? A camera move that feels obvious in your head becomes a series of turns you have to describe.

That's the convenience of drawing it: “Start here, go through here, end there.” You can point at the image. We wanted to see whether this could save some of the time spent writing prompts and explaining the route again.

Higgsfield's 3D Jutsu takes a related approach: an agent builds an editable 3D scene, then you adjust objects, cameras, and animation. Arranging the scene before generating the video is close to what we want to do with Blender locally.

The line doesn't remove the need for a prompt. We still have to say how low to fly, where to rise, how to pass through windows—and that the purple line must not appear in the video. We even wrote, “Do not turn the markings into light trails, ropes, or scene objects.” Use the route, please. Leave our annotations out of the shot.

We split the twelve seconds into four stages: 0–3 seconds from the blue boat to the white boats, 3–6 circling the boats, 6–9 entering the buildings, and 9–12 rising to the church. The boats stay moored. The camera moves.

The window entry is worth pausing on. At about seven seconds, the camera passes through the mint-green building's window frame. The bright harbor falls behind, and a dark passage opens ahead. We didn't draw the interior. It filled in that stretch itself.

Requested movement	What appears in the output
0–3 s: skim from the blue boat toward the white boats	At 0.000 s / frame 0, the blue boat is close on the left; by 2.500 s / frame 60, the camera approaches a white boat's bow
3–6 s: make one full circuit around both white boats	At 3.000 s / frame 72, the camera passes another boat side; by 4.000 s / frame 96, it heads ashore, leaving early. These frames don't establish a complete circuit
6–9 s: enter the buildings	Still outside at 6.500 s / frame 156; through the window frame at 7.000 s / frame 168; inside the passage by 7.500 s / frame 180
9–12 s: rise toward the church	Looking out from an archway at 10.000 s / frame 240; outside the bell tower at 12.000 s / frame 288

The window passage and climb to the church are there. The sampled frames don't show purple lines or numbers. But the boat circuit ends early, so the timing differs from our instructions. Watching once, you might think it looks close enough. Pausing at matched timestamps makes the differences easier to see.

Taking this into Blender would let us preview the camera traveling along the route. We could fix an obstruction or an awkward turn locally. Before going further, though, we wanted to try one more thing.

Take the drawn path away and the camera still gets there

What if we remove the route guide and generate another clip using only the clean harbor image and text?

It still gets there. The blue boat, white boats, building passages, and church all remain in the sequence. The text already explains quite a lot. The model can work without the guide image.

Top: with the route guide. Bottom: without it. Both clips are shown at the same timestamps, with zero-based frame numbers and no speed adjustment.

The difference at four seconds is easy to spot. The guided version is heading ashore, while the other is still beside the boats. At seven seconds, both reach an opening in the mint-green building. At ten, they use different passage exits. Their final compositions differ, too: the guided version is closer to the bell tower; the other includes the dome and the sea behind it.

The version without the guide has a spacious ending and a route of its own. The two clips have different rhythms, and the unguided one has its appeal too.

I'd still draw the line, though. Especially when I've already decided which boat to start beside and which window to enter. An image makes that easier to explain and check later. Being able to generate without the image doesn't tell us how long it would take to describe the route from scratch.

The same goes for a fight. With that many movements between two characters, it's more direct to act it out and point to the move you want to change. When you know exactly what you want, a reference is worth preparing.

We're trying to reduce the moments where “I meant this” turns into “you went somewhere else.” With a reference, at least we can point to the part we want changed.

Why does Seedance still drift from a reference video?

Look again at 3.750 seconds in the fight: the previz punches, but the character in red kicks. In the harbor clip, we're already heading ashore at four seconds, when we'd planned to still be circling the boats. The broad direction survives; details drift. We've shown it what to do. Why does this still happen?

The Seedance 1.5 Pro report describes a Diffusion Transformer and MMDiT for joint audio-video generation. The 2.0 model card lists text, images, audio and video as combined inputs. Publicly described generation methods give us a starting point for understanding how references guide an image. Seedance 1.5 Pro technical report, Seedance 2.0 model card

Start with publicly described diffusion methods. A model begins with noise and progressively generates an image, guided by text or other conditions along the way. Latent Diffusion uses cross-attention to bring conditions such as text and bounding boxes into generation. The model learns to produce suitable images given those conditions. Supplying them doesn't, by itself, make every step execute like an animation instruction in Blender. Latent Diffusion paper

What if we strengthen the guidance? Classifier-Free Guidance combines conditional and unconditional model predictions to steer generation; its paper also discusses the trade-off between quality and diversity. Stronger guidance still doesn't add a check that says “frame 90 must contain a punch.” Locking a pose or path requires an appropriate constraint. Classifier-Free Guidance paper

If Seedance 2.5 uses this kind of conditioning, it could help explain why references guide the result while details still drift. These public methods give us a way to think about it; 2.5's implementation has not been described at that level.

We'd use this workflow again. Act out a complicated exchange in Blender. Draw the intended camera route. That gives us something concrete to compare against. Then check the finished clip for the punch or turn that must stay as planned. The source clips, prompt, and matched frames are above, so you can see what carried over and what changed.

Next time, I'd still work out the action and camera locally before spending credits on generation. If I want to change a punch or a turn, I can start by opening Blender.

If you already have footage close to the motion you want, there's a route that skips the blocking: use a depth video as the motion reference.

Original cover image