\articolo{Phenomena: Moduli di animazione particellare per Real 3D}{Alessandro Tasora}
%\commento{Nota che in questo articolo ho messo io i titoli --Reinhard }

\paragrafo{Introduzione}
\noindent In questi ultimi cinque anni si sono susseguiti avvenimenti incessanti e
significativi nel mondo della grafica 3D, ed è noto che proprio ai computer
della serie \A si può attribuire il merito di aver reso accessibili a
chiunque i risultati delle ricerche accademiche più sofisticate.

Passando in rassegna i software che compongono il firmamento della grafica
3D per il nostro calcolatore, osserviamo come ognuno di loro si sia distinto
per un merito specifico, e abbia a suo tempo rappresentato un balzo in
avanti per determinati aspetti innovativi.

Si pensi, a questo proposito, alle primissime animazioni con Videoscape, ai
primi esperimenti di ray-tracing con Sculpt, o all'introduzione del  brush
mapping con Turbo Silver.

Tuttavia coloro i quali, come il sottoscritto, avevano la fortuna di veder
funzionare su Silicon Graphics i programmi di animazione high-end più potenti,
rimanevano colpiti dalle possibilità offerte da questi ultimi e sognavano di
poter disporre, un giorno, di analoghi strumenti anche sul proprio \A.

Difatti proprio sotto il versante dell'animazione si segnalava il ``gap
tecnologico'' più evidente rispetto alle workstation, mentre per quanto
riguarda la qualità di rendering disponevamo di algoritmi già
sufficientemente evoluti.

Così, col passare del tempo, maturai l'idea di realizzare un programma 3D il
quale raccogliesse tutte le funzioni che, da utente semi professionale,
avrei desiderato di poter disporre sul mio \A.

Naturalmente, per l'eccessivo impegno necessario, abbandonai presto l'idea
di programmare ex-novo un intero modellatore, sebbene tre anni fa arrivai a
completare un editor simile a Imagine, ma privo di rendering e modellazione
avanzata.


\paragrafo{Real 3D}
\noindent La presentazione della versione 2.0 del software Real 3D, meno di due anni
fa, ha rappresentato per me un  evento decisivo, in quanto mi avrebbe
consentito di realizzare, tramite il linguaggio di programmazione interno,
tutto quello che avrei voluto vedere in altri software e che mai ho trovato
implementato nel migliore dei modi.

Inoltre rimasi subito colpito dalla potenza delle funzioni di base di questo
programma, che difatti utilizzo tuttora per lavoro, nonché dalla sua
architettura flessibile e innovativa.

Perciò, dopo qualche mese di apprendistato con il linguaggio RPL, ho subito
iniziato a programmare nuovi metodi di animazione, soffermandomi in
particolar modo sulla ``particle animation''.

Sebbene non esista una definizione univoca di ``particle animation'', ricordo
che si tratta di un tipo di animazione nella quale sono coinvolti numerosi
oggetti, perlopiù di piccole dimensioni, al fine di simulare fenomeni fisici
come eplosioni, fiamme, fumo e liquidi discretizzando gli stessi in
``particelle''.

Ovviamente è impensabile animare manualmente le centinaia di particelle che
simulano, ad esempio, un getto d'aqua. Da ciò nasce l'esigenza di metodi di
animazione alternativi ai tradizionali ``key-frame'', ``path'', ``morph'', ecc.

Storicamente la prima soluzione a questo problema fu proposta da Reeves,  il
quale associava a ogni oggetto-particella un'``età'', una massa e un
vettore velocità; in questo modo egli poteva realizzare animazioni complesse
semplicemente inserendo specifiche formule di fisica meccanica, che
gestivano automaticamente il movimento delle particelle nonché la loro
cancellazione non appena superavano una determinata età. Ad esempio per far
cadere un getto d'acqua a terra era necessario scrivere l'equazione del
campo gravitazionale.

Evidentemente questo procedimento richiede che l'operatore abbia conoscenze
non banali di fisica, e soprattutto non risulta né intuitivo né
particolarmente produttivo.

Il software Real 3D consente di gestire le animazioni particellari tramite
formule, il che permette in verità la massima personalizzazione delle
stesse, ma è un metodo che si scontra con le esigenze di immediatezza e
facilità d'uso.



Ho passato questi ultimi mesi a osservare come i potenti software per
Silicon Graphics offrano un'interfaccia agevole per l'implementazione di
funzioni di animazione particellare, soffermandomi in particolar modo sul recente
programma della {\az Alias-Wavefront}, che fa proprio di questo tipo di animazione
un punto di merito.

Ho raccolto le idee più brillanti e, con tutte le limitazioni del caso, ho
cercato di implementarle su Real 3D. Se per certi versi sono incorso nei
limiti della macchina (non sarà possibile il preview in real-time, fino a
quando non ci sarà un'\A-RISC) e nei limiti del software (in particolare
il modulo di rendering delle perticelle è ancora in fase di completamento
alla {\az RealSoft}), d'altra parte ritengo di aver inserito nei miei metodi di
animazione alcuni concetti rivoluzionari, probabilmente inediti in qualsiasi
categoria di computer.

È vero che Phenomena non dispone ancora di tutti i parametri che
accompagnano i migliori programmi per Silicon Graphic, ma per certi punti di
vista l'architettura risulta all'avanguardia per flessibilità e possibilità
di personalizzazione.

Nasce spontaneo un confronto con analoghi prodotti low-end, per \A e PC.

Per Imagine e Lightwave esistono già alcuni programmi di animazione
particellare, certamente più collaudati e stabili del mio, ma non ho trovato
molti spunti innovativi nelle loro architetture. Probabilmente i loro limiti
sono più imputabili ai programmi ai quali si interfacciano, e questo spiega
perché non ho mai preso in considerazione l'idea di convertire Phenomena per
Imagine (seppure con la prospettiva di allargare il target dei probabili
futuri clienti).

Ho stimato che la scrittura di Phenomena per Imagine avrebbe richiesto circa
il doppio del tempo impiegato per la versione Real 3D, se non il triplo.

Lightwave è più ``aperto'' di Imagine, ma continuo a nutrire certe
perplessità sulle sue scelte progettuali, pertanto mi riservo di prendere in
considerazione una conversione solo dalla 5.0, mentre sarebbe più fattibile
una conversione per Solid Thinking (NextStep) alla luce di un recente
scambio di idee con i programmatori.

Per quanto concerne 3D Studio, software esistente solo per PC e che sta
conoscendo una grande diffusione di pubblico, vanno evidenziati alcuni
dettagli. Innanzitutto esistono già numerosi moduli prodotti da terze parti
(chiamati IPAS) che creano animazioni particellari. Nella maggior parte
possiedono algoritmi di rendering dedicati, magari veloci ed efficaci, con
interfacce graziose, ma sul valore delle animazioni generate ho decisamente
parecchi dubbi. Ho trovato decisamente poco flessibili questi programmi,
che spesso tendono a fornire risultati stereotipati. Per di più ho scoperto
che nella maggior parte dei casi non si fa uso di vere leggi fisiche, ma di
loro approssimazioni (sia per semplificare i calcoli, sia per un'errata o
approssimativa modellizzazione del fenomeno dinamico). Non ho intenzione di
convertire Phenomena per questo software perché la sua filosofia d'uso e
la sua architettura si scontrano con i principi di programmazione che mi
sono imposto di seguire.

Phenomena dispone di algoritmi in parte già ben collaudati, talvolta
efficaci oltre le mie aspettative, ma necessita ancora di molto beta-testing
e del perfezionamento di alcune funzioni che per ora sono troppo primitive.
Alcune funzioni sono per ora solo sulla carta, e vedranno la luce in seguito.

In futuro verrà dedicato un certo sforzo per migliorare la velocità di
calcolo: anche se fin d'ora i tempi di refresh si attestano su valori
accettabili, è possibile intervenire su determinate parti di codice per
aumentarne l'efficienza. Per quanto concerne il rendering in
``2D-post-processing'' delle particelle, conto esclusivamente sulla capacità
e disponibilità dei programmatori della {\az Realsoft}: da essi dipenderà buona
parte del successo di questo progetto.

Tuttavia, anche in assenza di moduli di post-processing per il rendering
custom, è possibile visualizzare ugualmente le particelle tramite il
``rendering engine'' di default (in tal caso è consigliabile che si faccia
uso di sfere o di oggetti semplici, per limitare il consumo di RAM e per
velocizzare il rendering). Ovviamente la presenza di un apposito modulo di
post-processing abbatterebbe di dieci-venti  volte i tempi di rendering e
fornirebbe risultati più realistici (motion blur, particle meta surfaces,
trails, ecc.)


Due sfide, parecchio impegnative, potrebbero entrare prossimamente nei miei
piani di sviluppo:  la simulazione dinamica ``Multibody'' e la simulazione
``FEM-dynamics''.

Mediante la prima si ha un metodo assolutemente generale per simulare il
comportamento dinamico di corpi interconnessi con qualsivoglia vincolo, ad
esempio un albero a gomiti che fa girare bielle, pistoni, valvole,
alternatore, ecc.

Non va confusa assolutamente con l'animazione delle catene cinematiche
(cinematica  inversa), che difatti rappresenta un seplice sotto-caso della
simulazione multibody.  Attualmente esistono solo due o tre programmi
commerciali, principalmente per workstation scientifiche, che facciano
questo tipo di animazione in 3D, e probabilmente si arriva a sei-otto
programmi in tutto il mondo se si includono le sperimentazioni
universitarie. Si può far riferimento ad Adams (di {\az Mechanical Dynamics}) o a
Mechanica (di {\az Rasna Corp.}), oppure a certe funzioni di Dynamation per
Wavefront.

La simulazione FEM-dynamics, invece, riguarda la simulazione del
comportamento di corpi elastici soggetti a forze, inerzie, urti,
sollecitazioni termiche e di altro genere, laddove il corpo si deforma
grazie a un oneroso calcolo matriciale. Esistono molti software,
principalmente per workstation HP-PA RISC, SUN, IBM Power RISC e Silicon
Graphics, che permettono già di fare queste simulazioni dinamiche. Citiamo i
casi ``eccellenti'' di MSC Nastran, Abacus, LUSAS, Mystro. Tuttavia l'uso di
questi algoritmi è confinato all'ambito scientifico: ad esempio vengono
usati per calcolare le deformazioni di una carrozzeria che impatta contro un
ostacolo, ma non sono ancora stati usati per semplici videoanimazioni,
magari con calcoli meno precisi.

La grande sfida del futuro dell'animazione 3D consisterà proprio
nell'integrazione dei metodi FEM-dynamics con i metodi Multibody, e
magari con le animazioni particellari. Si tratterà della cosiddetta
``animazione dinamica totale''.

Questo richiede sicuramente la presenza di funzioni di calcolo matriciale
evoluto e di integrazione non-lineare, e pertanto un traguardo intermedio
sarà quello di programmare tali funzioni di calcolo numerico in RPL.

Sicuramente i grossi calibri del 3D (Alias e Wavefront) convergeranno verso
questo obiettivo nel giro di qualche anno; io mi accontenterei di qualcosa
di equivalente, anche se molto più semplificato, anche per \A.


\paragrafo{Il FORTH}
\noindent Prima di affrontare i dettagli più tecnici riguardo la programmazione di
Phenomena, è il caso di dare qualche informazione riguardo il  FORTH, il
linguaggio che è stato scelto dai programmatori del Real 3D come ``dialetto''
del programma stesso.

Altri software hanno scelto altre strade, ad esempio l'Autocad ha scelto una
derivazione del Lisp, il Solid Thinking un'emulazione del C, altri ancora
hanno definito ex-novo un linguaggio per l'occasione.

Charles Moore, astrofisico presso il National Radio Astronomy Observatory,
inventò nel 1968 il linguaggio FORTH, contrazione di ``Fourth generation
language'', con lo scopo di fornire al programmatore uno strumento flessibile
e orientato alla risoluzione di problemi scientifici.

Fra le caratteristiche salienti di questo linguaggio ricordiamo l'estrema
sinteticità e la velocità di esecuzione coniugate alla possibilità di
strutturare in modo molto logico ed efficiente gli algoritmi (difatti è
lasciata al programmatore la scelta di scrivere codici più orientati alla
macchina o all'uomo, con i casi estremi in cui il FORTH viene usato quasi
come macroassembler o come parser di formule in sintassi LISP).

Tuttavia la scelta di adottare la notazione RPN (Reverse Polish Notation) ha
ostacolato parecchio la diffusione di questo linguaggio in ambienti non
accademici, sebbene tale sintassi rispecchi meglio il funzionamento della
macchina e trovi una buona accoglienza in ambienti ingegneristici.

Il software di modellazione e animazione tridimensionale Real 3D è dotato
al suo interno di un compilatore per il linguaggio FORTH, ribattezzato RPL
da ``Real Programming Language'', tramite il quale si ha accesso alle
funzioni più sofisticate del programma.

È stato scelto questo linguaggio per una sua peculiare caratteristica: nel
FORTH non esistono ``procedure'' bensì ``word'' create a partire da un set di
istruzioni-base. Ogni nuova istruzione creata, a partire dalle preesistenti,
non fa altro che ampliare il vocabolario di ``word''. Assemblando
istruzioni sempre più complesse si giunge a creare il programma definitivo,
consistente di una sola istruzione di alto livello. Ogni volta che viene
definita una ``word'', questa viene compilata e può essere subito utilizzata
nella shell, coniugando l'immediatezza di un linguaggio interprete come il
Basic con la velocità di un linguaggio compilato. In tal modo ogni nuova
funzione può essere subito testata, ad esempio provandone l'effetto in una
vista wireframe aperta di fianco alla shell di programmazione.

Ovviamente vengono fornite alcune librerie di istruzioni che ampliano il
kernel di base aggiungendovi le word per la manipolazione di oggetti,
materiali, animazioni.

Grazie ad alcune di queste librerie create dalla {\az Realsoft}, è consentito
perfino accedere alle strutture più remote del Real 3D; ad esempio è
possibile spostare le finestre aperte o modificare il contenuto dei loro
gadget.

Il linguaggio RPL dispone di istruzioni per comandare il sistema operativo
di \A (per
aprire nuovi task, eseguire funzioni DOS, ecc.), si interfaccia
perfettamente con la porta ARexx e dispone di un parser per la valutazione
di stringhe in sintassi LISP-like grazie al quale, per fare un esempio, è
possibile usare una shell di programmazione come una potente calcolatrice.

Fra le tante librerie ce n'è una di particolare importanza: è quella che
riguarda i calcoli vettoriali. Tale libreria si è rivelata di vitale
importanza per l'implementazione delle leggi fisiche che stanno alla base
delle animazioni particellari di Phenomena.

In particolare, nella scrittura di certe funzioni vettoriali, ho constatato
l'estrema sinteticità raggiungibile grazie alla sintassi e alle funzioni
RPL, laddove altri linguaggi avrebbero richiesto parecchie linee di codice.
Tuttavia l'aver condensato complesse equazioni differenziali in poche righe
(perdipiù in notazione polacca) ha parzialmente compromesso la leggibilità
del codice, soprattutto agli occhi dei profani.

Per amplificare ulteriormente la potenza dell'RPL nella manipolazione di
leggi fisiche e meccaniche, ho scritto la libreria \f{Coordsys.Rpl}
dedicata espressamente alle operazioni sui tensori tridimensionali del
second'ordine.

La creazione di metodi di animazione aggiuntivi si riduce, in linea di
massima, alla creazione di una procedura che agisce sugli oggetti da animare
con le dovute funzioni; dopodiché si passa il puntatore di questa nuova
``word'' all'istruzione \c{MTH\_CREATE}, la quale aggiunge il nuovo metodo alla
lista dei preesistenti metodi, in maniera del tutto trasparente e garantendo
la massima integrazione con il resto del software.

Con la versione 3.0 di Real 3D è stata aggiunta un'utilissima libreria per la
creazione di interfacce grafiche. Grazie a essa ho potuto fornire
all'utente alcune finestre di rapida e immediata comprensione, per un
editing accurato dei parametri di animazione più sofisticati (laddove, con
le release precedenti, si doveva ricorrere al fastidioso tag-editing).

Nonostante quasi tutti i metodi siano dotati di interfaccia grafica e
relativi requester, la maggior parte di essi non necessita l'input di
astrusi dati numerici per un corretto funzionamento, in quanto i parametri
più importanti vengono calcolati a partire da oggetti reali disegnati
nell'editor 3D. In parole povere, il metodo che crea spruzzi di particelle
non richiede l'input numerico dell'origine del getto poiché questa viene
calcolata a partire da una linea, da un punto o da una superficie che l'utente può
manipolare comodamente come farebbe con tutti gli oggetti di Real 3D. Lo
stesso principio è stato adottato per il calcolo della direzione del getto,
della sezione dell'ugello, della velocità\ldots Dal momento che i principali
parametri di animazione sono oggetti, essi stessi possono essere animati
tramite ulteriori metodi. Ad esempio il metodo {FAN} utilizza un disco per
definire la direzione del getto d'aria che ``soffierà via'' le paricelle
antistanti: associando a tale disco un semplice metodo {ROTATE}, otteniamo
un ventilatore che ruota sulla sua base, ecc.

Nella progettazione dei moduli di Phenomena ho cercato di sfruttare a fondo i
vantaggi offerti dalla moderna architettura di Real 3D, soprattutto per
quanto riguarda la flessibilità offerta dall'organizzazione object-oriented.
Difatti, grazie alla struttura gerarchica di questo programma, ogni metodo
di animazione è perfettamente combinabile con gli altri per ottenere un
numero infinito di effetti (a differenza della maggior parte dei plug-in di
animazione per altri software, che forniscono effetti di realizzazione
magari immediata, ma decisamente meno configurabili e flessibili).

Per fare un esempio, il metodo {VOLCAN} può creare getti di particelle
qualsiasi ma, non essendoci alcun vincolo sul tipo di particella, anche le
particelle che vengono spruzzate possono essere a loro volta dei piccoli
``volcan''\ldots


\paragrafo{Esempio}
\noindent Per fare un esempio conclusivo delle potenzialità dei metodi di
Phenomena,
osserviamo insieme i passaggi necessari alla realizzazione di una
``semplice'' animazione.

\begin{enumerate}
\item Creiamo un getto di particelle col metodo {VOLCAN}. Usiamo una particella a
forma di proiettile, definiamo un'origine puntiforme per il getto e una
direzione di getto coerente (non conica).

Nella finestra di editing del metodo mettiamo a 160 il massimo numero di
particelle ``sparabili'' prima della fine del caricatore, definiamo una
rapidità di creazione di 15 particelle al secondo, una dispersione ciclica
nulla (nessuna irregolarità nel ritmo di sparo), una continuità di ciclo
massima (niente ``colpi mancati''), ecc.
Inoltre attiviamo la funzione che allinea le particelle lungo il loro
vettore velocità, eventualmente con uno spin longitudinale.

Duplichiamo il metodo, associamo le due copie a un oggetto a forma di
``triplano Fokker'' e animiamo il tutto, ad esempio con un tradizionale
metodo {PATH}.
Avremo ottenuto un ``Barone Rosso sintetico'' che spara dal suo areoplano con
una mitragliatrice bifilare e due caricatori da 160 colpi.
Per definire l'istante in cui inizia a sparare utilizziamo semplicemente le
``timeline'' associate ai due metodi {VOLCAN}.

Si noti che possiamo modificare in qualsiasi istante dell'animazione il
calibro dei proiettili, il loro colore, la loro velocità, ecc., intervenendo
liberamente su questi parametri con altri metodi di animazione.


\item Il metodo {SPLASH} rileva la collisione delle particelle con qualunque tipo di
superficie, e sul luogo dell'impatto crea un piccolo spruzzo di particelle
a forma di ``splash'', appunto.

Tale metodo era stato originariamente concepito per simulare gli spruzzi
d'acqua dovuti alla caduta di sassi, gocce, monete \emph{et similia} in un
contenitore d'acqua. Tuttavia, essendo perfettamente configurabili le
particelle che creano gli ``spruzzi'' (fino al punto da poterne definire di
più tipi, che poi il programma sorteggerà al momento giusto) ed essendo
parametrizzabile anche la forma dello ``splash'', possiamo impiegare questo
metodo per simulare l'impatto dei proiettili contro oggetti che si
sgretolano.

Ad esempio associamo un metodo {SPLASH} al terreno, in modo che le pallottole
che colpiscono il terreno sollevino piccole zolle di terra (utilizziamo a
questo scopo un set di tre o quattro particelle di forma irregolare, colore
verde e marrone come il terreno).

Associando un altro metodo {SPLASH} ai muri di una casa (ma questa volta con
detriti di forma e colore differente) simuleremo l'effetto dell'intonaco che
si sgretola sotto l'impatto dei proiettili.

Operiamo analogamente per altri oggetti presenti nella scena (le finestre si
frantumeranno in schegge di vetro, il laghetto solleverà spruzzi d'acqua,
ecc.)

A questo punto, ovunque noi decideremo di far puntare la mitragliatrice al
Barone Rosso, i metodi di Phenomena simuleranno correttamente gli effetti
dell'impatto coi bersagli.

\item Ovviamente desideriamo che i detriti provenienti dalla frantumazione dei
bersagli cadano a terra e che vi rimangano. A tale scopo utilizziamo i
metodi {GRAVITY} e {BOUNDARY}. Si noti che il metodo {GRAVITY}
presenta una lista di accelerazioni di gravità pre-impostate: oltre
all'accelerazione terrestre possiamo utilizzare quelle di pianeti e
satelliti del Sistema Solare selezionandole da una lista.

\item Qualora le particelle nella scena aumentassero a dismisura,
compromettendo la velocità di refresh o di rendering, possiamo eliminare le
più vecchie, o le più lontane, possiamo porre un limite sul massimo numero
di particelle presenti e così via.
\end{enumerate}

\noindent Si osservi che la creazione di quest'animazione richiede non più di venti
minuti, modellazione degli oggetti esclusa, e che gli effetti raggiungibili
sono estremamente realistici.

\paragrafo{Metodi di animazione}
\noindent Passiamo ora in rassegna i diversi metodi di animazione, analizzandone
sinteticamente le funzioni.


\sottoparagrafo{VOLCAN}
\noindent Crea getti di particelle di ogni tipo, dimensione e forma. Le particelle
possono essere oggetti già animati.

L'origine, la coerenza e la velocità del getto sono definite da oggetti 3D,
in modo da poter creare spray, fuochi d'artificio, esplosioni, scintille,
fontane e altro, semplicemente modificando la forma degli oggetti-parametro.

La finestra di editing consente di intervenire sul numero di particelle al
secondo (o al fotogramma, a scelta), sul massimo numero di particelle a
disposizione, sul massimo numero di particelle presenti sulla scena, sulla
dispersione ciclica, sull'irregolarità (continuità) di getto,
sull'aleatorietà della velocità, sulla massima età prima dell'eliminazione
(con aleatorietà definibile), sulla massima distanza percorribile prima
dell'eliminazone (con aleatorietà definibile sulla distanza), sullo spin
della particella (casuale, entro certi limiti, nullo, particella sempre
allineata alla sua velocità).

È inoltre possibile creare getti di particelle ``miste'', laddove il metodo
sorteggia le particelle da un livello gerarchico comprendente
tutti i campioni di particelle, eventualmente con percentuale di probabilità
differente.


\sottoparagrafo{BOUNDARY}
\noindent Serve a cancellare le particelle quando oltrepassano (collidono) una
superficie arbitraria.
In alternativa si può scegliere che rimangano ``appiccicate'' alla
superficie, per simulare l'effetto di uno spray che vernicia un oggetto.

È possibile definire una percentuale di ``filtraggio'' delle particelle, in
modo che funzioni da setaccio.
Se si muove la superficie di collisione (con qualsiasi altro metodo di
animazione), si muoveranno anche le particelle che si sono già incollate ad
essa. Ad esempio: automobile che passa sotto la schiuma di un autolavaggio.

La rilevazione della collisione è decisamente più veloce di quella di
default di Real 3D.


\sottoparagrafo{GRAVITY}
\noindent Crea un'accelerazione di gravità diretta verso il basso.
Si può scegliere fra le accelerazioni gravitazionali dei pianeti e dei
satelliti del Sistema Solare (quella di default è ovviamente la Terra).


\sottoparagrafo{FAN}
\noindent Genera un effetto ``ventilatore'' che sposta le particelle leggere quando
sono investite dal flusso d'aria. La dimensione, la direzione e la forma del
getto vengono definite tramite oggetti sulla scena, in modo da avere un
``feedback'' visivo della posizione del ventilatore.

L'effetto di trascinamento delle particelle dipende dal peso e dalle
dimensioni della sezione maestra di queste, nonché dal loro CX (coefficiente
aereodinamico isotropo, di default è quello della sfera). È possibile
definire la densità del fluido impiegato per l'effetto (olio, acqua, aria,
ecc.) scegliendo da un set di sostanze comuni.

Tutti questi parametri fisici concorrono a modificare il moto delle
particelle, che così avranno un comportamento meccanicamente corretto (dopo
un transitorio più o meno lungo si adeguano alla velocità del flusso, con un
realismo notevole).


\sottoparagrafo{FLOAT}
\noindent Per simulare l'effetto della Spinta di Archimede dei corpi immersi nei
liquidi. È possibile definire la gravità agente sul fluido scegliendola fra quella
dei pianeti, come nel caso del metodo GRAVITY.

Inoltre si può definire la densità del fluido, dato che con fluidi più densi
il movimento sarà più ``smorzato'' e avrà transitori più lunghi. Per questa
ragione è possibile utilizzare FLOAT anche per simulare l'attrito con
l'aria, ad esempio, delle foglie che cadono da un albero; o la partenza di
una mongolfiera verso il cielo, ecc.


\sottoparagrafo{REFLECT}
\noindent Questo metodo letteralmente ``riflette'' le particelle quando
collidono con una superficie. È possibile intervenire sullo smorzamento
assiale o radiale del rimbalzo, nonché sulla casualità della direzione presa
dopo la riflessione. Ad esempio, usando livelli alti di casualità, si può
simulare l'effetto di una sabbiatrice diretta verso una parete, oppure il
getto d'acqua di una turbina Pelton che si infrange vaporizzandosi contro le
pale appena uscito dal bocchello.

Nel caso si usi un getto di particelle perfettamente coerente e di sezione
ridotta, con una casualità di riflessione nulla, si può simulare tramite
animazione particellare il funzionamento del ray-tracing, con le particelle
che rimbalzano da un oggetto a un altro per rappresentare il percorso dei
raggi luminosi.

Questo metodo consente anche la simulazione della rifrazione.



