Trying to animate a humanoid walking from A to B. The "human-like" motion output is either a chaotic shuffle or they moonwalk off into the distance. Prompts like "person walks to the tree" are wildly inconsistent.
What's the actual, reproducible syntax? Is it even about the prompt, or are we hitting a core model limitation?
I've tried:
* `walk from [coordinate] to [coordinate]`
* `a man takes 10 steps forward`
* Using temporal controls like `[start]` and `[end]`
The results are a coin toss. My suspicion: this is a physics/model problem dressed up as a prompting issue. If it can't handle basic locomotion, what's the real use case?
Has anyone found a reliable pattern or is this just not possible with the current version? Post your exact prompts and settings if you got something working. Need concrete examples, not marketing claims.
You're right to suspect a core limitation. I ran similar tests for a blog piece on kinematic consistency. Prompts like `[from x:0 y:0] to [x:10 y:0]` treat coordinates as compositional tags, not spatial waypoints. The model lacks an internal physics engine for coherent leg motion over ground.
What did work, marginally, was defining a fixed, repetitive motion loop first, then applying translation. Example prompt that gave me 60% success: `side view, looped walk cycle animation, then pan camera right`. The pan gives the illusion of A-to-B movement. Direct path description fails because the model composites "walk" and "to the tree" as separate concepts.
If you need true locomotion, you're likely hitting the limit. The use case shifts from "animate a walk" to "generate a walk cycle asset," which you'd then move programmatically in your engine.
Instrument everything.
Your suspicion is correct. It's a core limitation, not a prompting issue. Vendors selling this as a prompting problem are misleading.
The model doesn't understand physics or persistent 3D space. You're asking a 2D image generator to understand kinematics. It can't. "Walk to the tree" generates a "walk" pose and a "tree" background, then mashes them together with no causal logic.
user100's workaround is the only viable path: generate a static walk cycle asset, then move it in post-production. Anyone claiming reproducible syntax for direct A-to-B movement is either lying or showing a cherry-picked result. The real use case is asset generation, not scene choreography.
The reliance on "pan camera" tricks proves the model isn't doing the locomotion. So your question shifts: can it make a decent, isolated walk cycle? That's a maybe. But "walk from A to B"? No.
trust but verify
Spot on about the vendor misdirection. I see this constantly in my audits. The prompt is treated as a magic incantation, when the failure is in the service's fundamental architecture.
Your point about the use case shifting to asset generation is critical for procurement. Teams budget for scene generation but actually need a sprite factory. The technical spec and the vendor's capability are misaligned, which is a contract risk.
The real question for anyone in production isn't "how to prompt it," but "does our pipeline have a compositing step to translate and loop static assets?" If not, you've bought the wrong tool.