Quattro chiacchiere con Ken Perlin

Non con troppa frequenza (ed è un peccato) qui in Funcom ospitiamo talvolta alcune personalità importanti della industry. Questo mercoledi abbiamo avuto davvero l’onore di accogliere Ken Perlin, professore della New York University, eminente luminare della animazione procedurale. Non voglio sciorinare tutto ciò che ha fatto, perchè la lista è davvero lunga, mi permetto di citare solo che ha vinto un Oscar per meriti tecnologici per il film TRON, tanto caro al Future Film Festival in quanto primo film con effetti digitali, e ha modellizzato con successo un tipo di rumore, il Rumore di Perlin per l’appunto, che viene usato al giorno d’oggi per creare le rappresentazioni digitali di fumo e nuvole. Se siete interessati a tutti i lavori di Ken Perlin, la sua home page si trova qui http://www.mrl.nyu.edu/~perlin/, tuttavia una banale ricerca su Google vi condurrà attraverso magnifici risultati.

La conferenza di Ken Perlin è stata davvero affascinante, incentrata soprattutto sull’animazione procedurale. Mi limito a dire che è stata stupenda perchè preferirei invece scrivere qui che cosa si nasconda dietro questo complicato termine.

Parliamo di un problema canonico nella realizzazione di videogiochi, ovvero la rappresentazione dell’alter ego del giocatore e in generale di tutte le altre creature presenti nel mondo virtuale. Ci sono due modi, spesso mischiati: animare manualmente i modelli e usare il motion capture.

Animare manualmente i modelli è concettualmente semplice, si assume un animatore, gli si da il modello 3D da animare e dopo alcuni giorni di intenso lavoro avremo a disposizione una serie di animazioni specifiche per quel modello 3D. Ovviamente questo va ripetuto per ogni modello disponibile nel gioco, aspetto che, in caso di mancanza di una corretta prototipizzazione dei modelli, può portare al consumo di una quantità di risorse economiche e umane enorme. Il motion capture è una tecnica relativamente recente, si tratta in pratica di collegare un computer a un attore in carne e ossa che eseguirà alcuni movimenti corrispondenti alle animazioni che si vogliono appunto “catturare”. Il computer registra i movimenti grazie ad alcuni sensori riflettenti e mette a disposizione degli animatori un insieme di dati già pronti che corrispondono alle animazioni eseguite dall’attore. Con questi dati un animatore, anche non troppo bravo, può ottenere degli ottimi risultati. Il motion capture richiede meno competenze dell’animazione interamente manuale, ma richiede un sacco di tempo e soldi (specie perchè l’equipaggiamento per il motion capture non solo non è economico, ma bisogna anche saperlo usare).

Con i procedimenti di cui sopra si ottengono delle animazioni, singole. Qui cominciano i problemi, però. E’ irreale e ingenuo pensare che un personaggio virtuale eseguirà una sola azione alla volta. E’ molto più probabile che debba passare da una “azione” all’altra. Tanto per fare un esempio, un personaggio virtuale corre, dopo un po’ il gioco prevede che questo si fermi per riprendere fiato, poggiando le mani sulle ginocchia e ansimando un po’.

Qualcuno potrebbe osservare che basta creare una animazione specifica per questo, ma io rispondo che quella è una scelta estremamente ingenua. Che cosa succede se si vuole allungare la corsa? O il tempo per cui il personaggio riprende fiato? Una scelta del genere è statica e inflessibile, non è adatta a sistemi molto dinamici come i videogiochi.

Per rendere l’uso delle animazioni dinamico, si presuppone quindi che un personaggio possa essere “interrotto” durante la sua animazione corrente perchè deve cominciarne un’altra. Nel nostro caso, il personaggio sta eseguendo l’animazione “correre” che viene interrotta da “rallenta” e infine da “riposa”. La soluzione più banale al problema è eseguire le animazioni in sequenza, ma questo ci riporta ai problemi statici di prima, tutto il sistema sarebbe dipendente dalla durata delle animazioni scelte, quindi l’impressione del giocatore sarebbe quella di avere un sistema che segue sue temporizzazioni interne, poco prevedibili e insensate. Un’altra soluzione è quella di interrompere istantaneamente l’animazione corrente e cominciare immediatamente quella nuova. Il vantaggio di questa soluzione è l’impressione di risposta immediata che viene data al giocatore: il sistema reagisce esattamente quando necessario. Purtroppo però implementare questa soluzione ha un orribile difetto visivo: i personaggi virtuali interromperebbero istantaneamente ciò che stanno facendo, di fatto “scattando” direttamente in una nuova posizione che potrebbe non avere nulla a che vedere con ciò che stavano facendo prima.