\sottoparagrafo{SPLASH}
\noindent Crea spruzzi d'acqua (ma anche frammenti di materiale) quando le
particelle collidono contro una superficie arbitraria. L'origine degli
spruzzi coincide con il punto della collisione.

È liberamente definibile il tipo di particella impiegata per simulare gli
spruzzi, come pure è possibile usare più di una particella a questo scopo
(verranno sorteggiate di volta in volta). Questo consente la creazione di
effetti come l'impatto di proiettili su superfici fragili, che si sgretolano
in pezzi di diversa forma e traiettoria.

È possibile intervenire sulle conicità di apertura massima e minima dello
spruzzo, nonché sulla sua potenza, sulla deformabilità e sulla aleatorietà
delle traiettorie dei singoli frammenti.
Ovviamente è possibile definire il massimo numero di frammenti creati per
singola collisione (cioè gocce per singolo spruzzo), e una percentuale di
``filtraggio'' per l'effetto-setaccio.

Data la struttura gerarchica dei metodi di animazione, è possibile impiegare
altre animazioni come particelle-spruzzi; ad esempio si può gettare una
manciata di semi su un terreno e vedere i ciuffi d'erba che nascono
automaticamente dove sono caduti i semi (è sufficiente creare l'animazione
della crescita di un singolo filo d'erba).

\sottoparagrafo{ALIGN}
\noindent Allinea le direzioni principali delle particelle a un riferimento
cartesiano.
Ad esempio nel caso si creasse un gruppo di elicotteri i quali, durante il
volo, dovessero orientare la prua sempre nella stessa direzione.


\sottoparagrafo{DYNAMITE}
\noindent Fa esplodere un oggetto nelle sue sotto-gerarchie, a partire dal peso di
queste, dalla loro dimensione, dalla loro resistenza all'avanzamento
dell'onda d'urto, dalla quantità della carica, dalla posizione di
quest'ultima, dalla massima distanza raggiunta dall'onda d'urto e dalla zona
di massima brisanza.

Questi tre ultimi parametri sono inseriti graficamente nell'editor 3D,
perché consistono di due oggetti sferici.


\sottoparagrafo{SQUISH}
\noindent Deforma un oggetto lungo il suo vettore velocità, in modo che si allunghi
quando è dotato di alta velocità simulando l'effetto ``blur''.
Questo espediente è sovente impiegato dagli animatori dei cartoni animati
per rendere più ``fluido'' e caricaturale il movimento degli oggetti
inanimati (palle da tennis, palloni, ecc.)

In futuro verranno introdotti campi di deformazioni FFD con leggi
non-lineari ed effetti dinamici quali oscillazioni smorzate ipercritiche o
meno.

\sottoparagrafo{JELLY}
\noindent Attualmente serve a simulare vincoli di tipo ``stiff-damper'' fra un
oggetto e il suo path (ma funziona anche con tutti gli altri metodi di
animazione, grazie a una tecnica di backward engineering).

In pratica si immagini l'oggetto collegato al path non rigidamente, bensì
tramite un sistema molla-ammortizzatore: ogni movimento brusco imposto dal
path (o dal ``key-frame'', o dal ``rotate'', o dallo ``sweep'' ecc.) si
tradurrà in un oscillazione più o meno ampia, più o meno rapida a seconda
dei valori di elasticità e smorzamento (nonché dalla massa della particella).
In caso di smorzamento positivo la particella ritorna al suo ``ancoraggio''
sul path dopo un transitorio.

Oltre a simulare correttamente le oscillazione di pendoli e molle, può
essere associato a gruppi di punti di una mesh, in modo da simulare il
comportamento ``gelatinoso'' di muscoli e parti molli del corpo umano in
seguito a movimenti bruschi.
In futuro verrà semplificato l'uso, e probabilmente verrà accorpato con
{SQUISH}.

\sottoparagrafo{STARTER}
\noindent Si consideri di aver creato decine o centinaia di oggetti animati, e
di dover attivare in diversi istanti le diverse animazioni, ad esempio in
sequenza una dopo l'altra. Può essere il caso di decine di fontane (create
tramite metodi {VOLCAN}) che si devono aprire sequenzialmente per creare
suggestivi giochi d'acqua. Oppure il caso di fuochi d'artificio e di giochi
pirotecnici in generale.

È impensabile regolare manualmente, una dopo l'altra, tutte le fasi delle
animazioni, e anche qualora fosse possibile non sarebbe certo una soluzione
produttiva, dato che anche un minimo cambiamento nella coreografia
comporterebbe il rifacimento di tutto il lavoro.

