PivotCut: portare un progetto personale dal codice a una release pubblica

L'animazione 2D cut-out parte da un'idea semplice: invece di ridisegnare un personaggio intero in ogni fotogramma, si compone il personaggio con elementi separati — testa, torso, braccia, gambe e altri dettagli — e si modifica la posa nel tempo.

È un workflow diretto, particolarmente utile per bozzetti animati, studi di movimento, storyboard, brevi scene e sperimentazione visiva. Ma per essere davvero piacevole richiede strumenti chiari: importare asset non deve creare attrito, costruire una gerarchia deve essere comprensibile e la timeline deve restituire subito il senso dell'animazione.

PivotCut nasce da qui: creare un ambiente focalizzato sul pose-to-pose, con un'interfaccia desktop e un modello tecnico abbastanza solido da non diventare fragile appena il progetto cresce.

La versione attuale è un'app nativa per macOS Apple Silicon. Il nucleo del progetto copre un workflow completo, dalla costruzione della scena fino all'export.

Rig e asset PNG

È possibile importare PNG trasparenti e riutilizzarli nel progetto. Le parti di un personaggio possono essere organizzate in un rig gerarchico: quando si ruota un segmento, i figli seguono la trasformazione del genitore attraverso forward kinematics.

Ogni parte ha pivot, punto di aggancio, posizione, rotazione, scala, ordine visivo, opacità e visibilità. Il Character Rig Builder serve a costruire e modificare questa struttura senza dover alterare i file PNG originali.

Timeline e pose

L'animazione è organizzata come sequenza di pose. La timeline mostra miniature renderizzate dalla scena reale, permette di aggiungere, duplicare, eliminare e riordinare i frame e supporta FPS ed exposure.

In questa fase non c'è interpolazione automatica tra pose: ogni posa rimane visibile per il numero di frame video definito dall'exposure. È una limitazione intenzionale dell'MVP, ma anche una scelta che mantiene il comportamento semplice e prevedibile.

Layer, camera e parallasse

Oltre ai personaggi, una scena può contenere layer di background, midground e foreground. Una camera virtuale salvata per frame controlla posizione e zoom, mentre i layer più lontani reagiscono con una parallasse minore.

Questo non trasforma PivotCut in un motore 3D: resta un modello 2D con profondità semplificata. Però è sufficiente per aggiungere movimento e leggibilità a una composizione senza introdurre shader, prospettiva o infrastruttura inutile.

Export

L'app può esportare una sequenza PNG e, quando FFmpeg è installato, un video MP4 H.264. La sequenza PNG preserva la trasparenza; l'MP4 usa invece uno sfondo opaco, perché il formato di encoding scelto non conserva il canale alpha.

Un progetto creativo può sembrare un candidato naturale per il classico approccio “prima faccio funzionare l'interfaccia, poi sistemo il resto”. Per PivotCut ho scelto il percorso opposto: separare presto il dominio dell'applicazione dalla GUI.

Il modello di progetto — frame, rig, ossa, layer, camera, asset e operazioni sulla timeline — non dipende da Qt. Questo rende la logica testabile senza avviare l'interfaccia e impedisce che gli oggetti grafici diventino accidentalmente la fonte di verità dei dati.

La UI PySide6 traduce le interazioni dell'utente in operazioni sul dominio. Il canvas può essere ricostruito dal modello, la timeline può rigenerare le sue miniature e l'export può renderizzare una scena senza dipendere dalla finestra principale.

Perché questa separazione conta

Quando un editor cresce, le eccezioni arrivano rapidamente: Undo/Redo, salvataggio, caricamento, export, anteprime, riproduzione, asset mancanti e modifiche annullate. Se queste responsabilità vivono tutte nella GUI, ogni feature nuova può trasformarsi in una catena di effetti collaterali difficili da prevedere.

Separare il dominio non elimina la complessità, ma la rende localizzata. Per esempio, la stessa matematica delle trasformazioni può essere usata dal canvas, dal renderer di export e dai test automatici.

In un software di editing, la fiducia dell'utente passa spesso da un gesto banale: poter annullare un errore senza paura.

PivotCut usa un sistema di comandi per operazioni come creare, eliminare, spostare e riordinare frame; creare rig e layer; modificare la trasformazione di una parte; cambiare layer e camera. L'obiettivo non è registrare ogni singolo pixel di movimento, ma catturare un'azione significativa come un unico passo nella cronologia.

Questo dettaglio ha conseguenze pratiche importanti:

• trascinare un osso produce una sola azione annullabile al rilascio del mouse;
• una modifica strutturale nel Rig Builder viene salvata come operazione atomica;
• eseguire una nuova azione dopo un Undo elimina correttamente il ramo di Redo;
• i cambiamenti invalidano solo le miniature che devono essere aggiornate.

Undo/Redo è anche un buon test di architettura: se è difficile implementarlo in modo coerente, spesso significa che le mutazioni dello stato sono troppo disperse.

La parte più difficile di un progetto indipendente non è aggiungere idee. È scegliere quali idee non implementare ancora.

PivotCut ha limiti dichiarati: niente inverse kinematics, niente tweening automatico, niente audio, niente selezione multipla, niente shader, niente prospettiva 3D e nessuna sincronizzazione automatica delle modifiche strutturali tra le pose.

Questi limiti non sono nascosti. Sono parte del perimetro della release. Dichiararli permette di evitare due errori comuni: vendere una promessa troppo grande e rendere l'architettura più complessa prima che esista un reale bisogno.

L'app supporta forward kinematics: ruotando un braccio, avambraccio e mano seguono la gerarchia. Per un MVP questo è un comportamento chiaro, testabile e già utile. Un solver IK richiederebbe invece scelte di UX, vincoli, casi limite e manutenzione che meritano una fase dedicata.

Avere il codice su GitHub non equivale ad avere un prodotto distribuibile. Per trasformare PivotCut in qualcosa che un'altra persona possa provare servono almeno tre livelli distinti: build, distribuzione e comunicazione.

1. Build ripetibile

La build per macOS viene prodotta con PyInstaller. Lo script di build verifica l'ambiente, controlla l'architettura arm64, esegue i test e genera il bundle .app. Una build ripetibile riduce il rischio di distribuire un risultato creato per caso solo sulla macchina di sviluppo.

2. Distribuzione chiara

La prima destinazione pubblica scelta è itch.io. Anche se viene associato soprattutto ai giochi, itch.io è utile anche per strumenti creativi e software indipendente: offre una pagina di progetto, screenshot, descrizione, commenti, versioni scaricabili e un contesto adatto a chi prova progetti sperimentali.

La release viene presentata correttamente come app macOS per Apple Silicon, non come software universale. L'onestà sui requisiti evita una cattiva esperienza a chi usa un Mac Intel o si aspetta una versione Windows.

3. Comunicazione dei vincoli

La build iniziale non è ancora firmata né notarizzata. Questo significa che macOS può richiedere un'apertura manuale tramite click destro e “Apri” al primo avvio. Inoltre FFmpeg resta opzionale, ma necessario per generare MP4.

Sono dettagli tecnici, ma fanno parte dell'esperienza del prodotto. Pubblicarli chiaramente nella pagina di download è molto meglio che lasciare l'utente davanti a un messaggio di sicurezza o a un export non disponibile senza spiegazione.

Pubblicare una prima build non significa fingere che il progetto sia concluso. Significa dare al software una forma verificabile fuori dal proprio ambiente di sviluppo.

Una release iniziale permette di osservare domande concrete: il setup è comprensibile? La terminologia è chiara? Il Rig Builder risulta naturale? Le persone cercano feature diverse da quelle previste? L'export soddisfa il caso d'uso reale?

Queste risposte non arrivano soltanto dalla pianificazione. Arrivano quando qualcuno scarica l'app, prova a creare una scena e racconta dove si è fermato.

Per questo una prima release pubblica di PivotCut non è il traguardo finale. È il momento in cui il progetto smette di essere solo una codebase e diventa un prodotto che può ricevere feedback.

La direzione non è aggiungere tutto subito. Le priorità sono rendere l'esperienza più affidabile e più facile da provare.

• Preparare una distribuzione macOS più rifinita, con firma, notarizzazione e packaging dedicato.
• Creare esempi di progetto e asset demo per ridurre il tempo necessario al primo risultato visibile.
• Raccogliere feedback sul workflow di rigging, timeline ed export.
• Valutare le feature successive in base all'uso reale, non soltanto a una lista di desideri.
• Continuare a migliorare documentazione, onboarding e messaggi di errore, perché sono parte integrante del prodotto.

Il principio resta semplice: costruire strumenti che funzionino oggi e siano mantenibili domani. Per un progetto indipendente, sostenibilità tecnica e chiarezza del perimetro non sono dettagli secondari: sono ciò che rende possibile continuare a migliorarlo.