Daniel Vedovato
← Blog

ClaudeAnimationBase: creare animazioni con p5.js e controllare il rendering

Un percorso pratico con ClaudeAnimationBase: storyboard, animazione in p5.js, verifica dei fotogrammi ed esportazione MP4, con i limiti del rendering su GPU e CPU.

Newsletter del 23 ottobre 2026

Link originale

Creare un’animazione con un agente di programmazione richiede più della descrizione di una scena: servono una struttura temporale, strumenti per verificare il movimento e un percorso di esportazione. ClaudeAnimationBase propone una base concreta: codice p5.js e p5.brush, un personaggio già predisposto e una guida che accompagna l’agente dallo storyboard al file MP4.

Il valore pratico del repository è questo processo verificabile. È un punto di partenza per chi vuole costruire cartoni animati tramite codice e può lavorare con Node.js, Google Chrome e ffmpeg. La documentazione invita ad aprirlo in Claude Code o in un altro agente di programmazione, ma non dimostra risultati equivalenti tra agenti diversi. Anche l’hardware conta: l’autore segnala che i riempimenti ad acquerello possono rendere lenta l’esportazione senza una GPU dedicata.

Che cosa offre la base di animazione

Il progetto include Clawd, un personaggio con viste, espressioni e movimenti predisposti. La descrizione del repository indica 31 emozioni recitate; il modulo src/clawd.js raccoglie inoltre occhi, bocche, cappelli, gesti e danze. Questo materiale permette di partire da un repertorio visivo esistente, senza progettare ogni elemento prima della prima scena.

L’organizzazione del codice separa responsabilità utili anche durante la revisione del lavoro dell’agente:

La guida ANIMATION_GUIDE.md descrive regole, flusso di lavoro e API. Secondo il README, orienta la produzione verso un’estetica bidimensionale, tratti irregolari in movimento, assenza di testo e transizioni costanti. Sono vincoli artistici del progetto: prima di adottarlo, conviene verificare che corrispondano al linguaggio visivo desiderato.

Dallo storyboard alla verifica dei fotogrammi

Il percorso documentato comincia chiedendo all’agente di leggere la guida e proporre lo storyboard. Segue la costruzione delle singole inquadrature, poi la generazione di tavole di fotogrammi per controllare il risultato e infine l’esportazione in out/video.mp4.

La distinzione tra queste fasi ha una conseguenza pratica: consente di valutare la sequenza narrativa prima di investire nel rendering completo. Come criterio di revisione, lo storyboard dovrebbe rendere chiari l’azione principale, il passaggio tra le scene e il tempo concesso allo spettatore per capire ciò che accade.

Il renderer documentato supporta tavole di fotogrammi, sequenze, ritagli, immagini singole e MP4. Le immagini campionate sono utili per individuare problemi di composizione o pose incoerenti; non bastano, da sole, a giudicare la fluidità temporale. Quest’ultima distinzione è una considerazione tecnica sul metodo di controllo, non un risultato sperimentale del repository.

L’autore riferisce che i video di prova sono stati generati con Opus 5.5, ragionamento xhigh e Claude Code. Le sue osservazioni sulla precisione rispetto alle richieste e sulla ricchezza delle scene restano valutazioni dell’autore: la fonte non presenta un benchmark riproducibile.

Avviare la demo e scegliere il percorso di rendering

Con Node.js, Google Chrome e ffmpeg disponibili, il README indica questi comandi:

npm install
node render.mjs --clip --out=out/video.mp4

Il comando esporta la demo di 11 secondi contenuta in src/scenes/demo.js. Aprendo studio.html in Chrome si può esplorare la sequenza; i parametri ?loop=emotions e ?loop=views mostrano le tavole del personaggio. Se Chrome si trova in una posizione non standard, sono previsti --chrome=<path> e la variabile CHROME_PATH.

La scelta del rendering va verificata sulla macchina effettiva:

ConfigurazioneIndicazione documentataValutazione concreta
Grafica integrataL’autore consiglia di sostituire i riempimenti ad acquerelloControllare se lo stile alternativo conserva la leggibilità delle scene
Nessuna GPU--soft-gl abilita WebGL via softwareMisurare il tempo di un breve estratto prima dell’esportazione completa
NVIDIA su Linux senza interfaccia graficaSono suggeriti --gpu-angle=gl-egl oppure vulkanVerificare quale renderer viene effettivamente selezionato
Chrome fuori dai percorsi standardPercorso esplicito tramite opzione o variabileVerificare l’avvio della demo nell’ambiente scelto

Il comando node gpu_probe.mjs <chrome path> mostra il renderer ottenuto con diversi gruppi di opzioni. È uno strumento diagnostico, non una misura automatica della velocità del video.

Limiti da valutare prima di un progetto completo

Il README descrive tempi nell’ordine dei secondi per fotogramma per i riempimenti ad acquerello senza GPU dedicata. Non specifica però hardware, risoluzione e complessità sufficienti a trasformare questa indicazione in una previsione per altri progetti. Non sarebbe quindi corretto ricavarne una durata garantita di esportazione.

Su Linux, la documentazione segnala inoltre che render.mjs avvia Chrome con --no-sandbox. Questa scelta merita attenzione nell’ambiente di esecuzione, perché disabilita la sandbox del browser; non va interpretata come un dettaglio di accelerazione grafica.

Una valutazione sensata parte da una scena breve ma rappresentativa: stesso tipo di pennellate, densità visiva e movimento del video previsto. I criteri decisivi sono continuità dell’azione, coerenza del personaggio, costo del rendering e facilità di correggere una singola inquadratura.

FAQ

È necessario usare Claude Code?

Il README ammette anche altri agenti di programmazione. I video di prova dichiarati dall’autore usano però Claude Code: la fonte non documenta confronti tra alternative.

Si può esportare senza GPU?

Sì, il progetto documenta --soft-gl per WebGL via software. L’autore segnala lentezza con i riempimenti ad acquerello, senza fornire tempi generalizzabili.

La base è adatta a qualsiasi stile video?

La guida privilegia un’estetica pittorica bidimensionale e impone vincoli come l’assenza di testo. Per esigenze diverse occorre valutare quanto codice e quante istruzioni modificare.