# Paper plane messenger transition

After a "send" click the camera pulls back from window A, a paper plane flies out along a bezier arc, and the camera follows it to window B.

- Category: transition · Tags: shotcraft, remotion, transition, camera
- Spec: 1920×1080 @ 30 fps · 5.06s (16:9)
- License: Apache-2.0 · Tier: free
- JSON: https://gimgs.net/motion/paper-plane-messenger.json
- Kind: remotion
- Source (TSX): https://gimgs.net/motion/paper-plane-messenger/template.html
- Repo: https://github.com/Vincentwei1021/video-shotcraft
- Credits: video-shotcraft (Vincent Wei) — https://github.com/Vincentwei1021/video-shotcraft
- Page: https://gimgs.net/motion/paper-plane-messenger.html

## Params

_No params._

Default params (base64url for `?p=`): `e30`

## Prompt

## When to use

A narrative transition connecting two people/scene viewpoints via a "send/invite/share" action; when an abstract action needs a metaphorical object to carry the transition

## Intention

transition-travel is the camera drilling into an existing element already on screen to change scenes; this card does the opposite — it **releases a semantic messenger** out of the action and follows it to the next scene. The abstract action of "sending" is made into a physical paper plane, and the spatial relationship between windows A and B gets genuinely measured out by the flight path, giving the viewer a physical sense of "where the message went." The critical piece is the 2.5D camera pipeline: every element hangs on the same world coordinate system, the camera centers on A→follows the plane→B, zooming out and back in, with parallax props moving proportionally to camera displacement by depth — a heavy true-3D shot downgraded to a "fake 3D" rig, dropping a full cost tier while keeping the sense of depth. The plane's pitch following the arc's tangent is the entire difference between "it's flying" and "it's just translating."

## Duration & energy

- Duration: ~5s (150f: click 12f → pull back 16–42f → flight 34–104f → B takes over 112–146f)
- Energy: Medium

## Shot recipe (original Chinese — timing, easing, parameter table, known pitfalls)

## 意图
transition-travel 是镜头钻进画面里的既有元素换景；本卡反过来——从
动作里**放出一个语义信使**，让镜头跟着它飞去下一个场景。"发送"这个
抽象动作被实体化成折纸飞机，A/B 两窗的空间关系被飞行轨迹真实丈量
过，观众对"消息去了哪"有了身体感。命门是 2.5D 相机管线：所有元素
挂在同一世界坐标系上，镜头中心 A→跟飞机→B、变焦拉远再推近，视差
道具按 depth 乘相机位移——重 3D 原片降级成一台"假三维"，成本掉一个
量级而纵深感保留。飞机俯仰角跟随弧线切线是"它在飞"而非"它在平移"
的全部区别。

## 动效核心
- 世界坐标系相机：`screen = 960 + (world − camCenter) × zoom × depth`；
  镜头中心 A(520,560) → 跟飞机 → B(3200,600)，变焦 1.55（贴脸 A）
  → 0.62（拉远伴飞）→ 3.1（B 接管全屏）
- 飞机三次贝塞尔：A 发送按钮 → 高抛控制点（y=−80）→ 下压控制点 →
  B 门前；朝向 = bez(t) 与 bez(t+0.012) 的 atan2 切线角
- 飞行整体缓动 Easing.bezier(0.45,0.05,0.25,1)（起飞加速、落定
  减速）70f；途中 scale 放大 1.7 倍保可读，落定收回 1.1
- 视差道具 16 件（圆环/圆角方块，seed 随机）分 depth 0.45/0.75/1.3
  三层，远层 blur3、近层 blur8 焦外；各带正弦漂浮
- 飞机 = SVG 三块折面（白/浅灰/深灰示折痕）+ 描边；入场
  Easing.back(1.6) 弹出，B 接管期 opacity 淡出不留残影
- 点击脉冲：按钮 scale ×1.22 + 扩散圈（CLICK 12f 起 3f 峰值）

