Tripo AI: come controllare rigging e animazioni in Blender con Claude
Creo un gioco con l'AI: 52 boss di un RPG fatti con Tripo AI, rigging e animazioni in Blender. Li controllo frame per frame con uno script scritto da Claude.

Sto creando un gioco con l'AI. Nell'articolo precedente ho messo alla prova la modellazione 3D con AI: ho usato Tripo AI (spesso chiamato anche Tripo 3D) per trasformare il concept della statua in un modello 3D, poi uno script Blender per ridurre i poligoni, fare il rigging e animarla. Quella volta era un mostro solo. Poi ho ripetuto lo stesso processo con il boss di ogni capitolo dell'RPG che sto progettando: 52 in un colpo solo.
Solo alla fine ho capito che il problema vero veniva dopo. Da fermi erano tutti bellissimi. Ma appena agitavano l'arma o tiravano un colpo pesante, sulla spalla compariva una lunga striscia di colore stirata, il pugno girava troppo e mostrava il taglio, e i motivi della texture si riducevano a macchie di colore. 52 boss, cinque o sei animazioni a testa, decine di frame per animazione: controllarli a occhio in Blender, uno per uno, era impossibile.
Così con Claude Opus ho messo in piedi un "flusso di controllo dei boss": prima un programma misura, frame per frame, dove il modello di Tripo AI si rompe dopo il rigging, poi fotografa il frame peggiore e me lo fa vedere. In questo articolo lo ripercorro tutto con il boss del capitolo 8, l'"Esploratore Spora".
Il boss d'esempio: l'Esploratore Spora
L'Esploratore Spora è un fungo alto e smilzo di 2,4 metri: un cappello arancione appuntito con tre macchie gialle che sembrano occhi, sotto una faccia con gli occhi socchiusi e un ghigno furbo, una mantellina verde muschio, un cannocchiale di legno intagliato sulla schiena e, nella mano destra, un bastone ricurvo con una lanternina appesa.
Il concept: Claude lo progetta dalla trama, Codex genera l'immagine
Chiedo a Claude di leggere la trama di ogni capitolo e di progettare un boss adatto a quella parte della storia. Poi è lui stesso a scrivere il prompt e a passarlo a Codex CLI, che chiama gpt-image per generare l'immagine, con un personaggio già presente nel gioco come riferimento di stile. L'Esploratore Spora compare nel capitolo della foresta, alla guida di un gruppo di soldati fungo, quindi Claude l'ha pensato come un fungo esploratore allampanato, con macchie sul cappello che sembrano sorvegliare tutto intorno. Il prompt che ha scritto è questo:
Character: SPORE SCOUT (孢子斥候), a 2.4 m forest boss: a tall thin long-legged mushroom scout that leads mushroom soldiers; eye-spots on its cap.
A tall lanky chunky KayKit-style mushroom: a tall narrow conical cap in rusty orange with three big painted eye-spot markings (rings of yellow around black dots), a long thin pale stem body with a sly face (two small glowing yellow eyes and a narrow grin), long thin arms and long stilt-like legs ending in flat root feet. Gear: a scout's short hooded cloak in moss green over the shoulders, a leather bandolier strap with buckles, a spyglass of carved wood strapped on the back, wrapped leather cloth bands on the shins, holding a long thin walking stick with a small glowing spore bulb in one hand down at its side.I prompt di Claude hanno sempre tre livelli: prima una frase che dice chi è il personaggio, quanto è alto e cosa fa nella storia; poi la forma (cappello, corpo, faccia, braccia e gambe); infine l'equipaggiamento (mantella, cinghia, cannocchiale, fasce sulle gambe, bastone). Più è preciso, meno volte Codex deve rifare l'immagine, e in più resta una lista da spuntare voce per voce quando lo confronto con il modello.
In tutto il processo io intervengo pochissimo. Quasi sempre faccio solo review: guardo se il design è coerente con la trama e se l'immagine ha lo stile giusto. Se qualcosa non va, gli chiedo di cambiarlo.
Tutti i prompt sono salvati in file, nella pagina di anteprima di cui parlo più avanti. La scheda di ogni boss ha un link "prompt", così posso sempre tornare a vedere cosa era stato chiesto.
È un ottimo esempio perché ha tutti i problemi possibili:
- Braccia e gambe sottili: quando si piegano, le parti sottili sono le prime a strapparsi.
- Il bastone: l'arma deve restare in mano, ruotare con il pugno e non attraversare il corpo.
- Il cappello grande: è attaccato a un gambo sottilissimo; se la testa si inclina, la giunzione può aprirsi.
- Tanti piccoli dettagli: le macchie, le cuciture a X delle fasce, le fibbie della cinghia. Sono le prime cose a sparire con la riduzione dei poligoni e la colorazione.
Prova 1: il file GLB e il concept, uno accanto all'altro

La prima prova è la più semplice, ed è anche quella che si salta più spesso: mettere il concept e il modello finito uno accanto all'altro.
Ho chiesto a Claude Opus di creare una pagina web di confronto (con three.js per leggere il file GLB): a sinistra il concept che ho dato a Tripo, a destra il modello 3D così come lo carica il gioco. Da un menu a tendina si passa tra idle, camminata, attacco, colpo pesante, colpo subito e caduta, e con il mouse lo si fa ruotare. I 52 boss sono tutti nella stessa pagina: un clic e si apre, senza dover aprire Blender ogni volta.
Qui si guarda il quadro generale:
- Silhouette: proporzioni, altezza e forma del cappello.
- Accessori: se ci sono la mantella, la cinghia, il cannocchiale sulla schiena e la lanternina del bastone.
- Arma: se il bastone è in mano e se attraversa il corpo quando si muove.
- Luci: se gli occhi e la lanternina brillano ancora.
Prova 2: rigging e animazioni in Blender, ogni angolazione e i frame chiave di ogni animazione

La pagina di confronto serve a capire se "sembra giusto", ma i problemi a metà animazione spesso durano un attimo. Per questo, ogni volta che lo script Blender ricostruisce il modello, renderizza anche una tavola riassuntiva:
- Quattro angolazioni: fronte, lato, retro e tre quarti, per verificare che anche schiena e fianchi siano completi.
- Mappa dei pesi di Blender: un colore per osso, per vedere quale osso muove ogni parte della mesh. I cambi di colore devono cadere sulle articolazioni; se il colore del braccio sconfina nel petto, quando alza la mano si porta dietro anche il petto.
- Frame chiave: per ogni animazione, i frame di massimo sforzo, come l'attacco che punta in avanti, il colpo pesante con il bastone alzato accanto alla testa a disegnare un cerchio, il cappello che sbatte a terra nella caduta.
Con un'immagine sola vedo tutte le animazioni di un boss, molto più in fretta che trascinare avanti e indietro la timeline di Blender.
Prova 3: Claude scrive uno script Blender Python che misura frame per frame dove si rompe

Guardando le immagini qualcosa sfugge comunque, quindi la terza prova la fa un programma. Ho chiesto direttamente a Claude di correggere il problema, e lui ha scritto da solo uno script di audit in Blender Python: apre il modello, scorre ogni frame di ogni animazione, lo confronta con la posa a riposo e misura questi problemi:
Cosa misura | Che problema indica |
|---|---|
Spigoli strappati | Uno spigolo stirato fino a più volte la sua lunghezza; a schermo è una striscia di colore tirata o una punta |
Facce schiacciate | Una faccia compressa fino a non avere quasi più area; capita spesso all'interno delle articolazioni |
Facce ribaltate | La faccia si gira sul retro e nel gioco si vede un buco |
Giunture aperte | Lo spazio tra un pezzo tagliato (pugno, arma) e il corpo si allarga |
Rotazione dell'osso | Un osso ruota oltre 110 gradi; di solito vuol dire un'animazione troppo esagerata |
Dopo la misurazione, lo script sceglie il frame peggiore e lo fotografa da quattro angolazioni (fronte, tre quarti, lato e retro in diagonale), più un primo piano del punto peggiore. L'ultima immagine è una mappa di calore: più è rosso, più è stirato. Mi basta guardare questa immagine per sapere se il problema è nella spalla, nel polso o sotto il cappello.
C'è poi una soglia: se in un qualsiasi frame di attacco o colpo pesante ci sono più di 8 spigoli strappati o più di 30 facce schiacciate, oppure vertici che nessun osso muove o frammenti staccati che fluttuano fuori dal corpo, lo script non esporta il GLB. Un modello rotto nel gioco non ci arriva proprio, non serve aspettare di accorgersene giocando.
Il risultato del primo audit dell'Esploratore Spora:
- Pugni: agitando il bastone, il pugno ruotava da 150 a 180 gradi, e tra il pugno tagliato e il braccio si vedeva il taglio.
- Caduta: cadendo, il cappello si inclinava troppo e l'anello del gambo sottile sotto di lui si apriva: 6 spigoli strappati.
La soluzione è stata infilare una "sfera di giunzione" nel polso, così quando il pugno ruota troppo nel taglio si vede la sfera, come negli snodi delle action figure; e dimezzare l'inclinazione del cappello nella caduta. Dopo la correzione: attacco 0, colpo pesante 1, caduta 0; idle, camminata e colpo subito tutti a 0. Soglia superata.
Prova 4: backface culling, a caccia di buchi da dietro e in primo piano

