Due sono le cose importanti quando si sta cercando di imparare a padroneggiare Dynamo, l’applicativo di visual scripting per Autodesk Revit programmato da Ian Keough nel lontano 2011: quali sono i package a disposizione, i nomi dei singoli nodi e come collegarli tra loro per ottenere qualcosa non sono tra queste.
Lunedì 6 aprile è in partenza un corso di Dynamo e per l’occasione abbiamo scelto uno specifico ambito di applicazione, ovvero un progetto di interni, ma l’obiettivo del corso è fornire delle basi solide di computational design per riuscire a districarsi in questo mondo non facile.

Docente del corso sarà Paolo Quadrini, istruttore di Dynamo da tempi immemori e uno dei guru italiani sull’argomento: collabora con il reparto consulting di Autodesk dal 2015 e trovate on-line alcune delle sue prodezze, tra cui il lavoro di interoperabilità tra BIM e GIS svolto presso Italferr, una delle punte di diamante sull’argomento, a livello mondiale. A questo indirizzo trovate il caso studio documentato in italiano.
Insieme, nell’arco di 9 lezioni spalmate lungo tutto il mese di aprile, tenteremo di trasferire quelle due cose importanti.
È possibile iscriversi a questo indirizzo: le iscrizioni rimarranno aperte fino a domenica sera.
Ma quali sono queste due cose importanti?
1. Le fondamenta profonde
Uno dei punti di riferimento per chi vuole orientarsi nel mondo di Dynamo è il Dynamo Primer, una risorsa on-line completamente gratuita che con l’uscita della versione 2.0 è stata completamente ricompilata da un altro dei guru di Dynamo a livello internazionale, il buon John Pierson. Si tratta dell’autore del package Rhythm, una dei professionisti più gentili che io abbia mai conosciuto, e lo trovate on-line con il nickname 60secondsRevit.
Il primer è una guida completa, che vi accompagna per mano sin dall’inizio, dai fondamenti della programmazione visuale alla procedura di installazione.
Ciò che il primer non fornisce, e per le quali è necessaria una guida che abbia lo stato mentale di un programmatore, sono alcuni fondamenti di programmazione per i quali non è necessario essere dei programmatori, per i quali potrebbe essere sufficiente avere a disposizione un pochino di logica e dei mattoncini da costruzione.
Dynamo, fino a quando non ci si addentra nella programmazione di nodi personalizzati, consiste nella costruzione di un algoritmo. È necessario innanzitutto conoscere le tipologie di mattoncini che abbiamo a disposizione e comprendere come si combinano tra loro. Una volta comprese le relazioni che i mattoncini possono instaurare tra di loro, le infinita possibilità di Dynamo si apriranno davanti a noi. Senza questa comprensione, saremo solo in grado di ripetere in modo meccanico gli esempi che ci troviamo di fronte.

Tra i mattoncini di cui è più difficile padroneggiare il funzionamento, ne cito solo alcuni:
- le curve (linee, polilinee, archi, cerchi, elllissi, NURBS, policurve… non sono concetti intercambiabili);
- i vettori (quel giorno, a lezione di fisica, io dormivo);
- le liste, senza le quali nulla in Dynamo ha senso.
1.2. Le Curve


1.3. I Vettori

1.3. Liste

Difficilmente si utilizza Dynamo per una singola istruzione su un singolo elemento: lo strumento dà il proprio meglio quando si riesce a creare lo Script Sovrano, l’Unico Script, Uno Script per Controllarli Tutti. E per farlo è necessario padroneggiare le liste.
2. Non come, ma quando
Di questi e molti altri principi si occuperà Paolo. Non fate come me, che ho imparato Dynamo da sola, di corsa, per necessità, con il piede sinistro. È tutto molto più facile se vi fate guidare da qualcuno che sia in grado di fornirvi delle basi rigorose.
Lasciatevi guidare da me, però, se volete provare a capire non solo come si usa Dynamo, ma anche quando.
E soprattutto, quando non si usa.
Dynamo è uno strumento che si utilizza tendenzialmente per tre motivi:
- La volontà di portare avanti operazioni con maggiore precisione (ad esempio piccole variazioni di grado nel posizionamento di un elemento);
- La necessità di creare relazioni tra diversi elementi di un modello informativo laddove, per necessità o per dolo, non possiamo utilizzare le relazioni già fornite dalle funzionalità base di Revit: non dimentichiamo che l’obiettivo finale del BIM è creare un modello parametrico relazionale.
- Il desiderio di automatizzare operazioni ripetitive, di modellazione o di documentazione.
La seconda applicazione non richiede necessariamente l’utilizzo di Dynamo: è spesso possibile ottenere gli stessi risultati con un uso sapiente delle tecniche di parametrizzazione delle famiglie, un uso oculato di reporting parameters, qualche trucco e un po’ di pensiero laterale. Le altre due applicazioni, purtroppo, consentono ben poco scampo.
Di queste, tuttavia, l’applicazione che io ritengo particolarmente problematica è la terza, che ci costringe ad addentrarci in un discorso che ha a che fare con la definizione strategica: quando è opportuno introdurre un elemento di automazione all’interno di un processo? Esistono delle regole e le vedremo insieme.

No Comments