## 参数表
| 参数 | 典型值 | 调节手感 |
|------|--------|----------|
| 变焦三段 | 1.55 → 0.62 → 3.1 | 不先拉远直接跟飞，观众不知道 B 在哪个方位；拉远 <0.7 才装得下旅程感 |
| 飞行时长 | 70f，ease-in-out | <45f 读作弹射；匀速读作拖拽平移 |
| 切线采样 | dt = 0.012 | 太大角度滞后、太小抖动；俯仰角是"飞"的命门，删掉立即变贴图滑动 |
| 途中放大 | ×1.7（0.25–0.75 区间），落定 ×1.1 | 拉远后飞机只剩几十像素，不放大就丢主角 |
| 视差层 | depth 0.45/0.75/1.3，远 blur3 近 blur8 | 全同 depth 就没有穿越感；近景不虚会抢飞机视线 |
| B 接管 | 112–146f，变焦推到 3.1，道具/飞机同步淡出 | 道具不淡出会在推近时变成巨大糊块扫过全屏 |

## 已知坑
- demo 在灰阶/占位素材上调校通过——参数是调校起点非实战定稿，
  首次实战须以真实素材回验
- 与 transition-travel 分工：那卡钻进**画面里既有的**元素/容器完成
  换景（空间早已在构图里）；本卡**放出一个新实体**连接画外的第二场景
  ——A/B 无既有空间关系时才轮到本卡
- 与 glow-flyline-moves B（flyline-arc）分工：飞线是暗场数据流向的
  抽象示意（线是主角），本卡是明场叙事旅程（信使是主角、镜头伴飞）
  ——讲数据用飞线，讲人与人用信使
- 信使实体必须来自动作语义（发送→纸飞机、上传→气球、部署→火箭），
  随便找个吉祥物飞一趟读不出因果
- 相机三段（拉远/伴飞/接管）的切换帧上中心与变焦都要连续——demo 里
  zBase/zTake 在 TAKEOVER[0] 处相等（0.62）才不跳帧，改时间轴先查这点
- 2.5D 的极限：道具只能是剪影级形状，写实道具会暴露"没有真透视"；
  要重 3D 质感请回原片路线（成本高一档）

## 参考实现
demos/transition/paper-plane-messenger/
（PaperPlaneMessenger.tsx）
原片出处：pitch-app 77–82s（重 3D 原版的 2.5D 降级）

## Reference implementation (Remotion)

- demos/transition/paper-plane-messenger/PaperPlaneMessenger.tsx — https://raw.githubusercontent.com/Vincentwei1021/video-shotcraft/main/demos/transition/paper-plane-messenger/PaperPlaneMessenger.tsx

The component imports shared fixtures from `demos/_fixtures` and helpers from `assets/lib` in the repo; SKILL.md there documents the render workflow.


## Flow

1. **Read the recipe**
   Prompt = when to use, intention, parameter table with typical values and how each one feels, known pitfalls. Treat values as calibrated starting points.
2. **Get the code** — tool: git
   `git clone https://github.com/Vincentwei1021/video-shotcraft && cd video-shotcraft && npm install`
3. **Register + render** — tool: remotion
   `npx remotion render <CompositionId> out.mp4   # component: demos/transition/paper-plane-messenger/PaperPlaneMessenger.tsx`
4. **Or re-implement**
   Port the timing/easing from the recipe to HTML + WAAPI (gimgs motion contract) or any engine; keep the same segment windows and easing.

## Render

Clone https://github.com/Vincentwei1021/video-shotcraft (npm install). The component lives under demos/{category}/{name}/ and imports shared fixtures from demos/_fixtures and helpers from assets/lib. Copy it (with those imports) into a Remotion project, register a <Composition> with the template's width/height/fps/duration in Root.tsx, then `npx remotion render <CompositionId> out.mp4`. SKILL.md in the repo documents the full Claude Code / Codex workflow. The prompt below is the shot recipe (timing, easing, parameter table, pitfalls) — enough to re-implement the shot in HTML/WAAPI or another engine if you prefer.

## Contract

React/Remotion composition (TSX) from the open-source video-shotcraft library (Apache-2.0). It is not a browser-playable template: clone the repo, register the component in a Remotion project and render with `npx remotion render`. The recipe (prompt) describes timing, easing and parameters so you can also re-implement the shot in any engine.