Per motivi di prestazioni, il gioco disegna solo il lato della mesh rivolto verso l'esterno. Un modello che in Blender sembra completo, nel gioco può risultare vuoto da qualche angolazione.
Per questo c'è un'altra immagine con il backface culling attivo, renderizzata come fa il gioco: fronte, lato, retro, dall'alto e dal basso, più i primi piani del viso e del pugno. Quella dal basso è particolarmente importante: le pieghe sotto il cappello e la giunzione del gambo non vengono quasi mai inquadrate, e se c'è un buco salta fuori all'improvviso in qualche cutscene.
Prova 5: bake delle texture, la texture 4K di Tripo è uguale al concept?

Le prime quattro prove guardano la "forma", l'ultima guarda il "colore".
I modelli generati da Tripo AI hanno texture 4K piene di dettagli. Ma nel mio primo flusso, per alleggerire il modello, riducevo i colori di tutto il boss a 8 blocchi di colore. Risultato: le macchie sul cappello diventavano una chiazza gialla, le cuciture a X delle fasce sparivano e le fibbie della cinghia si impastavano.
Nella seconda versione sono passato a una "texture completa": il modello già ridotto viene riaperto in UV in Blender, e ogni pixel cerca il punto più vicino sul modello originale di Tripo per prenderne il colore. In pratica si fa il bake dei dettagli della texture 4K. Nell'immagine, sopra ci sono i vecchi blocchi di colore e sotto la nuova versione: tornano le pupille nere delle macchie, le cuciture delle fasce e le fibbie della mantella, quasi identici al concept a sinistra.
Il prezzo è da 0,2 a 0,5 MB in più per boss. L'Esploratore Spora è passato da 1,19 MB a 1,56 MB: su smartphone resta leggero.
Problemi comuni del rigging in Blender e come risolverli
Dopo aver passato l'audit su tutti e 52, i problemi erano sempre quelli:
Problema | Come si vede | Soluzione |
|---|---|---|
Transizione troppo stretta sull'articolazione | Il braccio ruota e sulla spalla compare una striscia di colore stirata | Far cambiare i pesi dello scheletro gradualmente vicino all'articolazione e aggiungere un "osso di supporto" che si prenda parte della rotazione |
Riquadro della zona fissa troppo largo | Quando si muovono l'elmo o l'asta sulla schiena, il bordo del riquadro si apre | Restringere il riquadro e lasciare un po' di sfumatura sul bordo |
Ascella legata alla vita | Alzando la mano, la vita trattiene l'ascella | Abbassare il centro della transizione della vita |
Taglio del pugno in vista | Il pugno ruota troppo e si vede la sezione tagliata | Infilare una sfera di giunzione |
Residui in vista alzando il braccio | Spuntano frammenti del corpo che il braccio copriva | Dopo il rigging, eliminare i residui sotto il braccio |
Dettagli cancellati dai blocchi di colore | Spariscono motivi, cuciture e rivetti | Passare alla texture completa |
Conta anche l'ordine delle correzioni: prima quelle economiche (dimensione dei riquadri, ampiezza della transizione), poi quelle costose (cambiare l'ampiezza dell'animazione, ritagliare di nuovo i pezzi). Alcune modifiche sembrano sensate e invece peggiorano le cose: per esempio, bloccare più pezzi come fissi aggiunge un bordo rigido tutt'intorno, e gli spigoli strappati passano da 4 a 17-51. Per questo dopo ogni modifica bisogna rifare l'audit e lasciar parlare i numeri.
Dopo questo giro, tutti e 52 i boss hanno superato la soglia: 30 senza nessuno strappo, gli altri 22 con appena 1-3 spigoli, invisibili con la telecamera del gioco.
Problemi da evitare prima di generare con Tripo AI
Molti problemi si possono evitare prima ancora di passare l'immagine a Tripo. Ho dato queste regole a Claude, e quando scrive il prompt per far disegnare il concept a Codex le mette sempre in chiaro:
- Posa frontale: gli umanoidi in A-pose con i piedi piatti; i mostri a quattro zampe che poggiano a terra, di fronte, al massimo ruotati di 15 gradi. Solo le creature acquatiche che fluttuano vanno di tre quarti.
- L'arma non copre il corpo: le armi lunghe, come bastoni o righe, stanno dritte accanto al corpo, non di traverso davanti al petto. Altrimenti Tripo incolla arma e corpo in un unico blocco, ed è difficilissimo separarli dopo.
- Ciò che fluttua diventa pieno: fumo e capelli sparsi Tripo li trasforma in un blocco pieno. Io li sostituisco con riccioli di fumo corti attaccati al corpo, e il fumo vero lo lascio agli effetti del gioco.
- I motivi non devono sembrare scritte: fibbie, stemmi e incisioni non devono sembrare lettere o numeri. Le finte scritte generate dall'AI, viste da vicino, stonano parecchio.
- Un solo personaggio per immagine: se carichi l'intera tavola, Tripo fa tutti e tre in un unico modello (mi è successo nell'articolo precedente).
Il mio flusso di controllo dei boss

