oil-motion: Oil Motion: The AI Motion Pipeline That Makes Video Behave Like an Interface
It generates continuous motion, cleans the frames, chooses the right delivery format, and maps scroll, mouse, drag, touch, or device orientation onto the same sequence.
- Oil Motion is not just generating video, it is turning motion into a runtime asset that the browser can index with user input.
- The repo is built for agents as much as for developers, which shifts the workflow from hand-authoring animation to orchestrating production.
- Its real value comes from the pipeline behind the scenes, where frame cleanup, validation, and format selection make AI motion usable on the web.
- The project wins a narrow but important gap between manual animation tools and generative video tools.
Most animation tools start with a timeline. Oil Motion starts with a question: what if the page itself could decide where motion should be sampled? The project maps scroll, mouse movement, drag, touch, and device orientation onto one generated sequence, so the browser is not just playing motion. It is steering it.
That distinction matters because it changes what an animation is. In Oil Motion, motion is not a finished file you drop into a page. It is an input-aware asset that can be scrubbed, bounded, normalized, and packaged for a specific interaction budget.
The weird part: motion is controlled after it is generated
The simplest way to understand the repo is as a layer between AI video generation and frontend interaction. It uses generated motion as raw material, then turns that material into a controllable sequence. That means a product reveal, character move, or scroll story can be driven by the same motion data, even if the user reaches it through different inputs.
This is why the project feels different from a normal animation library. Framer Motion and GSAP give you control over motion you authored. Oil Motion gives you control over motion you did not author by hand.
Oil Motion 从目标出发构思交互动画，先生图锁定首尾状态，再用AI 视频补全连续动作，最后编译成由连续参数控制的网页动画。
Built for agents, not just developers
The repo is organized like a production system, not a demo. The presence of agents/, evals/, references/, and a script-heavy pipeline tells you the intended user is not a person clicking through a UI. It is an agent carrying out a motion brief.
That workflow changes the role of the human. You supply intent, constraints, and source material. The agent handles generation, cleanup, validation, and packaging.
程序只处理确定性工作：探测、插帧、切帧、离线或实时抠色、去溢色、稳定、查重、检测闪帧、编码、图集打包、清单生成、预加载、文字覆盖和交互映射。
How the pipeline keeps AI motion from going feral
The pipeline is where the project earns its credibility. It does not trust raw generations. It starts with keyframes that define identity and endpoints, then fills the motion between them with AI video, then checks the result for stalls, glitches, jumps, and drift.
That matters because generated motion is only useful if it behaves predictably when the user scrubs it. If a frame sequence jitters, repeats too long, or drifts off anchor, the illusion breaks. The repo treats those failures as engineering problems, not aesthetic annoyances.
The evaluation and cleanup layer is the real moat here. It turns an impressive clip into a dependable interaction primitive.
Why it chooses between WebP atlases and green-screen MP4
Oil Motion is opinionated about runtime cost, not one universal format. For small, looping, or jumpy interactions, it can use Alpha WebP atlases. For larger scroll-driven sequences, it can use chroma-key MP4 and composite it in WebGL.
That decision is subtle but important. The repo is not saying one format is best. It is saying the right format depends on motion budget, device limits, and how the interaction will be consumed.
| Project | Primary asset | Workflow | Control model |
|---|---|---|---|
| Oil Motion | AI video, WebP atlas, or chroma-key MP4 | Agent-driven generation, QA, and packaging | Input-to-frame mapping |
| Framer Motion / GSAP | CSS, SVG, canvas, or DOM transforms | Manual authoring in code | Time or physics based |
| Lottie | Vector animation JSON | Design export from After Effects | Timeline playback |
This is the gap the project occupies. It is not trying to beat Framer Motion or GSAP at authoring motion by hand. It is trying to automate the creation and delivery of motion that would otherwise be too cinematic, too complex, or too expensive to build manually.
What makes this different from Framer Motion, GSAP, and Lottie
The comparison is easiest if you separate the asset from the control layer. Framer Motion and GSAP are control systems for motion you define. Lottie is a vector export pipeline. Oil Motion is a generative pipeline with a runtime mapping layer on top.
That makes it useful in a different part of the stack. If your problem is animating a card, use a motion library. If your problem is turning AI-produced motion into a scroll-driven interface element, Oil Motion is the more interesting abstraction.
The trade-off hidden inside the magic
The project solves a real problem, but it does not remove complexity. It moves complexity into evaluation, asset budgeting, and generation quality. That is a good trade if you want cinematic motion without hand-animating every state.
It also means trust has to be earned. The presence of evals/ and the README's emphasis on validation are reassuring because they acknowledge the fragility of AI motion instead of pretending it is free.
A concrete recipe for turning AI-generated video into scroll- and input-driven web animation that agents can produce end to end.
Why the repo matters
Oil Motion points at a useful future for frontend work. The browser does not always need a hand-built animation timeline. Sometimes it needs a generated motion source that can be cleaned, constrained, and mapped to interaction with enough precision to feel native.
That is the real shift here. Motion becomes something closer to infrastructure: generated upstream, validated in the middle, and consumed downstream as an interface component.