Per risolvere questo problema è stato studiato il metodo Starter.

Un oggetto di forma qualsiasi, associato a questo metodo, ``attiva''
l'animazione degli oggetti non appena li tocca. Ovviamente è necessario
conferire un movimento all'oggetto ``starter'', affinché possa definire la
coreografia, e questo si può fare con un qualsiasi metodo path, sweep,
rotate, ecc.

\sottoparagrafo{FLOW}
\noindent Grazie a questo metodo di animazione si può simulare il comportamento
di getti liquidi che investono superfici di forma arbitraria: il liquido
forma un velo che ``lambisce'' l'oggetto per poi ricadere, attratto dalla
forza di gravità.

È possibile intervenire sul fattore di attrito fluido-superficie nonché su
altri importanti parametri; tuttavia questo metodo è in via di
perfezionamento (soprattutto per raggiungere una corretta simulazione del
flusso su superfici concave).


\sottoparagrafo{TURBOLENCE }
\noindent Permette la simulazione di fumo, fuoco, vento e fenomeni simili.
Interviene sul moto delle particelle con diverse modalità, selezionabili
dall'utente.
Si possono definire vari parametri, fra i quali la scala integrale, la scala
di Kolmogorov, le ottave della funzione di Perlin, ecc.

È possibile definire graficamente, tramite un sistema di riferimento
cartesiano 3D, sia la posizione che il movimento della funzione di
turbolenza. Difatti, deformando tale sistema di riferimento, è possibile
ottenere turbolenze anisotrope.

Il metodo è in via di perfezionamento.


\sottoparagrafo{HYPERSPACE }
\noindent Avendo definito un volume arbitrario nello spazio, quando le
particelle entrano in esso vengono trasportate in un'altra gerarchia (dove
eventualmente possono sussistere diverse leggi fisiche e diversi metodi di
animazione).


\paragrafo{Sviluppi futuri}
\noindent In futuro sono previsti i moduli:

\begin{description}
\item [TRAILS,] dal significato ovvio, utile anche per creare effetti di
effervescenza;
\item[COBRA,] per l'estrusione di un profilo lungo un path in animazione (utile
anche per la creazione di oggetti tipo conchiglie o simili);
\item[ZZZOT,] per la creazione automatica di lampi fra oggetti di differente
potenziale elettrico, durante un'animazione;
\item[TORNADO,] per il movimento di gruppi di particelle, tipo flock animation;
\item[GRAPH,] per plottare i 18 grafici di velocità, spostamento e accelerazione (in
$x$, $y$, $z$ e nei tre angoli di Cardano) di ogni oggetto animato. Utile per
studi di meccanica applicata (studio di accelerazioni di bielle e glifi non
ordinari);
\item[FIREWORKS,] per automatizzare la creazione di esplosioni con scintille;
\item[SIMMETRY,] dal significato piuttosto ovvio.
\end{description}

La strada  da percorrere è ancora lunga, ma i risultati ottenuti fin d'ora
sono incoraggianti e stimolano la ricerca di idee sempre nuove.


\begin{thebibliography}{10}
\bibitem {I} Alan, Mark Watt. \emph{Advanced Animation and Rendering Techniques}.
Addison-Wesley.
\bibitem {II} Foley, Van Dam. \emph{Computer Graphics, principles and
pratice}. Addison-Wesley.
\bibitem {III}Zienkiewicz, R.L. Taylor. \emph{The Finite Element
Method}.
Quarta edizione, Vol.~1, \emph{Basis formulation and linear problems}.
\bibitem {III}Zienkiewicz, R.L. Taylor. \emph{The Finite Element
Method}. Quarta edizione, Vol.~2, \emph{Solid and fluid mechanics, Dynamics and
non-linearity}.
\bibitem {V}J.S. Przemieniecki. \emph{Theory of Matrix Structural Analysis}.
\bibitem {VI}R.D. Cook, M.E. Plesha. \emph{Concepts and applications of Finite Element Analysis}.
\bibitem {VII} Klaus Jurgen Bathe. \emph{The FE Procedures in E.~Analysis}.
\bibitem {VIII}A. Shabana.  \emph{The Multibody simulation}.
\bibitem {IX}Articoli di Computer Graphic World.
\bibitem {X}Articoli e dispense del SIGGRAPH.
\end{thebibliography}

\autore{%
Alessandro Tasora\\
Via Cagliero 4\\
I-20125 Milano MI}
{Internet: atasora@galactica.it}

\citazione{\selectlanguage{english}Sex without love is an empty experience, but, as empty experiences go,
it's one of the best.}{Woody Allen}