Alla fine l'ho trasformato in una checklist da spuntare per ogni boss prima di metterlo nel gioco:
- Rispetto al concept: silhouette, accessori e arma ci sono; l'arma è in mano e non attraversa il corpo.
- Nessun frame di idle o camminata ha strappi (sono sempre in riproduzione e si notano di più).
- In attacco e colpo pesante, al massimo 8 spigoli strappati per frame; l'obiettivo è da 0 a 3.
- Nel frame di massimo sforzo del colpo pesante: spalle, ascelle, gomiti, polsi e collo senza strisce stirate o punte.
- Alzando la mano non spuntano frammenti sul fianco e non ci sono pezzetti che fluttuano.
- Con il backface culling nessun buco, soprattutto da dietro, dal basso e nei primi piani.
- Texture: motivi, cuciture e rivetti visibili, e colori nella stessa tonalità del concept.
- Le parti luminose, come occhi e lanterne, brillano ancora.
Conclusione: l'AI misura, la persona guarda
Generare modelli 3D con Tripo AI è veloce: un boss è pronto in pochi minuti. Quello che richiede davvero tempo viene dopo: "verificare che, con lo scheletro e dentro una scena 3D di Godot, non si rompa". Il mio metodo è dividere il lavoro: quello che si può misurare lo misura un programma frame per frame, quello che non si può misurare diventa un'immagine da far guardare a una persona. Lo script Blender scritto da Claude riduce 52 boss e migliaia di frame a una sola immagine del caso peggiore per boss, e a me bastano pochi secondi per guardarla. Per me, la cosa più utile di Blender con l'AI non è modellare, ma proprio questo tipo di controllo ripetitivo che deve essere preciso.
Se anche tu stai generando modelli 3D con l'AI per un gioco e ti sei bloccato sul rigging o sulle animazioni, scrivimi pure nei commenti di un mio post su Threads o su X e ne parliamo.