Qual è la soluzione adottata nei giochi moderni quindi? La soluzione si chiama Blending, ovvero “miscelamento di transizione”. Le animazioni che devono essere eseguite “in sequenza” vengono dotate di una animazione intermedia generata dal Blending per fare in modo che non ci sia nessuno “scatto”, del tutto irreale, nell’animazione. La soluzione è bella e funziona molto bene ma ha un piccolo problema: è costosa sia in termini di tempo (bisogna fare del blending per ogni coppia di animazioni che si vuole rendere compatibili l’una con l’altra) che in termini di risorse umane (fare del buon blending richiede esperienza e personale esperto).

Nonostante l’efficienza del Blending sia bassissima, è l’unica soluzione disponibile industrialmente al momento. Fortunatamente persone come Ken Perlin stanno facendo ricerche interessantissime nel campo della animazione procedurale, ovvero nella creazione di personaggi virtuali che sappiano “automaticamente” come comportarsi a seconda degli ordini che vengono impartiti loro. Non voglio addentrarmi in argomenti eccessivamente tecnici, ma vorrei dare almeno un sentore di significato a tutto questo.

In informatica gran parte dei sistemi sono imperativi, ovvero l’uomo dice alla macchina esattamente come vuole che si comporti. Se ad esempio voglio che un personaggio si muova in un certo modo, lo fornisco di specifiche animazioni e gli dico di eseguirle. Questo è un approccio imperativo.

Esiste però un numero più circoscritto di componenti procedurali in cui l’uomo non dice alla macchina come si deve comportare ma solo che cosa vuole ottenere. La macchina esamina il risultato voluto e cerca di raggiungerlo autonomamente senza ricevere istruzioni precise sul COME raggiungere l’obiettivo. Ora, è chiaro che qui c’è della disonestà, è ovvio che le macchine non imparano da sole come fare, ovvero i componenti procedurali sono in realtà fatti di componenti imperativi, tuttavia la ricerca di persone come Ken Perlin si avventura proprio in questo campo: fornire componenti procedurali che possano essere usati in maniera rapida ed efficace.

Nell’ambito specifico delle animazioni, Ken Perlin si sta specializzando nel fornire componenti procedurali che permettano di muovere un qualsiasi personaggio virtuale dalla vita in giù, specializzandosi quindi primariamente nel movimento delle gambe e dei piedi. Con uno strumento del genere non è più necessario registrare animazioni specifiche, nè lanciarsi in massacranti sessioni di blending: è sufficiente dire al proprio personaggio che cosa vuole che faccia, il resto verrà gestito dall’animazione procedurale che tramite parametri davvero semplici da gestire può davvero spaziare all’infinito in quanto a variabilità, molto più di qualsiasi animazione registrata in maniera imperativa.

Mi scuso per la lunghezza della dissertazione, ma è solo per fare capire ai lettori meno tecnici l’importanza degli studi di Perlin.

Veniamo a un po’ di risate tutte norvegesi, giusto per fare capire che razza di barbari siano i nordici per certe cose. Una illustre società norvegese convoca un grande professore americano. I solerti dipendenti tra cui il sottoscritto dopo la conferenza lo portano in giro per l’ufficio e infine lo invitano a cena. L’allegro web designer austriaco, amico personale di Perlin, che ha invitato il professore è un vegano, così come Ken.

Domanda, dove porterai a mangiare un ospite illustre? MA E’ OVVIO! Nello schifosissimo indiano take away da cui ordiniamo la scroccocena! Sono rimasto esterrefatto, sono andati su internet, hanno visto che nel menu c’era “qualcosa che possiamo mangiare” e hanno deciso di andare lì, abbiamo preso la metro per andare in centro (pieno COSI’ di locali di ogni tipo) e siamo andati in una schifosissima trattoriazza indiana di sesta categoria che fa anche takeaway (la scroccocena era chiusa)…

Non ci potevo credere. Poi però ho visto che gli stranieri di cibo non capiscono un accidente e mi sono spiegato molte cose, tutti gli altri al tavolo tranne me e i francesi si stavano leccando i baffi di fronte alle “delizie” del ristorante di Giggi l’Indiano de Trastevere. Fortunatamente la serata era tutta incentrata sull’ospite, alla fine il luogo dove andare a mangiare era davvero irrilevante.

Pensierino della sera: quando finisci le frasi di uno come Ken Perlin, i casi sono due: o sta dicendo cose ovvie, oppure magari proprio scemo scemo non sei.

🙂

Annunci

2 Risposte to “Quattro chiacchiere con Ken Perlin”

  1. Mitch Says:

    Molto interessante, bel post, potrebbe essere l’editoriale di un giornaletto di videogames how-to. Esclusi gli ultimi tre paragrafi ovviamente.

  2. osloninja Says:

    Ho cercato di non entrare in alcun modo nelle problematiche tecniche, si potrebbe ovviamente entrare nello specifico affrontando il tema in maniera estremamente più rigorosa.

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...


%d blogger hanno fatto clic su Mi Piace per questo: