וידאו
שהוא קוד.
איך Claude מייצר סרטוני השקה ברמת סטודיו, בלי After Effects
seek(t) → Playwright → ffmpeg · 60 fps · on the beat
▶צפו בשלושת הסרטיםקטלוג: מה אפשר לבקשהסרטון למטה הוא לא קובץ וידאו. הוא תוכנה קטנה שמציירת אותו בזמן אמת, פריים אחרי פריים, מתוך מספר אחד בלבד: הזמן. בדיוק כמו הסרטונים של @twoclipping, רק קטן יותר. לחצו Play, תגררו את הסרגל לכל נקודה — ואז נפרק אותו ביחד, מהיסוד, פירור אחרי פירור.
סרגל הביטים מתחת לתמונה: כל קו הוא ביט (חצי שנייה, כי השיר ב-120 פעימות לדקה), הקו הכתום הוא ה"דרופ" — הרגע שבו המוזיקה מתפוצצת. המוזיקה והאפקטים כאן מסונתזים בדפדפן לצורך ההדגמה בלבד; השיטה המקורית דורשת סאונד אמיתי (ונראה למה).
הסרט: 27 שניות, 60fps, עשוי כולו בשיטה הזו
קובץ HTML אחד ופונקציה אחת של זמן. כל פריים צולם ב-Playwright, הסרט הורכב ב-ffmpeg, והמוזיקה והאפקטים אמיתיים, כל אחד ממוקם לפי השיא הנמדד שלו.
שיעור שלא מופיע במאמר: אותה תנועה, שני כיווני אמנות
הגרסה הראשונה (מימין) עבדה טכנית: אותו תזמון, אותם קפיצים, אותו סאונד. ובכל זאת היא נראתה "אנמית". הגרסה השנייה (משמאל) לא הזיזה אף שנייה בתזמון. היא שינתה רק את השפה הוויזואלית:
- דף צבע מלא שמתחלף על הביט הראשון של כל תיבה (שחור, ציאן, מג׳נטה) במקום נייר חיוור קבוע. ההחלפה היא מגב קשיח עם פס צבע מוביל, לא פייד.
- טיפוגרפיה בקנה מידה של מגזין: כותרת Rubik 900 בגודל 150px מעוגנת לימין, במקום 104px באמצע. כותרות המשנה ב-Anton במקום מונו דק.
- מספרי פוליו ענקיים (01–07) שיוצאים מגבולות הפריים. זו שכבת עומק בלי שום תוכן נוסף.
- קווים עבים (4–9px) ובלי אפור: כל צבע על המסך הוא צבע מותג.
שלב הבא: YUV.AI MOTION, אותה שיטה בקנה מידה מלא
סרט השקה של 33 שניות למוצר דמיוני שהופך כל נושא לסרטון השקה. הוא בנוי עם הקיט שיצא מהעבודה הזו, ושום פריים בו לא מגיע מתוכנת עריכה:
- תיבת קלט עם הילה ניאונית שפועמת על הביט.
- הקלדה בתווי שש־עשרה, והמצלמה עוקבת אחרי הסמן.
- קליק שמתפוצץ לכרטיס שנוחת בקרוסלה תלת־ממדית ונעצרת על כל ביט.
- אייפון ומקבוק שהמכסה שלו נפתח על הביט, עם קוד שנכתב על המסך בזמן אמת.
- טיים־לאפס של השמיים מיום לשקיעה.
גם הים, העננים והשמש הם קוד: three.js ושיידר, עם אותו שעון seek(t). הקוד פתוח בתיקייה /kit.
ועכשיו סיפור: "קצב", סרט מוצר לאפליקציית כושר
סרט השקה הוא לא רשימת פיצ'רים. "קצב" (אפליקציה דמיונית) בנוי כמו פרסומת אמיתית: בעיה שמרגישים, רגע מפנה, המוצר מבפנים, אנשים שמשתמשים בו, הוכחה, ולמה עכשיו. 40 שניות, 84 ביטים, וגם כאן כל פריים הוא קוד:
- הבעיה: לילה, ספה, טלפון. לוח שנה שמתמלא באיקסים, שלוש התראות מאפליקציות שלא עבדו, ואז הכל מתכווץ לנקודה שפועמת כמו לב והופכת לאייקון.
- הדרופ: איריס אל שמיים של יום, והשם נוחת על הביט.
- המוצר מבפנים: צלילה לתוך המסך, גלילה בפיד על הביטים, צ'יפים ניאוניים שמסבירים כל חלק, טאפ שהופך כרטיס למסך הבא, ומסך אימון חי.
- מתאמנים: נועה עושה סקוואט, וכל חזרה נוחתת על ביט ושולחת "+1" למונה בטלפון. דניאל רץ, מאיה עושה שכיבות סמיכה, והמסך מתחלף איתם. הדמויות מצוירות בקוד, עם רגליים שנטועות ברצפה וזרועות ב־IK.
- הוכחה ולמה: רצף של 30 יום, גרף לפני ואחרי, שלוש סיבות, וכפתור הורדה עם הילה.
בשורה התחתונה — בלי מילה אחת של ז'רגון
חמישה משפטים. כל השאר בעמוד הוא ההוכחה והפירוק שלהם.
- קלוד לא מצייר וידאו. הוא כותב תוכנה שמציירת כל תמונה בסרטון. שאלה ויזואלית ("תעשה משהו יפה") הופכת לשאלה של קוד ("מה המיקום של הכפתור בשנייה 4.2?") — ובשאלות של קוד קלוד מצוין, מדויק ועקבי.
- הטעם לא נשאר לניחוש. הפרומפטים שלו לא אומרים "תעשה יפה"; הם מכתיבים צבעים מדויקים, פונט, ורשימת "אסור" ארוכה של כל הטריקים הזולים שמודל נוטה אליהם כברירת מחדל.
- אין חיתוכים — יש שינויי צורה. כפתור לא נעלם ומוחלף בעמוד; הכפתור עצמו גדל והופך לעמוד. העין עוקבת אחרי אותו אובייקט, והמוח קורא את זה כסיפור אחד רציף ויקר.
- המוזיקה היא השעון. קודם מודדים את השיר — כמה פעימות בדקה ומתי הפיצוץ — ורק אז מתכננים מה קורה בכל פעימה. התנועה "נוחתת" על הקצב כי היא תוכננה עליו.
- קלוד בודק את עצמו לפני שאתם רואים. הוא מצלם תמונות סטילס, מסתכל עליהן (הוא יודע לקרוא תמונות), מודד קפיצות ותקלות במספרים — ורק אז מרנדר. אתם נותנים הערות כמו במאי, לא כמו מתכנת.
מי זה @twoclipping, ומה בדיוק הוא פרסם
עובדות עם מקורות. מה שלא הצלחתי לאמת — כתוב במפורש.
zero (@twoclipping ב-X) הוא יוצר שהתפוצץ בשבוע ההשקה של Claude Opus 5.5 (שיצא ב-22 בספטמבר 2026). הפוסט הראשון שלו — "צורה אחת שמשתנה דרך תריסר מצבי ממשק על הביט" — עלה ב-24.9 ונמדד בכ-978 אלף צפיות ו-11.9 אלף לייקים (מדידה אחרת, מאוחרת: 933 אלף). הוא פרסם יחד עם הסרטונים את הפרומפטים המלאים והזמין במפורש להעתיק אותם ("steal it").
ב-28.9.2026 פרסם מאמר ארוך ב-X: "How I Make $10K Launch Videos for $0 with Opus 5.5 (Full Course)" — זה המאמר שעליו מבוסס העמוד. הוא מכיל 6 שלבים, 3 פרומפטים מלאים, ו-7 "חוקי יוקרה". לפי סיכום עצמאי של המאמר, הוא נחתם בהמלצה על רשת יוצרים/אפיליאייט להפצה — חלק שלא הופיע בגרסת הטקסט שעליה עבדנו.
| הפרומפט | פורמט | מה מיוחד בו |
|---|---|---|
| UI Morph (הוויראלי) | 1440×1440 · 0:14 · 120BPM | צורה אחת שעוברת 14 מצבי ממשק, לופ מושלם |
| הזמנת אוכל | 1920×1080 · 0:15 · 130BPM | סיפור משתמש: בקשה → תוצאה → פעולה |
| "Develop" — הדפסת תמונות | 1440×1440 · 0:27 · 120BPM | "זכוכית נוזלית", צמצם מצלמה, פוטג' אמיתי; ~106K צפיות |
| Beat-synced footage | 1920×1080 · 10 תיבות | קליפים אמיתיים מסונכרנים לביט, קרוסלה תלת-ממדית |
| Landing-page fly-over (בונוס) | 1440×1152 · 14.5s | WebGL תלת-ממדי, עומק שדה, מצלמה ממהירות |
המאמר — בתרגום מלא לעברית
נאמן למקור. השמטתי רק שתי שורות של "שמרו בסימניות / תנו לייק". הפרומפטים נשארים באנגלית (כדי להדביק) ומתחתם תרגום. מונחים טכניים מוסברים בסוגריים במקום הראשון שבו הם מופיעים.
איך אני מפיק סרטוני השקה של 10 אלף דולר ב-0 דולר עם Opus 5.5 (הקורס המלא)
אני פותח בקוד פתוח את כל תהליך העבודה שלי ליצירת עיצובי תנועה (motion design — אנימציה גרפית: טקסט, צורות וממשקים שזזים, בניגוד לצילום) שסטודיואים גובים עליהם 5,000 עד 15,000 דולר.
זה משתמש ב-0 MCP (Model Context Protocol — דרך לחבר לקלוד כלים חיצוניים כמו שירותים ואפליקציות), ב-0 כלים חיצוניים, ואני לא מוכר לכם שום מנוי. לא צריך After Effects (תוכנת האנימציה המקצועית של Adobe) או שום תוכנת עריכה — קלוד בונה את כל הדבר בקוד.
למטה כל שלב: איך אני מוצא את הרעיון, איך אני מנסח את הפרומפט, ואיך זה הופך למוצר מוגמר — באפס מאמץ, כשקלוד מטפל בכל התהליך. כל פריים בודד כאן הוא קוד ש-Opus 5.5 כתב, ואני לא מכיר אפילו את שלב 1 של מושן דיזיין.
שלב 1: לגנוב את הרעיון
לא צריך להיות יצירתיים בחלק הזה. כל סרטון שעשיתי התחיל ממשהו שכבר קיים: אנימציות ממשק מ-Dribbble (אתר שבו מעצבים מציגים עבודות), קינוט של אפל, אפילו פרומו של אפליקציה של מישהו אחר. אז מצאו סרטון השקה שאתם אוהבים, שמרו אותו ותנו אותו ל-Claude Code (קלוד שרץ בטרמינל/אפליקציה ויכול להריץ פקודות, לכתוב קבצים ולראות תמונות) עם זה:
Extract 2 frames per second from reference.mp4 with ffmpeg and put them on contact sheets. Go through them and break the video into beats: what happens on each beat, how each scene turns into the next, the camera moves, the colors and the fonts. Then write the same structure for my product: [your product + link].
אין רפרנס? בקשו ממנו 3 רעיונות למוצר ובחרו אחד. טיפ אחד: קלוד נוטה כברירת מחדל לסרטונים כהים שנראים תלת-ממדיים, והם עדיין לא נראים יוקרתיים — אז אני דוחף את שלי למראה דו-ממדי, לבן ומינימליסטי. זה מה שבאמת מרגיש פרימיום. אם אתם כותבים פרומפט משלכם, הוסיפו את זה כדי שלא יברח לתלת-ממד כהה:
Style: 2D only. Warm white background, black UI, one accent color, one clean font (Geist or Inter). No 3D, no dark mode, no glows, no particles. Think Apple keynote, not a video game trailer.
שלב 2: להפוך את Claude Code לסטודיו
פתחו את Claude Code והדביקו:
Set up a motion design studio in this folder. Install ffmpeg and Playwright with Chromium. Then render a 2 second test where a black circle grows into a pill on a spring, 60fps, and show me the first and last frame.
זה כל הסטודיו שלכם. Opus כותב קובץ HTML אחד עם פונקציה בשם seek(t) שמציירת כל פריים שתבקשו, Playwright מצלם כל פריים, ו-ffmpeg הופך אותם ל-MP4. כיוון שהכל קוד — אם משהו נראה לא טוב, פשוט אומרים לקלוד והוא מתקן רק את החלק הזה.
שלב 3: להשיג את הנכסים — הכל בחינם
- מוזיקה חינמית: mixkit.co/free-stock-music
- אפקטים קוליים חינמיים: mixkit.co/free-sound-effects
- וידאו ותמונות חינמיים: pexels.com
- פונטים חינמיים: fonts.google.com
- ועוד צילומי מסך והלוגו שלכם.
גם את זה לא מורידים בעצמכם — הדביקו ל-Claude Code:
Download a royalty-free track around 120 BPM with a clear drop from mixkit.co/free-stock-music. Analyze it with numpy and give me the beat grid and the exact time of the drop. Then download one sound effect per event from mixkit.co/free-sound-effects and measure where each one peaks.
תמיד השתמשו באפקטי סאונד אמיתיים — בהתחלה נתתי לו לייצר את שלו, והם נשמעו זול מאוד.
שלב 4: הפרומפטים
אלה הפרומפטים המדויקים שהשתמשתי בהם. הדביקו אחד ל-Claude Code עם Opus 5.5 — הוא ישאל אתכם קודם מה הוא צריך. כולם בנויים באותה צורה: מה לבקש מכם, איך זה צריך להיראות, מה קורה מתי, והטעויות שצריך להימנע מהן. הערה: אלה לא השקות אמיתיות — אלה דמואים שעשיתי כדי להראות מה Opus מסוגל. תעשו להם רמיקס עם המוצר והנכסים שלכם, ולא תוכלו להבדיל ביניהם לבין סרטון השקה של 15 אלף דולר.
שלושת הפרומפטים מופיעים כאן במלואם. מונחים כמו "קפיץ בנוסחה סגורה", "מרחב לוגריתמי" ו"תת-פריימים" מוסברים בהמשך העמוד לעומק, עם מעבדה אינטראקטיבית לכל אחד — אבל כבר בתרגום כל מונח מקבל הסבר קצר במקום.
פרומפט 1 — סרט השקה: הזמנת אוכל (15 שניות, 16:9)
פרומפט 2 — קינוט בסגנון אפל: אפליקציית הדפסת תמונות (27 שניות, ריבוע)
פרומפט 3 — UI Morph: צורה אחת, 14 מצבים (14 שניות, לופ)
שלב 5: מה גורם לזה להיראות יקר
אם לא תגידו לו את הדברים האלה — זה ייראה כמו מצגת פאוורפוינט:
- שום דבר לא נכנס בפייד (התעמעמות) — דברים משנים צורה. כפתור גדל והופך לעמוד הבא.
- אין חיתוכים — כל סצנה יוצאת מתוך הקודמת.
- משהו קורה על כל ביט של השיר.
- דברים קופצים קצת כשהם נוחתים, כמו חפצים אמיתיים.
- המצלמה עושה תנועה אחת בכל פעם.
- לכל קליק ו-whoosh יש סאונד אמיתי.
- הוא בודק את העבודה של עצמו לפני שאתם צופים.
שלב 6: לסגור את זה
כשאתם אוהבים את התוכנית, תגידו לו:
Render the final video in 60fps with motion blur. Put every sound effect exactly on the moment it belongs to, balance the audio, and check every frame for glitches before you show me.
ואז צפו ותנו לו הערות כמו במאי, לא כמו מתכנת: "החלק הזה איטי מדי", "הפייד הזה נראה זול — תגרום לו לשנות צורה", "תגרום לזום להכות על הדרופ". בדרך כלל זה לוקח 2–3 סבבים וסיימתם.
יסוד: מה זה בכלל "וידאו"?
לפני כל טריק — מה הדבר עצמו, פיזית.
וידאו הוא רצף של תמונות סטילס שמוצגות מהר מאוד אחת אחרי השנייה. כל תמונה כזו נקראת פריים (frame). העין והמוח לא מספיקים לראות "קפיצות" בין התמונות, ולכן הם מחברים אותן לתנועה רציפה — כמו ספר דפדוף.
FPS (Frames Per Second) = כמה תמונות מוצגות בשנייה. ב-60fps כל תמונה מוצגת 1/60 שנייה ≈ 16.7 מילישניות. למה 60 ולא 30? כי רוב המסכים מתרעננים 60 פעם בשנייה, ובתנועה מהירה (כפתור שגדל, מצלמה שנדחפת) ב-30fps כל צעד גדול פי 2 והעין מתחילה להבחין ב"מדרגות". המחיר: פי 2 תמונות לייצר.
שימו לב למה שקרה עכשיו: גררתם לפריים 240 — והתמונה הופיעה מיד, בלי "לנגן" את 239 הפריימים שלפניו. זה לא מובן מאליו בכלל, וזה הלב של כל השיטה. בשביל להבין למה, צריך קודם להבין מה מודל שפה עושה טוב.
הטריק המרכזי: להפוך בעיה של פיקסלים לבעיה של קוד
למה זה עובד דווקא עם מודל שפה — ודווקא עכשיו.
יש שתי דרכים שונות לגמרי שבהן AI יכול "לעשות וידאו":
דרך א׳: מודל וידאו (Veo, Sora, Flux Video)
המודל מייצר פיקסלים ישירות — הוא "מנחש" איך התמונה הבאה צריכה להיראות לפי סטטיסטיקה של מיליוני סרטונים. מצוין לצילום מציאותי. גרוע בדברים שדורשים דיוק: טקסט נכון, צבע מותג מדויק, כפתור שנשאר אותו כפתור, תזמון למילישנייה. ואי אפשר "לתקן רק את השנייה הרביעית" — מייצרים מחדש והכל משתנה.
דרך ב׳: מודל שפה שכותב קוד (השיטה הזו)
Claude לא מייצר פיקסל אחד. הוא כותב תוכנה — דף אינטרנט — שמציירת כל פריים. הטקסט מדויק כי הוא טקסט אמיתי. הצבע מדויק כי הוא #FF8F3A. ואם השנייה הרביעית לא טובה, משנים שלוש שורות קוד — וכל שאר הסרטון נשאר זהה בבית.
למה זה מתאים דווקא ל-LLM? מודל שפה הוא, בבסיסו, מכונה שכותבת טקסט — וקוד הוא טקסט עם חוקים חדים. כשהופכים "תעשה אנימציה יפה" ל"תכתוב פונקציה שמחזירה את רוחב הכפתור בזמן t", לוקחים את המשימה מהתחום שבו המודל חלש (ניחוש ויזואלי) לתחום שבו הוא הכי חזק (קוד מדויק, ארוך ועקבי). למה זה פרץ דווקא עם Opus 5.5? אין מדידה ישירה של "יכולת מושן", אבל מה שהקהילה מצביעה עליו הוא חוש תזמון וקצב טוב באופן חריג, ויחד איתו שני דברים שהשיטה דורשת: לכתוב ולתחזק קובץ קוד ארוך בלי לשבור אותו, ולראות תמונות.
| מודל וידאו | קוד שמרונדר (zero) | |
|---|---|---|
| טקסט ולוגו מדויקים | לא אמין | מדויק לפיקסל |
| תיקון נקודתי ("רק שנייה 4") | מייצרים מחדש הכל | משנים שורה |
| סנכרון למוזיקה | מקורב | למילישנייה |
| אותה תוצאה בכל הרצה | לא | כן (דטרמיניסטי) |
| צילום מציאותי, אנשים, טבע | מצוין | רק עם פוטג' אמיתי שמביאים |
וכאן נכנסת המילה seek(t) — הדרך שבה "תוכנה שמציירת פריים" נבנית כך שזה בכלל יעבוד.
seek(t): כל פריים הוא פונקציה טהורה של הזמן
הכלל הטכני הכי חשוב בכל הפרומפטים: "no CSS transitions, no timers, no state between frames".
פונקציה היא מכונה: נכנס ערך, יוצא ערך. פונקציה טהורה היא כזו שאותו קלט תמיד נותן אותו פלט, ושלא תלויה בשום דבר אחר — לא בשעון של המחשב, לא במה שקרה קודם. seek(t) מקבלת זמן t בשניות (למשל 4.2) ומציירת את המסך בדיוק כפי שהוא צריך להיראות ברגע הזה. מכלום. בלי לזכור שום דבר.
<div id="dot"></div>
<script>
const spring = (t, w = 12, z = 0.8) => { if (t <= 0) return 0;
const wd = w * Math.sqrt(1 - z*z);
return 1 - Math.exp(-z*w*t) * (Math.cos(wd*t) + (z*w/wd) * Math.sin(wd*t)); };
window.seek = (t) => { // t in seconds. Nothing else.
const grow = spring(t - 0.5); // starts growing at 0.5s
const w = 44 + (380 - 44) * grow; // circle (44px) -> pill (380px)
dot.style.width = w + 'px';
dot.style.borderRadius = '999px';
};
seek(0);
</script>למה לא פשוט להפעיל אנימציה רגילה ולהקליט? כי אנימציה רגילה (CSS transition, setTimeout, requestAnimationFrame) קוראת את השעון האמיתי: "עברו 300 מילישניות מאז שהתחלתי, אז אני ב-30%". אבל כשמרנדרים, צילום מסך אחד של Playwright לוקח זמן משתנה — לפעמים 40 מילישניות, לפעמים 200. השעון ממשיך לרוץ בזמן הצילום, וכל פריים "נתפס" ברגע אקראי. כשמנגנים את התמונות ב-60fps קבוע, התנועה מקרטעת, מאיצה ומאטה. עם seek(t) אומרים לדף "תהיה ב-t=4.2", מחכים כמה שצריך, מצלמים — ו-t הבא הוא בדיוק 4.2 + 1/60. הזמן של הסרטון מנותק לגמרי מהזמן של המחשב.
מה שראיתם בגרף: הקו של seek(t) ישר לחלוטין (כל פריים מתקדם בדיוק 1/60 שנייה), והקו של הטיימר משונן ומזנק — כי כל פריים "נתפס" אחרי זמן צילום שונה. ועוד שלוש מתנות ש-seek(t) נותנת:
- קפיצה לכל רגע: קלוד יכול לצלם רק את פריים 240 כדי לבדוק את הדרופ, בלי לרנדר הכל.
- רינדור מקבילי: 7 דפדפנים יכולים לרנדר 7 חלקים שונים של הסרטון בו-זמנית (כמו שעשינו ב-EP04 על ה-4090), כי אף פריים לא תלוי בקודם.
- תיקון כירורגי: לשנות את הסצנה של שנייה 6 לא נוגע בשום פריים לפניה.
async seek(t). async = פונקציה שמותר לה "לחכות" לפני שהיא מסיימת — למשל עד שתמונה או פריים של וידאו נטענו. Playwright מחכה שהיא תסיים ורק אז מצלם. בלי זה הייתם מצלמים פריים שבו התמונה עוד לא הופיעה.Easing: למה תנועה "ליניארית" נראית רובוטית
השכבה הראשונה של "טעם" — ואיך היא נראית כמספרים.
נניח שכפתור צריך לזוז מנקודה A לנקודה B בשנייה אחת. הדרך הפשוטה: בכל רגע הוא עבר את אותו אחוז מהדרך שעבר מהזמן (50% מהזמן = 50% מהדרך). זה נקרא ליניארי, וזה נראה מכני — כי שום דבר בעולם לא זז ככה. מכונית מאיצה, נוסעת, ומאטה. יד מרימה כוס, מאיצה, ומאטה לפני השולחן.
Easing היא פונקציה שממירה "כמה מהזמן עבר" (u, בין 0 ל-1) ל"כמה מהדרך עברנו" (גם בין 0 ל-1). בהתחלה בלי נוסחאות — תסתכלו על הכדורים:
עכשיו הנוסחה, אחרי שיש תמונה בראש. easeInOutCubic: עבור u קטן מחצי, 4u³ (מתחיל לאט — u³ קטן מאוד כש-u קטן); עבור החצי השני, 1 − (−2u+2)³/2 (סימטרי: מאט בסוף). easeOutCubic = 1 − (1−u)³: מזנק ומאט — מצוין לדברים ש"נוחתים". easeOutExpo מאט בצורה קיצונית — נראה "מהיר ויקר" אבל בשימוש יתר מרגיש תבניתי.
קפיצים "בנוסחה סגורה" — הסוד של התחושה הפיזיקלית
"Springs are closed-form step responses" — מה כל מילה אומרת, ולמה בדיוק ככה.
אינטואיציה קודם: דמיינו משקולת שתלויה על קפיץ, ואתם מזיזים בבת אחת את נקודת התלייה 10 ס״מ למטה. המשקולת לא קופצת מיד למקום החדש: היא מאיצה לכיוונו, עוברת אותו קצת, חוזרת, ומתייצבת. שני דברים קובעים איך זה ייראה:
- קשיחות (ω, "אומגה"): קפיץ קשיח = תנועה מהירה. ביחידות: תדירות טבעית ברדיאנים לשנייה. ω=12 → מחזור תנודה טבעי של 2π/12 ≈ 0.52 שנייה.
- ריסון (ζ, "זטא"): כמה "חיכוך" יש. ζ קטן מ-1 → עובר את היעד וחוזר (קפיצי). ζ=1 → מגיע הכי מהר בלי לעבור (ריסון קריטי). ζ גדול מ-1 → זוחל, "בוצי".
"Step response" = איך הקפיץ מגיב כשהיעד קופץ בבת אחת ("מדרגה") מ-0 ל-1. "Closed-form" = יש נוסחה שנותנת את המיקום בכל זמן t ישירות, בלי לסמלץ צעד-אחרי-צעד. וזה כל העניין: סימולציה צעד-אחרי-צעד צריכה לזכור את המיקום והמהירות מהפריים הקודם — כלומר "מצב" — וזה שובר את seek(t) (אי אפשר לקפוץ לפריים 240 בלי לחשב 239 לפניו). הנוסחה הסגורה נותנת קפיץ שהוא פונקציה טהורה של הזמן.
x(t) = 1 − e−ζωt · ( cos(ωdt) + (ζω/ωd)·sin(ωdt) ), כאשר ωd = ω·√(1−ζ²).•
e−ζωt — "המעטפת": דועכת עם הזמן, כמה מהר תלוי בריסון כפול קשיחות. זה מה שגורם לתנודה למות.•
cos ו-sin — התנודה עצמה (הלוך-חזור סביב היעד), בתדירות ωd — התדירות הטבעית "מואטת" קצת בגלל הריסון.• הצירוף
(ζω/ωd)·sin נבחר כך שבזמן 0 המהירות היא בדיוק 0 — הקפיץ מתחיל ממנוחה, בלי "בעיטה".• החריגה המקסימלית (overshoot) יוצאת בנוסחה:
e−πζ/√(1−ζ²). ζ=0.8 → 1.5%. ζ=0.6 → 9.5%. וזה מה שהפרומפט מתכוון אליו ב-"a tiny overshoot at most": ריסון של בערך 0.75–0.9."סכום של קפיץ אחד לכל שינוי" — איך היעד משתנה באמצע
בפרומפט: "A value with many targets is the sum of one spring per change, so it stays a pure function of time." סמנו בתיבה "שלושה יעדים" במעבדה. הרוחב מתחיל ב-44, ב-0.0 שנייה מקבל יעד 380, ב-0.35 משנה דעתו ל-200, וב-0.7 ל-300. במקום לזכור "איפה הייתי", מחשבים: ערך = 44 + (380−44)·spring(t) + (200−380)·spring(t−0.35) + (300−200)·spring(t−0.7). כל שינוי מוסיף קפיץ משלו שמתחיל ברגע השינוי. כיוון שכל קפיץ מתחיל במהירות 0 ובמיקום 0, החיבור רציף — אין קפיצה — והתוצאה עדיין פונקציה טהורה של t.
הטריק של "האינדיקטור הנוזלי": שני קצוות, שני קפיצים
בפרומפט ה-UI morph: "The tab indicator's two edges ride different springs, so the leading edge stretches ahead of the trailing one." הפס שמסמן את הטאב הנבחר הוא לא אובייקט אחד שזז — הוא שני מספרים: הקצה הימני והקצה השמאלי. אם הקצה שבכיוון התנועה מקבל קפיץ קשיח יותר מהקצה האחורי, הפס נמתח בדרך ומתכווץ כשהוא מגיע — בדיוק כמו טיפת מים. לחצו על טאבים:
לשנות צורה במקום להעלים: Morph מול Fade
חוק מס׳ 1 ו-2 ב"מה גורם לזה להיראות יקר". למה זה עובד על המוח.
Fade (קרוספייד) = התמונה הישנה נעשית שקופה בזמן שהחדשה מופיעה. באמצע, שתיהן חצי-שקופות אחת על השנייה. Morph = אותו אובייקט עצמו משנה רוחב, גובה, פינות וצבע — עד שהוא הופך לדבר הבא.
למה המוח מעדיף Morph: מערכת הראייה שלנו בנויה לעקוב אחרי אובייקטים לאורך זמן (קביעות אובייקט). כשהכפתור עצמו גדל לעמוד, העין לא מאבדת אותו לרגע — ולכן המוח קורא סיבה-ותוצאה: "לחצתי, והדבר הזה נפתח". בפייד, יש רגע שבו העין רואה שני דברים חצי-שקופים ולא יודעת במה להתמקד; הקשר הסיבתי נשבר והתוצאה מרגישה כמו "שקופית הבאה" במצגת. מכאן "it looks like a powerpoint".
seek(t) גדלה לכרטיס, והכפתור הכתום שבכרטיס הוא זה שמציף את המסך בדרופ — לא צבע שמופיע משום מקום.המצלמה: טרנספורמציה אחת, וזום "במרחב לוגריתמי"
"The camera is one transform on a container... zoom interpolated in log space."
אין באמת מצלמה בדף אינטרנט. "מצלמה" = קופסה אחת שעוטפת את כל העולם, ועליה מפעילים הזזה והגדלה (transform). להגדיל את הקופסה פי 2 סביב נקודה = "זום פי 2 על הנקודה". כל התנועה של המצלמה היא רשימה קצרה של מפתחות [זמן, זום, x, y] וביניהם easing.
למה "לוגריתמי"? זום הוא כפלי: מ-1 ל-2 זה "פי 2", ומ-2 ל-4 זה גם "פי 2" — והעין חווה את שניהם כאותו מרחק. אם מחשבים זום ליניארית מ-1 ל-16, באמצע הזמן הזום הוא 8.5 — כלומר כבר עברנו פי 8.5 מתוך פי 16. העין מרגישה זינוק מטורף בהתחלה וזחילה בסוף. במרחב לוגריתמי (z = a·(b/a)u) באמצע הזמן הזום הוא 4 = √16: מחצית הדרך התפיסתית. המהירות שהעין חווה היא קצב השינוי של ln(z) — וזה בדיוק מה שהגרף מתחת מודד.
- "one move per scene" — תנועת מצלמה אחת לכל סצנה. שתי תנועות בו-זמנית (זום + פאן לכיוון אחר) = העין לא יודעת לאן להסתכל.
- "never zooms in and out back to back" — זום-אין ומיד זום-אאוט נראה כמו מצלמה שלא החליטה. בסרטון למעלה: המצלמה נדחפת פנימה לפני הדרופ, ואת החזרה ל-1 היא עושה בזמן שההצפה הכתומה מכסה את כל המסך — שינוי מצלמה על משטח בצבע אחיד הוא בלתי נראה. זה טריק עריכה קלאסי.
- "Never put will-change on anything the camera scales" —
will-changeאומר לדפדפן "צלם את האלמנט הזה כתמונה ותזיז את התמונה". כשמגדילים תמונה כזו — הטקסט מטושטש. בלעדיו הדפדפן מצייר את הטקסט מחדש בכל גודל, חד.
המוזיקה היא השעון: BPM, ביטים, דרופ וסאונד לפי שיא
"Something happens on every beat" — ואיך מחשב "שומע" את הביט.
BPM (Beats Per Minute) = כמה פעימות בדקה. 120 BPM = 2 פעימות בשנייה = ביט כל 0.5 שנייה. תיבה (bar) = 4 ביטים. דאונביט = הביט הראשון בתיבה, החזק. דרופ = הרגע שבו אחרי בנייה כל הכלים נכנסים בבת אחת — שיא האנרגיה.
ברגע שיודעים את ה-BPM, כל תכנון הסרטון הופך לטבלה: ביט 0 — זה קורה, ביט 1 — זה. בגלל זה הפרומפטים מדברים בביטים ולא בשניות. בדקתי את המספרים שלו — הם מדויקים:
איך numpy "שומע" את הקצב — שלב אחרי שלב
הפרומפט אומר "Analyze it with numpy and give me the beat grid". מה קורה מתחת לפני השטח (אני מריץ כאן בדפדפן בדיוק את האלגוריתם הזה, על שיר שמסונתז עכשיו):
- מה זה קובץ שמע: רשימה ארוכה של מספרים בין −1 ל-1 — מיקום הממברנה של הרמקול. 22,050 מספרים לכל שנייה.
- מעטפת אנרגיה: חותכים לחלונות של 256 דגימות (~12 מילישניות) ומחשבים בכל חלון RMS (שורש ממוצע הריבועים) = "כמה חזק" בחלון.
- Onset ("התחלת צליל"): לכל חלון — בכמה הוא חזק יותר מהקודם (רק עליות). תוף שמכה = קפיצה חדה. זה הופך את השיר לרשימת "דפיקות".
- אוטוקורלציה: מזיזים את רשימת הדפיקות על עצמה בהיסטים שונים ובודקים מתי היא הכי "מתלכדת" עם עצמה. אם יש דפיקה כל 0.5 שנייה, ההיסט של 0.5 שנייה נותן את ההתאמה הכי גבוהה → 120 BPM. (מעדיפים קצב קרוב ל-120 כי אחרת האלגוריתם עלול לבחור חצי או כפול.)
- פאזה: יודעים כל כמה, צריך לדעת מתי — מחפשים את ההיסט ההתחלתי שבו הרשת נוחתת על הכי הרבה דפיקות.
- הדרופ: מחשבים אנרגיה ממוצעת לכל ביט ומחפשים את הביט עם הקפיצה הגדולה ביותר ביחס לשני הביטים שלפניו.
אפקט סאונד "לפי השיא הנמדד" — הפרט הקטן שעושה את ההבדל
בפרומפט: "Place each so its measured peak, not its file start, lands on the event." לקובץ של "ווש" יש התחלה שקטה שעולה עד שיא — הרגע שהאוזן שומעת כ"הנה!". בקובץ שלנו השיא נמצא 0.42 שנייה מתחילת הקובץ. אם מנגנים את הקובץ ברגע הדרופ, השיא מגיע 0.42 שנייה אחרי הדרופ — כמעט ביט שלם באיחור, והאוזן מרגישה שמשהו "לא נוחת". הפתרון: למדוד איפה השיא, ולהתחיל את הקובץ ב-זמן האירוע − זמן השיא.
loudnorm הוא פילטר של ffmpeg שמביא את כל הסרטון לעוצמה נמדדת קבועה. −14 LUFS הוא יעד נפוץ לפלטפורמות סטרימינג — כך הסרטון לא יישמע חלש מכל השאר בפיד, וגם לא "יוחלש" אוטומטית.מושן בלר מתת-פריימים: למה 4 משאיר "רוחות רפאים" ו-8 לא
"8 subframes per frame blended with ffmpeg tmix" — כל מילה, כל מספר.
הבעיה: מצלמה אמיתית פותחת את התריס לפרק זמן (למשל חצי מזמן הפריים — "תריס 180°"). מה שזז בזמן הזה נמרח בתמונה. זה ה"מושן בלר", והמוח רגיל אליו כל כך שבלעדיו תנועה מהירה נראית "מגמגמת" ומלאכותית. אבל צילום מסך של דפדפן הוא רגע אחד אינסופית קצר — אפס מריחה.
הפתרון: לכל פריים סופי, מצלמים N "תת-פריימים" בזמנים צפופים בתוך חלון התריס, ומחשבים ממוצע פיקסל-פיקסל. ממוצע של 8 מיקומים קרובים של עיגול = עיגול מרוח. ffmpeg tmix הוא בדיוק פילטר שממצע N פריימים רצופים.
למה 4 לא מספיק בתנועה מהירה: המרחק בין שני תת-פריימים הוא מהירות × זמן תריס ÷ N. אם המרחק הזה גדול מהאובייקט עצמו — העותקים לא נוגעים זה בזה, ורואים 4 עותקים שקופים נפרדים: "ghost copies". הפרומפט אומר "use 8 and slow the move down" — שתי הדרכים להקטין את אותו מספר.
ופקודת ה-ffmpeg — בדקתי אותה בפועל לפני שכתבתי אותה כאן: יצרתי 24 תת-פריימים מלאכותיים ווידאתי שכל פריים יוצא הוא הממוצע של 8 התת-פריימים שלו ולא מערבב שכנים:
# 60 fps × 8 subframes = 480 images per second of film ffmpeg -framerate 480 -i sub_%06d.png \ -vf "tmix=frames=8,select='eq(mod(n\,8)\,7)',setpts=N/(60*TB)" \ -r 60 -c:v libx264 -pix_fmt yuv420p -crf 16 video.mp4
tmix=frames=8 ממצע כל פריים עם 7 שלפניו. select='eq(mod(n,8),7)' שומר רק כל פריים שמיני — את זה שהממוצע שלו מכסה בדיוק קבוצה שלמה. setpts מסדר מחדש את חותמות הזמן ל-60fps. גוטצ'ה מהסקיל של Howseen: לעולם לא ממצעים על פני חיתוך קשה — אחרת שתי סצנות נמרחות זו לתוך זו.
"It checks its own work": בקרת איכות שקלוד עושה לבד
החוק השביעי — והסיבה שהתוצאה לא נראית כמו "פרומפט אחד ותקווה".
כל פרומפט שלו נגמר ב-<start> שמחייב: לפני כתיבת הסרט המלא — מפת ביטים ו-4 סטילס לאישור. ואחרי הרינדור — שתי בדיקות: פריים אחד לכל ביט, וסריקת "pops".
בדיקה 1: גיליון מגע — פריים אחד לכל ביט
זה בדיוק מה שקלוד "מסתכל" עליו. הנה הגיליון של הסרטון מלמעלה, מחושב עכשיו מאותה seek(t) — פריים בכל חצי שנייה:
בדיקה 2: סריקת "pops" — תקלה של פריים אחד
Pop = פריים בודד שבו משהו קופץ למקום לא נכון ומיד חוזר (שכבה שהופיעה מוקדם, משתנה שלא הוגדר). ב-60fps העין קולטת את זה כ"הבהוב" מעצבן, אבל קשה מאוד למצוא אותו בצפייה. האלגוריתם: לכל זוג פריימים רצופים מחשבים הפרש ממוצע בין הפיקסלים. בתנועה חלקה ההפרש משתנה לאט. Pop יוצר זינוק — פי 3 ויותר מהשכנים — בדיוק כמו שכתוב בפרומפט: "frame-difference spikes 3x their neighbours".
הצנרת המלאה: מקובץ HTML ל-MP4
עכשיו, כשכל חלק מוגדר, אפשר לראות את כל השרשרת.
import { chromium } from 'playwright';
const FPS = 60, SUB = 8, SHUTTER = 0.5, DUR = 9; // seconds
const browser = await chromium.launch({ args: ['--use-angle=d3d11', '--enable-gpu', '--ignore-gpu-blocklist'] });
const page = await browser.newPage({ viewport: { width: 1920, height: 1080 } });
await page.goto('http://localhost:8000/film.html');
await page.evaluate(() => document.fonts.ready); // never shoot before fonts load
let i = 0;
for (let f = 0; f < DUR * FPS; f++) {
for (let k = 0; k < SUB; k++) { // subframes spread across the shutter
const t = f / FPS + (SHUTTER / FPS) * ((k + 0.5) / SUB - 0.5);
await page.evaluate(t => window.seek(t), t); // may be async (images, video)
await page.screenshot({ path: `out/sub_${String(i++).padStart(6, '0')}.png` });
}
}
await browser.close();המספרים בכפתורים לקוחים מהרינדורים האמיתיים שלנו בפרויקט: בסביבת הענן (CPU בלבד) הגענו לכ-7 פריימים בשנייה; על RTX 4090 ביתי, 7 workers במקביל, כ-6 לשנייה כל אחד. תת-פריימים מכפילים את העבודה — לכן בטיוטות מרנדרים בלי מושן בלר וברזולוציה נמוכה, ומושן בלר רק במאסטר.
אנטומיה של הפרומפט: 6 בלוקים, ולמה כל אחד עובד על LLM
כל הפרומפטים שלו בנויים בדיוק באותו שלד. לחצו על בלוק.
בונוס: פרומפט ה-Fly-over התלת-ממדי
אותו שלד בדיוק — אבל כאן הוא שובר את חוק ה"2D only" שלו, ובכוונה.
הפרומפט המלא + תרגום
מה חדש כאן לעומת שלושת הקודמים:
1. מצלמה שמונעת ממהירות — לא ממיקומים
"Drive the camera from one speed curve, never from a position key every half second... Integrate it into the page position." במקום לומר למצלמה "ב-0.5 שנייה תהיי ב-y=300, ב-1.0 ב-y=700", מגדירים כמה מהר היא נוסעת בכל רגע, ומסכמים (אינטגרציה) את המהירות לאורך הזמן כדי לקבל מיקום. למה? כי כשמחברים מיקומים בעקומה חלקה, המהירות בין המפתחות "גלית" — מאיצה ומאטה סביב כל מפתח. העין מרגישה את זה כגלישה שנתקעת וקופצת ("stops or surges in the glide" — ברשימת האסור). כשמתחילים מהמהירות, היא שטוחה בדיוק כמו שהגדרתם.
2. עומק שדה (Depth of Field) אסימטרי
"blur radius = 75 × (focus − depth) / depth in front of the focus and 6 × (depth − focus) / depth behind it, capped at 120px". עומק שדה = כמה מהתמונה חד. בעדשה אמיתית, מה שקרוב מאוד לעדשה מיטשטש הרבה יותר מהר ממה שרחוק — וזה מה שנותן תחושת "מקרו", מיניאטורה יקרה. המקדם 75 מלפנים מול 6 מאחור (פי 12.5) יוצר בדיוק את זה: הדף שליד העדשה "נמס", מה שמאחורי הפוקוס כמעט חד.
3. שלושה פרטים הנדסיים שמסבירים "למה זה נראה זול אצלי"
- Mipmaps + סינון אנאיזוטרופי 16x: טקסטורה (תמונת הדף) שנראית בזווית חדה ורחוק מתכווצת להרבה פחות פיקסלים ממה שיש בה. בלי הכנה, כל פריים "דוגם" פיקסלים אחרים ← טקסט רחוק מהבהב (shimmer). Mipmaps = גרסאות מוקטנות מראש של התמונה; סינון אנאיזוטרופי = דגימה שמבינה שהתמונה נמתחת יותר בכיוון אחד (בגלל הזווית).
- "drawn lowest first with no depth buffer": מציירים מהשכבה הנמוכה לגבוהה, כמו צייר שמצייר קודם רקע ("אלגוריתם הצייר"). בלי depth buffer כי השכבות שקופות בחלקן, ו-depth buffer לא יודע להתמודד עם שקיפות.
- "fade them into the haze colour first": כרטיס שנעשה שקוף חושף את מה שמאחוריו — ובתלת-ממד זה נראה כמו "רוח". קודם צובעים אותו לצבע האובך של הרקע (הוא "נבלע" באוויר), ורק בסוף חותכים לשקיפות.
--use-angle=d3d11) ו-16 תת-פריימים לפריים — כלומר רינדור על מחשב מקומי, לא בענן. 14.5 × 60 × 16 = 13,920 צילומים. (2) הוא מתחיל ב"open my link" — הוא מצלם את דף הנחיתה האמיתי שלכם, ולכן כל שינוי בגובה של סקשן בדף מזיז את כל התזמון ("lock the page before timing anything").מה אפשר להבין מזה — כולל מה מוגזם
השיטה מצוינת. הכותרת שלה — פחות.
| הטענה | מה נכון | מה מוגזם / חסר |
|---|---|---|
| "$0" | אין צורך ב-After Effects או בסטוק בתשלום. | Claude עצמו עולה (מנוי או טוקנים). מקור אחד מדווח ~90K טוקני קלט + 15K פלט לסרט ≈ 0.66$ במחיר מחירון — לסרט אחד, לפני סבבי תיקון, רינדור וזמן שלכם. |
| "0 effort" / "לא יודע שלב 1 במושן" | לא צריך ידיים של אנימטור. | הפרומפטים מלאים בידע מקצועי עמוק (תריס 180°, זום לוגריתמי, קפיצים אנליטיים, LUFS). הידע לא נעלם — הוא עבר לפרומפט. מי שמשנה את הפרומפטים בלי להבין אותם — שובר אותם. |
| "פרומפט אחד" | פרומפט אחד מניע את התהליך. | בפועל: רפרנס → נכסים → מפת ביטים → סטילס → רינדור → 2–3 סבבי הערות. גם יוצר אחר (@rexan_wong) שבדק סרטונים כאלה הגיע למסקנה ש"פרומפט אחד" הוא בעצם תהליך עבודה. |
| "לא תוכלו להבדיל מ-$15K" | הדמואים באמת ברמה גבוהה. | אלה דמואים בסגנון אחד שהוא אהב (2D, לבן, אפל). סטודיו מוכר גם אסטרטגיה, קופי ותהליך מול לקוח. הטענה היא שלו, לא נמדדה. |
| "הכל חינם ב-Mixkit/Pexels" | יש שם ספריות חינמיות גדולות. | ל-Mixkit יש רישיון נפרד לכל סוג פריט (מוזיקה, SFX, וידאו "חופשי" מול "מוגבל"). ל-Pexels יש מגבלות על אנשים מזוהים ומותגים. חובה לבדוק כל קובץ לפני פרסום מסחרי. |
איך אנחנו מאמצים את זה מעכשיו — YUV.AI Motion Method
מה כבר יש לנו מ-EP01–EP06, מה משתנה, והפרומפט שלנו.
| רכיב | מה עשינו עד היום | מעכשיו |
|---|---|---|
| מנוע | GSAP timeline מושהה / render(t) (EP01, EP04) | אותו רעיון, אבל קפיצים אנליטיים וכלל "אפס מצב" קשיח. GSAP מושהה בסדר — כל עוד אין טיימרים |
| שעון | מילים של הקריינות (Scribe/Whisper) | שני שעונים: קריינות לכתוביות, ביטים למעברים. האירוע המרכזי על הדרופ |
| מעברים | whip/slice/flash cuts (EP03) | Morph + shared element בסצנות. כתוביות קצרות עם חיתוך קשה נשארות — זו שכבה נפרדת |
| מצלמה | punch-zoom בכל קאט (EP03 אנכי) | תנועה אחת לסצנה, זום לוגריתמי, איפוס מתחת להצפה |
| סאונד | SFX ממוקמים בתחילת אירוע; לפעמים מסונתזים (EP02) | SFX אמיתיים, לפי שיא נמדד; ducking מתחת לקריינות; −14 LUFS (כבר יש) |
| מושן בלר | אין | 6–8 תת-פריימים + tmix, רק במאסטר |
| QA | contact sheets, audit.py לקריאות | + פריים לכל ביט, סריקת pops, בדיקת RTL |
| תהליך | "תעבוד עד הסוף בלי לשאול" | שער אחד זול: מפת ביטים + 4 סטילס לפני הסרט המלא (אפשר לאשר אוטומטית אם לא זמין) |
הפרומפט שלנו — בשלד של zero, מותאם לעברית, RTL והמותג
yuv-motion) כך שלא צריך להדביק כלום — ולפני שבונים מאפס, לבחון את howseen-ai/claude-motion-design: סקיל קוד-פתוח (MIT) שבנוי על אותם עקרונות, כולל render.py, סריקת pops וזיהוי דרופ, שנבנה בהשראה ישירה מהפרומפטים של zero. אפשר לקחת ממנו את המנוע ולשים מעליו את השכבה שלנו (עברית, RTL, מותג, מצלמה על ה-4090).מקורות
כל הקישורים נבדקו כחיים ב-15.10.2026.