La giornata è cominciata con una piccola dimostrazione di
forza di Autodesk, in verità sotto l’evocativo titolo della lezione “quando le
famiglie diventeranno coscienti” sono stati mostrati i risultati di un progetto
di ricerca interno ad Autodesk (nome in codice Honeycomb, nido d'ape) che cerca di
fondere insieme i benefici di un approccio tradizionale alla creazione di
famiglie con quello più analitico attraverso script esterni o procedure più complesse
(leggi varie implementazioni di Dynamo o più specifici linguaggi di
programmazione).
Il concetto è che la maggior parte di questi comandi esterni
implementati attraverso le API oppure attraverso la programmazione visuale di Dynamo,
sono poco affidabili in quanto non vengono aggiornati costantemente, sono sotto
questo aspetto contrari alla natura specifica di Revit. Inoltre quando il file
del progetto viene fatto circolare al di fuori del proprio studio e finisce ad
un consulente che non possiede questi particolari script, queste funzionalità
aggiuntive cessano di esistere, non sono quindi replicabili. Il progetto Honeycomb
vorrebbe quindi integrare la leggerezza di un semplice codice all’interno della
tecnologia di un progetto o incorporare dei comportamenti all’interno dei
diversi componenti, siano essi di sistema oppure no, per poter garantire la
congruenza di comportamento attraverso il passaggio di file da uno studio ad un
altro ad esempio.
Le implicazioni potrebbero essere molteplici: la prima
applicazione utile che mi è venuta in mente potrebbe essere quella di compilare
un abaco delle finiture per i locali e far in modo che il materiale di finitura
dei muri possa cambiare automaticamente in accordo con quanto definito nell’abaco.
Sono stati portati esempi di componenti autoadattanti che sono molto più performanti
di una serie di vincoli che possiamo esplicitare in una famiglia ad esempio.
Non ho apprezzato molto l’intento di Autodesk in questo
senso perché sono state mostrate delle caratteristiche che potrebbero non entrare
mai a far parte del software, mentre invece ci sono problemi sanguinosi ancora
aperti oppure strumenti da rifinire e completare nelle funzionalità che non si
sono guadagnati ancora il diritto di entrare a far parte delle lista di cose da
fare assolutamente ma che avrebbero un impatto molto pesante in senso positivo
sul lavoro di tutti i giorni.
La seconda sessione del mattino che ho seguito è stata
tenuta da Harry Mattison di Boost your BIM, un ex collaboratore di Charles
River Soft che poi ha preso il nome di Revit Technology fino all’acquisizione
da parte di Autodesk. Dal 1998 al 2012 ha lavorato nella stanza dei bottoni di
Revit e lo conosce in modo profondo. Quello che ha cercato di dimostrare in
pochi esempi è come sia possibile rendere i nostri progetti addirittura più
intelligenti attraverso l’utilizzo delle API. Anche in Italia con Diego Minato
e Renato Caenaro ho potuto vedere cose piuttosto complesse gestite con un’applicazione
esterna realizzata appositamente per gestire dati di un modello BIM e produrre
documentazione standard di layout di supermercati ad esempio. Questi sono
strumenti che fanno risparmiare tempo senza dubbio ma quelli che ha mostrato
Harry sono esempi in cui le applicazioni esterne aiutano a fare scelte
progettuali mentre si lavora, ad esempio tenendo sotto controllo la lunghezza
dei percorsi per raggiungere una particolare stanza e quindi riformulare la
forma dell’edificio sulla scorta di un piano tipo ottimizzato, piuttosto che
tenere sotto controllo la distanza dalle vie d’uscita ed intervenire su altri
aspetti progettuali sempre prima nella concezione del progetto.
Si possono anche ridefinire dei comandi attraverso le API o
attivarne di altri in funzione di determinati eventi di innesco come ad esempio
l’apertura di una vista, il salvataggio o l’apertura di un documento ecc. ad esempio è possibile definire le proprie finestre di dialogo e impostare i valori di default di quando si collega un oggetto da "Auto: centro a centro" a "Auto: origine a origine".
La particolarità di Harry è la velocità con cui riesce a realizzare
strumenti utili al volo: giusto il tempo di un panino ed è tornato con un video
fatto per spiegare un comando che rispondeva ad una richiesta che un altro
partecipante gli aveva posto per individuare quando un elemento attraversa, ad esempio, un controsoffitto o una parete che
abbia una determinata resistenza al fuoco e che quindi deve essere monitorato
per i fini della manutenzione con una frequenza particolare e che deve essere
quantificato in un report esterno. Vedendolo lavorare sembra davvero tutto
semplice, ed è un po’ questo ciò che meraviglia di una persona con un talento
come il suo.
Chiacchierando un po' con lui gli ho chiesto se esistesse un modo per aggirare il problema delle annotazioni in Revit attraverso le API ma lì il suo disappunto sulla questione è venuto fuori e si è sfogato di quanto poco ancora sia stato fatto per risolvere questo tipo di problematiche (ad esempio le etichette della categoria dei montanti di facciata continua mancante, o l'inconsistenza delle viste collegate per quanto riguarda le quote che si riferiscono ad elementi collegati in un primo file come associati e poi ricollegati in un altro file... provate: dentro il file A collegate un file B nel quale è collegato un file C come associato, se in B tracciate delle quote che interessano gli elementi di C e successivamente collegate la vista di B in A non riuscirete a vedere le quote sugli elementi di C).
Durante la tarda mattinata si è tenuta una prima parte della
lezione dedicata allo sviluppo di standard di utilizzo Revit per l’Europa, in
realtà doveva essere proprio il filo portante della conferenza, trovare dei
punti in comune per avere del materiale valido da cui partire. C’era una
vignetta esplicativa: due persone parlano e una fa all’altra “hey ci sono 14
tipi di standard concorrenti, dobbiamo fare qualcosa” e l’altro ribatte “si
abbiamo bisogno di un solo standard” ed il risultato è che di lì a poco ci
sarebbero stati 15 tipi di standard.
Ognuno sembra avere una specie di ricetta, molti dichiarano
di utilizzare uno standard di riferimento ma non tutti sono veramente in grado
di garantire la consistenza e la completa aderenza ad uno standard proprio per
la natura collettiva del lavoro, altri sono partiti dalla codifica delle categorie
e dei materiali, delle tipologie costruttive, della forme e hanno ottenuto un
complessissimo codice parlante da utilizzare per dare un nome agli oggetti o ai
parametri contenuti in essi. Usando una serie di strumenti automatizzati è
possibile non essere inghiottiti da questa giungla di codici ma ovviamente una
volta implementato e visto funzionare resta ancora qualche limite linguistico
da superare, di localizzazione, perché a quanto pare quasi tutti riescono a vedere il
valore di avere uno standard per la collaborazione con altri progettisti, ma non
tutti per la verità condividono questo punto di vista. O meglio la questione
non è tanto semplice da dirimere apparentemente perché purtroppo non è ben
chiaro cosa sia uno standard e quando c’è confusione su una cosa fondamentale
come questa difficilmente si può venire a capo di qualcosa di utile,
soprattutto in un dibattito di un’oretta scarsa.
Dal mio punto di vista non si deve confondere lo standard di
utilizzo di Revit con l’aderenza alla normativa di un determinato Paese, o,
peggio ancora, con un protocollo di scambio dati come ad esempio l’IFC.
Quello che costituisce uno standard sono le pratiche da
adottare nella realizzazione dei modelli per far si che si possano eseguire
tutte le analisi possibili sul progetto partendo dall’insieme dei modelli
interdisciplinari che lo costituiscono.
Ci sono regole da rispettare per ottemperare alle esigenze
di ciascun tipo di analisi, da quelle energetiche che richiedono ad esempio che
i muri siano un solo oggetto multi strato per poterne computare i correttamente
i valori di trasmittanza con una certa affidabilità nei nodi per la modellazione
dei ponti termici, a quelle strutturali dove ad esempio si devono modellare le
giunzioni tra un muro e un solaio, quindi il muro non potrà essere unico dalla
base alla sommità ma dovrà essere interrotto in corrispondenza dell’intersezione
dei diaframmi orizzontali, ancora ci sono le analisi dei costi cui strumenti
come le parti possono portare seri benefici a garanzia dell’attendibilità del
modello e tutto questo quindi porta a definire quale livello di dettaglio e affidabilità
si vuole avere nel modello.
In poche parole si deve codificare la prassi da seguire nel
nostro lavoro per parlare effettivamente di collaborazione, partendo dal basso
per i contenuti da includere e partendo dall’alto per stabilirne l’obbligatorietà
all’interno di un progetto. Si tratta di un processo che va in due sensi e si
spera trovi un punto di incontro a metà strada tra la fattibilità e l’utilità
di una scelta simile per l’intera filiera delle costruzioni.
Si può obiettare che è un processo complicato e complesso,
che dipende dalle abitudini locali o dagli standard interni ecc… forse perché
sono in Olanda, mi è venuta in mente questa immagine esplicativa: quando
si impara ad andare in bicicletta si stanno eseguendo una serie coordinata di
movimenti, se dovessimo metterci a pensare a cosa dobbiamo fare ogni volta che
saliamo su una bicicletta non ci sarebbe nemmeno il piacere di fare una
passeggiata, mentre invece ci viene naturale, eseguiamo una serie complessa di
operazioni in un ambiente in costante evoluzione, circondati da fonti di
pericolo potenziali quando andiamo in strada, ma tuttavia sappiamo andare
ugualmente spediti sia in Italia sia in Inghilterra dove hanno un codice della
strada diverso dal nostro e guidano dal lato opposto della carreggiata: andare
in bicicletta in modo corretto resta essenzialmente la stessa cosa ovunque. Perché
non possiamo realizzare i nostri modelli BIM con la stessa naturalezza e grado
di confidenza indipendentemente dal Paese in cui ci troviamo a lavorare?
Dai commenti che ho sentito e dagli interventi che altri
partecipanti facevano sull’argomento sembra che Revit sia utilizzato come
modellatore, non ci sono però informazioni nel modello, o semplicemente sono
impostate male e rendono il modello inaffidabile. La sfida è quindi riuscire a
realizzare modelli affidabili al 100% inserendo programmaticamente gli
obiettivi da raggiungere e le metodologie da seguire in un contratto. Sembra
che al di là dell’Atlantico questo tipo di approccio legale funzioni piuttosto
bene e qualora ci siano consulenti che non siano in grado di fornire questo
tipo di prestazioni saranno costretti a
dotarsi in breve tempo di una forma di outsourcing se vogliono rimanere
competitivi sul mercato europeo e successivamente interiorizzarla nel proprio
processo di lavoro.
Al termine di questa sessione ci sono state due lezioni di
alleggerimento: la prima di “tips and tricks” per lo più cose arcinote, alcune
molto banali, altre più sofisticate, ma nel complesso valevoli di essere menzionate
e ricordate. La seconda è stata una carrellata di ultimi ritrovati tecnologici
che avevano poco a che fare con Revit o il mondo delle costruzioni ad eccezioni
di droni miniaturizzati per eseguire il laser scanning di un edificio. Non si
sono toccati minimamente temi come sostenibilità tecnologica, servizi in cloud
o nuove piattaforme di collaborazione
purtroppo.
A quanto pare questa prima edizione del Revit Technology
Conference in Europa ha smosso un po’ gli animi su questioni più o meno
spinose, ha portato allo scoperto i difetti di una cultura frammentaria ma che
si sta a fatica mettendo a regime per dialogare con il resto del mondo.
La prossima edizione si terrà nel 2014 in agosto a Dublino, resterà
con la formula a numero chiuso dei partecipanti per consentire l’interazione su
una scala umana e avere uno scambio di idee in forma più sociale e proattiva.