Vincenzo Panasiti
Mer, 20/02/2013 - 19:00
Ecco i primi passi per utilizzare Arduino!
Per prima cosa dobbiamo procurarci il materiale, a cominciare ovviamente da Arduino stesso. Va bene qualunque board, io ho un Arduino Uno.
Seconda cosa consiglio a tutti la guida di Massi Banzi, Arduino la guida ufficiale.
Bene adesso non resta che procurarci tutto il materiale elettrico o elettronico su cui riusciamo a mettere mano e cominciare! Il materiale che ci serve molto probabilemtne è già a casa nostra, a giacere inutilizzato in vecchie tv, tastiere, telecomandi, telefoni ecc. Smontando qualunque di questi oggetti ormai spazzatura possiamo trovare tutto il materiale ce ci serve. Ma possiamo cmq comprare tutto quello che ci serve in qualunque negozio di elettronica. Pastorelli è molto fornito e si trova vicino al mattatoio. Prima avvertenza, quando andate in questi negozi, siate preparati!!! Se vi presentate chiedendo delle resistenze o dei termistori, dovete essere pronti a saper rispondere alla domanda "da quanto?" Pena la derisione da parte dei commessi e di tutti i vecchietti che affollano il negozio!
Il 99% delle domande trovano risposta nella Legge di Ohm
Un accessorio assolutamente necessario, a meno che non siate esperti in saldature di circuiti è la Breadboard la quale ci permetterà di unire i circuiti incastrando!
A questo punto non rimane che scaricare il compilatore di arduino l'IDE (Ambiente di sviluppo integrato) applicazione in Java che utilizza le librerie C/C++....che significa? Che per compilare in Arduino non è necessario conoscere il linguaggio C/C++ ma semplicemente utlizare due funzioni:
Passiamo all'azione.
Bene ora cominceremo da qualcosa di molto semplice, accenderemo un led e lo spegneremo GRADUALMENTE!!! Come possiamo fare? attraverso una tecnica chiamata Modulazione di Larghezza di Impulso o PWM, in parole semplici: se facciamo lampeggiare un LED abbastanza rapidamente, non lo si vede più lampeggiare, ma si riesce a cambiare la luminosità cambiando il rapporto tra il tempo in cui sta acceso e quello in cui sta spento.
Assembliamo il nostro circuito in questo modo:
Il Led è collegato dall'anodo (+) al PIN digitale 9 e il suo catodo (-) ovviamente alla massa
E adesso compiliamo lo sketch:
La programmazione è molto semplice, notiamo come tutto quello che viene scritto dopo // non viene letto dal compilatore, ma è è molto utile per noi per ricordare cosa abbiamo fatto ecc. soprattutto in script molto lunghi.
E questo è il risultato:
<iframe width="640" height="360" src="http://www.youtube.com/embed/4FAq9j1ZCjk?feature=player_detailpage" frameborder="0" allowfullscreen></iframe>
Il prossimo passora sarà che di dimmerare 3 LED di 3 colori diversi!
Mini lampada RGB
COme preannunciato ecco la dimmerazione con 3 LED dei colori RGB, con i quali, attraverso la sintesi ADDITIVA, riusciamo a altri colori!
Per prima cosa creiamo il circuito con 3 LED
E ricombiliamo il codice come prima, ma facendo in modo che i LED si accendano in tutte le combinazioni possibili (RGB, RB, RG, GB, R, G, B)
Ma in questo modo non otteniamo altre tonalità....ecco perchè ora dobbiamo creare un diffusore!A cosa ci serve? In questo modo potremo aumentare la superfice diffondente dei LED e permetteremo ai colori di mescolarsi. Un semplice diffusore artigianale può essere creato costruendo una scatolina di carta e riempirla con dei fazolettini "tempo" (sono perfetti per ammorbidire la luce), ed ecco il risultato (a breve pubblicherò anche le altre immagini): 
Vincenzo Panasiti
Gio, 21/02/2013 - 18:55
Uno strumento molto potente per creare sofistificati modelli parametrici è senza dubbio Grasshopper. Grasshopper è un editor visuale per lo scripting, completamente gratuito e progettato in modo da non richiedere conoscenze di programmazione. attraverso un intuitivo metodo grafico basato su interfaccia a nodi, l'utente definisce sequenze di istruzioni che vengono tradotte in modelli tridimensionali nella finestra di Rhino. [Arturo Tedeschi, Architettura Parametrica]
Quindi al contrario di Rhinoscript non richiede la conoscenza di linguaggi di rpogrammazione. Tuttavia manca della capacità di comunicare con hardware esterno come, ad esempio, Arduino. Anche qui non avere dimestichezza con i linguaggi può essere un ostacolo, ed è qui che entra in gioco Firefly. La caratteristica principale di questo plug-in di grasshopper è la possibilità di far dialogare quasi in tempo reale inpu e output dal mondo phisical al digital, attraverso un interfaccia visiva!
Cominciamo!
Per prima cosa dobbiamo avere installato sul nostro computer:
- Rhinoceros (4.0 sr8 o 5.0)
- Grasshopper (v. 8.004 o più recente)
- Arduino IDE
A questo punto scarichiamo dal sito la fersione più recente di Firefly e seguiamo le istruzioni per installarla ed la palette di firefly comparirà nel menu di grasshopper.
Per prima cosa, dobbiamo verificare che firefly comunichi con Arduino per la porta giusta:
- Posizioniamo il nodo Ports Aviable sul desk di Grasshopper
- Adesso trasciniamo il nodo Open Port e colleghiamo il suo input Port all'output dell'altro nodo
- Ora dobbiamo trascinare un Boolean Toggle da Params>Input>Boolean Toggle
- Colleghiamo il suo output all'input Open del Open/Close Port
- A questo punto creiamo due Panel da Params>Input>Panel e li colleghiamo all'output dei componenti Open Port e Aviable Port
Se tutto è andato bene dovreste ottenere un graficante messaggio HOORAAY
Perfetto adesso il passo successivo è quello di vedere gli input che riceve dai Pin analogici e Digitali.
Piccola, ma importante, digressione sui Pin di Arduino:
I segnali in ingresso o in uscita, possono essere analogici o digitali. Un segnale analogico può assumere qualsiasi valore (all'interno di un range noto). Con notevole semplificazione, si può pensare che siano "analogiche" tutte le grandezze fisiche misurabili nell'ambiente. Un segnale digitale può assumere due soli stati (High/Low, 1/0), corrispondenti a due livelli di tensione convenzionali (ad esempio, 5-0V). Con simile semplificazione, si può pensare che siano "digitali" tutte le informazione scambiate tra componenti logici (microprocessori, memorie, interfaccie di rete, display...). Possiamo quindi schematizzare in questo modo:
Dei pin digitali solo alcuni sono predisposti per segnali di tipo PWM (per maggiori dettagli rimando al post precedente) qui sotto sono quelli in verde. Infine ci sono 6 pin dedicati ai segnali analogici (in giallo), ma solo in input, ossia questi pin servono principalmente per acquisire dei segnali provenienti da sensori di tipo analogico: trimmer, potenziometri, fororesistenze, ultrasuoni, IR, ecc… ossia tutti quei sensori che possono generare un segnale analogico in funzione della loro stimolazione (luminosa, meccanica, ecc).
Sapere questo come vedremo è estremamente importante, come vedremo in seguito, per creare i nostri progetti.
Bene, andiamo avanti. Adesso quindi vogliamo che gli input analogici di Arduino vengano letti da firefly, come possiamo fare?
- Per prima cosa trascianiamo nel desk il componente Uno Read (Firefly>Arduino Boards>Uno Read)
- Colleghiamo l'output di Port Aviable al port input di Uno Read
- Prendiamo un nuovo Bolean Toggle e colleghiamolo allo start input di Uno Read
- Colleghiamo un Panel per output di Uno Read
- Prendiamo un GH_Timer (Params>Special>Timer) e colleghiamolo all'Uno Read.
- Settiamo come valore del timer 1ms, in questo modo i valori che otteremo saranno aggiornati pressochè in tempo reale
- Attiviamo il bolean Toggle
A questo punto vedremo apparire dei valori nei vari panel di output (ricordiamo che dagli analogici avrevo valori compresi tra 0 e 1023 e dai digitali 0[low] e 1[HIGH]) anche se non abbiamo sensori collegati ai pin analogici vedremo comunque dei valori, che cambiano in continuazione, niente paura si tratta semplicimente di disturbi statici (white noise) ininfluenti per noi. Se avete fatto tutto bene dovreste trovarvi con una situazione del genere:
Il prossimo passo sarà quello di far rispondere il nostro modello agli input analogici.
Mar, 21/10/2014 - 18:57
Vincenzo Panasiti
Mar, 21/10/2014 - 18:55
“La sostenibilità di un edificio si decide in larga parte nelle prime fasi dei processi di progettazione edilizia, alla base di Project Vasari c’è la volontà di dare una risposta a questa problematica offrendo al mercato soluzioni concrete per affrontarla e superarla. Project Vasari consente a chiunque, non solo agli utenti di Revit, di vedere e sperimentare molti dei benefici derivanti dall’applicazione delle analisi energetiche alle prime fasi di sviluppo concettuale dei progetti architettonici.”
Phil Bernstein, Autodesk vice president of industry relations.
Si tratta di un modellatore stand-alone, che non richiede l’installazione di Autodesk Revit, ma è stato sviluppato con lo stesso linguaggio. Permette quindi di effettuare le prime analisi di un progetto nelle prime fasi della progettazione.
Lo strumento Conceptual Energy Analysis è incluso all’interno di Project Vasari per consentire di convertire in modo automatico un modello concettuale in un modello analitico per l’analisi energetica così da poter raccogliere informazioni sui consumi e costi energetici sin nelle primissime fasi del processo di progettazione.
Vogliamo capire cosa come e quanto influisce ogni scelta all'interno della nostra simulazione, per verificare se l'output di dati che ricaviamo sia effettivamente attendibile, o comunque mostri una precisione apprezzabile. Per fare questo modelleremo 3 tipologie di edifici (stecca, cubo e corte) in tre zone climatiche italiane differenti (nord, centro e sud) e andremo a verificare cosa e quanto varierà nelle nostre analisi.
Ma procediamo con ordine.
Dove
Il parametro più importante di qualunque analisi energetica è sicuramente il DOVE, questa viene effettuata. All'interno di Vasari possiamo definire dove sarà situato il nostro progetto, attraverso un sistema di coordinate, che ci colegherà alla stazione meteo più vicina!
IMPORTANTE: bisogna stare molto attenti a quale stazione ci agganciamo, specialmente in luoghi con grandi dislivelli: se il nostro edificio sorge in una vallata e la stazione meteo è sulla cima di una montagna i nostri dati di partenza non saranno molto validi.
L'Autodesk Climate Server, una rete di rilevamento climatico si basa su 3 metodologie:
- Virtual wheather station: il sistema di staizoni meteo virtuali di Green Building Studio, basato su elaborazioni di dati meteorologici. Elaborate dal NOAA.
- Physical wheather station: basato su stazioni meteorologiche reali.
- Historical data: una banca dati dello storico meteo del luogo.
Nel nostro esempio sceglieremo 3 locali climaticamente diverse (all'interno comunque della fascia climatica temperata-mediterranea):
- Casteldarne (BZ)
- Roma (RM)
- Altolia (ME)
E scegliamo le rispettive stazioni meteo.
Cosa
Stabilita la localizzazione, dobbiamo decidere la forma del nostro edificio! Poichè vasari è un software di analisi PRELIMINARE, ci viene molto utile nel caso si debba scegliere la forma migliore del nostro edificio in funzione della strategia bioclimatica. Questo perchè edifici di forme diverse, a parità di isolamento, volume ecc, hanno comportametni diversi. Questo è legato a un discorso sulla superficie disperdente, disporso che viene spiegato molto bene in questa tesi .
Per il nostro lavoro utilizzeremo 3 tipologie di edificio con pari volume:
- Stecca
- Cubo
- Corte
Tutti e tre sono tipologie molto omuni di edifici, forse il cubo non tanto, ma va bene uguale.
La teoria ci dice che un edificio a cubo risulta più efficiente nei climi freddi, dove le dipersioni termiche sono ridotte al minimo. Mentre un edificio a corte in climi caldi, un edificio a corte risulta vantaggioso poichè a fronte di uno svantaggio nel periodo invernale, attraverso la ventilazione naturale ha un guadagno in regime estivo. Tutto questo perchè bisogna sempre valutare se:
Consumo di più per riscaldare o per raffreddare?
Questo è un concetto di estrema importanza, poichè Vasari genera una stima stima dei consumi che avrà il nostro edificio. Ora dobbiamo solo capire come e se è in grado di apprezzare le variazioni di forma che daremo al nostro edificio.
Vasari è in grado attraverso la sua analisi energetica di fornire:
- Stima delle emissioni di anidride carbonica (CO2) legate a quasi ogni aspetto dell'edificio, comprese le emissioni di CO2 della rete elettrica regionale per tipo di combustibile utilizzato.
- Analisi del potenziale della ventilazione naturale per la gestione del carico di raffrescamento dell'edificio su base oraria
- Stima del numero di ore nelle quali si può utilizzare l'aria esterna per il raffrescamento dell’edificio e valutazione della necessità di sistemi di condizionamento forzato
- Stima del carico richiesto per il condizionamento forzato
- Stima del fabbisogno idrico in base al tipo di edificio e al numero di occupanti
- Valutazione di misure per la riduzione del consumo idrico
Come sappiamo per svolgere queste analisi Vasari utilizza il sistema Autodesk 360 Energy Analysis, un sistema di elaborazione in cloud su cui l'Autodesk sta spingendo molto negli ultimi anni.
Ma cosa intendiamo esattamente per Energy Analysis? basta andare nella directory DOEs Building Energy Software Tools Directory per trovare decine di software legati alle analisi energetiche. Tuttavia spesso i software sono stati realizzati per un particolare utenza o fascia di mercato o parte del mondo (90% sono fatti per paesi anglossassoni). Tuttavia il sistema di analisi dell'autodesk come il sistema di rendering ecc. è basato su un MOTORE comune ad altri software ossia il DOE2.2. Un algoritmo di calcolo creato da Lawrence Berkeley National Laboratory, James J. Hirsch & Associates, U.S. Department of Energy e l'Electric Power Research Institute. Basato sul DOE2.1 del 1994 è una sua diretta evoluzione dove viene incrementato la capicità di calcolo generale in relazione agli impianti alle superfici disperdenti e ai dati climatici.
Questo motore risulta leggermente meno accurato del più noto EnergyPlus (sempre sviluppato dal dip. dell'energia degli Stti Uniti) ma ha un notevole vantaggio in termini di velocità di elaborazione ed interattività. Cosa comporta questo? E' sicuramente lo strumento più adatto in un analisi preliminare dove molte cose non sono definite e le variazioni anche significative del progetto sono molto frequenti.
Ma vediamo come Vasari sfrutta questo motore per l'analisi energetica:
- L'edificio è discretizzato per zone termiche, che scambiano calore tra loro e con l'esterno.
- I dati climatici sono inviati su base oraria, specialmente temperature, velocità del vento, umidità e irraggiamento.
- Attraverso il "calcolo agli elementi finiti" il calore viene scambiato per convezione, conduzione e irragiamento.
Quanto e' accurato?
Questa è il problema principale. Durante una lezione AU2012 Ian Molly spiega come esistono 2 tipi di accuratezza: l'accuratezza di calcolo e l'accuratezza di informazioni. Per quanto riguarda il calcolo gli esperimenti mostrano una precisione del +/- 5%, il che è senza dubbio notevole, ma per avere un alto livello di precisione dobbiamo avere informazioni di base precise. Vige sempre la logica del GARBAGE IN GARBAGE OUT!
Attraverso questo schema sempre dell'AU2012, vediamo come gran parte dei dati necessari per l'analisi energetica derivino da operazioni che possiano conoscere con una buona precisione. Ovviamente tutte le parti che derivano dalla progettazione invece, molto difficilmente saranno definite fino alla fine del processo.
L'analisi energetica quindi non è una scienza esatta, lo scopo di Vasari per l'appunto non è quello di darci risultati esatti, ma quello di guidarci nella progettazine prelimanare nella scelta della forma e dei materiali.
Dopo questa lunga ma indispensabile digressione, vediamo cosa risucimo a verificare noi.
Confronto
Come detto in precedenzo cominceremo modellando 3 edifici di forma differente ma di pari volume:
Vincenzo Panasiti
Lun, 21/10/2013 - 18:50
Dal simulato al reale: in questo post andremo a vedere come il lavoro virtuale
- se correttamente eseguito in ottica simulativa n.d.r. - abbia un chiaro riscontro nel reale.
Durante la progettazione dell'abitazione Med in Italy per il Solar Decathlon 2012, ho scoperto come un coretta simulazione dei componenti del progetto possa essere importante per evitare spiacevoli sorprese dopo. Inoltre una simulazione accurata, permette un miglioramento complessivo di tutto il progetto.
Uno degli aspetti di cui mi sono occupato è stata la modellazione delle finiture e degli arredi interni (la cui la disposizione era assai importante, poichè la casa sarebbe stata un expo e quindi tutti i requisiti di accessibilità che richiede uno spazio pubblico...quando spazio di manovra serve a una sedia a rotelle?)
Tutti gli elementi modellati, dovevano essere il più possibile fedeli alla realtà e allo stesso tempo essere facilmente modificabili. Poichè la progettazione degli interni e dell'illuminazione andava di pari passo all'architettonico e allo strutturale, ciò ha richiesto numerosi cambi e una grande velocità di modifica. In particolare per quanto riguarda l'illuminazione, la quale dipendeva da molti parametri tra cui:
- I risultati delle analisi illuminotecniche (minimi di legge, requisiti della competizione, qualità della luce superiore agli standard)
- La disponibilità degli sponsor (i soldi in poche parole) che forniscono il corpo illuminante
- Le capacità produttiva del produttore dei case non standard
- Le modalità di montaggio
Inutile dirlo che durante la prgettazione, tutti questi parametri sono cambiati mooooooooooolte volte!
Vediamo alcuni esempi:
Progettazione ambiente cucina.
Prendiamo ad esempio la progettazione degli arredi e dell'illuminazione della cucina.
Per prima cosa dobbiamo ricordare i parametri in atto, essendo un progetto finanziato da sponsor, con i fornitori non si ha una poszione contrattuale forte, quindi bisogna assolutamente evitare errori.
- Valori illuminotecnici
- Qualità della luce nello spazio
- Consumi energetici
A progetto finito abbiamo utilizzato 2 corpi lampada Genius LED della DGA. Tuttavia questa non è stata la scelta iniziale: la prima proposta aveva due corpi lampada a luce puntuale sui piani di lavoro e un binario di luce nella mezzeria del soffitto. Ecco i risultati delle prime analisi.
Come possiamo vedere, oltre a non soddisfare i requiti illuminotecnici sul piano di lavoro, abbiamo anche un carico elettrico non indifferente. In seguito è stato optato per i due Genius......ma il carico elettrico e la luce sono gli unici fattori? diamo un occhiata all'ordine complessivo
Abbiamo un gran numero di Genius per il wallwash dell'abitazione. Quindi una minor varietà di componenti comporta un risparmio notevole sia di tempo che di lavorazione nel montaggio e in caso di imprevisti.
Bene come possiamo vedere anche dal confronto render-foto, dal punto di vista illuminotecnico la luce è stata ben simulata il modello si è prestato facilmente alle modifiche, anche radicali, in corso di progettazione. Tuttavia non è andato tutto liscio...durante la progettazione non è stato considerata nè la modalità di montaggio nè lo spazio occupato dalla cavetteria e dai trasformatori. Questo ha reso necessario eseguire delle lavorazioni in cantiere non previste (che è proprio ciò che dobbiamo evitare)
Vincenzo Panasiti
Gio, 21/11/2013 - 18:45
La chiusura del cerchio
La nostra idea di interazione tra Dialux, Revit ed Ecotect parte da questo schema
I nostri propositi sono quindi quelli di trovare la giusta relazione tra illuminamento naturale ed artificiale durante tutto l'anno se possibile. Le analisi in ecotect purtroppo non sono state di grande aiuto poiché i risultati ottenuti sono stati di gran lunga eccedenti l aspettative reali. Inoltre ciò che veniva fuori dalle analisi era di certo errato in quanto i valori di illuminamento naturale riportati erano presenti anche in orari del giorno in cui sappiamo di per certo non esserne possibile la presenza. Nei link che seguono è spiegata la procedura utilizzata per modellare in ecotect gli ambienti, per analizzarli e per ottenere i diveris risultati:
http://design.rootiers.it/tecniche2012/node/516 (vengono illustrati i passaggi per poter effettuare un'analisi comparata luce naturale ertificiale)
http://design.rootiers.it/tecniche2012/node/458 (viene spiegato il calcolo dell' FLD in ecotect e la valutazione dei risultati)
come si può vedere nella dicitura in basso a sinistra average value (valore medio), il valore di FLD (fattore di luce diurna dovuta al solo ingresso di luce naturale), che è indipendente dalla stagione o dall'orientamento dell'edificio risulta esser troppo elevato e le analisi successive in Dialux lo confermano.
atto
E' comunque evidente come la percentuale di luce sulla superficie di calcolo sia comunque indicativa del fatto che le zone contro muro dove sono allocati gli scaffali siano le più svantaggiate
Anche in questa immagine sono evidenti gli squilibri tra zone adiacenti la vetrata e quelle che ne sono più distanti, il problema sta nei valori che estrapola ecotect: la luce naturale in ingresso è troppo elevata per poter esser considerata un'analisi valida.
E' stato quindi necessario spostare l'intera analisi su Dialux. Qui di seguito è elencata la procedura per il passaggio da Revit a Dialux:
http://design.rootiers.it/tecniche2012/node/461 ( vengono mostrati gli scaffali con il relativo corpo illuminate)
Allego anche il link di utile freeware per la conversione dei file .LDT (usati da dialux) in .IES (usati da revit) http://www.helios32.com/resources.htm
Tuttavia l'utilizzo dei file .IES si è rivelato effimero in quanto il sistema di rendering on cloud non accettava scene con questi files. (da qui il nostro studio sulle tipologie di rendering utilizzate ). Fortunatamente dopo approfondite ricerche abbiamo trovato queste conversazioni dove viene spiegato il problema:
https://getsatisfaction.com/cloudservices/topics/interior_rendering_failed
Il passaggio a Dialux ci ha permesso di continuare il lavoro che ci eravamo prefissati.
Come già affermato in precedenze siamo riusciti a trovare sotto la voce "scena luce naturale" il giusto apporto di luce in ingresso (durante però tutto l'anno), questo ci ha comunque permesso di giungere a delle valide conclusioni.
Dall'immagine si nota come le aree più distanti dalle vetrate siano leggermente in ombra. Per ovviare a questo proposito abbiamo pensato di illuminare a giorno anche gli apparecchi verticali posti sulle scaffalature. La loro luce (che comunque non è eccessiva e comunque sempre dimmerabile grazie a sensori che con l'ausilio di un luxometro consentono di rilevare valori di illuminamento sufficenti e in caso negativo attivarsi), ovvia alla distribuzione della luce in ingresso.
Va comunque ricordato che l'ambiente è stato pensato per un ingresso di luce uniforme e che quindi non presenti eccessive disparità di luce naturale in ingresso per evitare situazioni di chiaro-scuri e di disagio psicologico dovuto alla presenza di "anfratti bui " illuminati solo da luci artificiali. Lo scopo dello studio e dell'imtero progetto in genere è quello di integrare tali fattori con la condizione psichica e mentale dell'utenza, che necessita della visione di una quotaparte di volta celeste, del panorama e della possibilità di interagire con l'esterno pern non alienarsi dal contesto.
Dalle isolux del grafico è evidente l'ingresso maggiore di luce ai bordi esterni maggiore e più accentuato (come detto prima riferito all'intero arco dell'anno). Va inoltre detto che i valori di Emin/Em in tabella sono fuorvianti in quanto per poter effettuare l'analisi abbiamo comunque dovuto creare un ambiente racchiuso che necessitava per poter esser delimitato di partizioni che inficiano inevitabilmente sui vaori minimi riscontati. Per fare un esempio in prossimità dell'ingresso si ha un brusco calo dei lux dovuto alla partizione chiudiambiente o in prossimità del corridoio retrostante laddove non è stato modellato il garnde lucernario superiore che avrebbe altresì consentito l'ingresso di una larga parte di luce ed il conseguente innalzamento di Emin (valori consigliati si aggirano attorno agli 0.8).
A seguito della revisione con il prof. Longobardi abbiamo cambiato il locale di studio dalla salla lettura all'emeroteca, più interessante dal punto di vista architettonico. In questo caso la dinamica della luce cambia, l'emeroteca non è più un luogo dove bisogna isolarsi e concentrarsi nello studio, ma un luogo dove ricercare mantenendo un rapporto più aperto con il prossimo, coadiuvat dall'uso di un illuminazione molto più diffusa e unforme.
MODELLO IN REVIT
Per prima cosa è stato necessario modellare l'ambiente con i relativi arredi e le lampade, associandovi il relativo solido fotometrico nonché i relativi parametri di famiglia nidificata.
Ecco i post in cui viene spiegato come creare e modellare apparecchi illuminati in Revit:
http://design.rootiers.it/tecniche2012/node/469 (nel seguente post vengono elencate le procedure per crerare la lampada Le Perroquet)
http://design.rootiers.it/tecniche2012/node/438 (qui invece viene descritta la creazione dell'illuminazione degli scaffali con il relativo link da cui abbiamo imparato a modellare)
ESPORTAZIONE IN GBXML
PROGETTO IN DIALUX
Di seguito vengono fatte le analisi sui livelli di illuminazione prodotti dagli apparecchi illuminanti precedentemente elaborati e parametrizzati in Revit. Il passaggio in Dialux ha semplicemente permesso di svolgere le analisi. Nei passaggi successivi una volta verificati i livelli di illuminamento necessari e le zone svantaggiate da lasciar illuminate si torna in Revit,
In quest'ultimo passaggio nel modello stesso vengono accese o spente le lampade in diurna e notturna in base alle esigenze evidenziateoe necessarie e vengono fatti i rendering con il metodo in cloud (successivamente vengono analizzati i vantaggi temporali di un metodo piuttosto che un altro) che abbiamo verificato essere il più veloce e semplice da utilizzare.
Sia il Pov-ray che il rendering in cloud che Revit utilizzano l'algoritmo di calcolo Mental ray, tuttavia, mentre Pov-ray si basa principalmente sul numero di rimbalzi di luce che arrivano direttamente alla telecamera, il motore di render interno di Revit e di Cloud sfruttando vari algoritmi montecarlo, riescono ad ottenere risultati migliori sulle caustiche ed i riflessi indiretti.
Il cloud, tuttacia, compensa la sua grande velocità con una qualità della luce artificiale ed un controllo dell'esposizione decisamente minore rispetto al motore di Revit intern (vedi tabella exel che segue)
A conclusione di tale processo ritornando in Revit vengono fatti quindi i rendering più fedeli alla realtà ed alle condizioni di utilizzo reali che si verificheranno all'interno della biblioteca
Ed ecco il risultato finale ottenuto tramite Pov-ray. Vediamo come il render sia molto poco fotorealistico tuttavia mostra una perfetta diffusione della luce, quello che proveremo a fare sarà ottenere un render più fotorealistico cercando di capire tuttavia se la luce sarà altrettanto esatta.
LAMPADE UTILIZZATE
In seguito abbiamo compreso come fosse fondamentale per il nostro studio la comprensione del funzionamento che è alla base dei motori di render che abbiamo utilizzato: a tal proposito ci siamo proposti di soffermarci sulle differenze tra le tre tipologie di renderizzazione da noi utilizzate (che sono poi state alla base delle nostre successive analisi per la scelta dell'illuminazione dell'ambiente in diurna in Revit).
Ma come funziona l'algoritmo di calcolo Mental ray?
La caratteristica principale di mental ray è il raggiungimento di alte prestazioni attraverso il parallelismo su macchine a multiprocessore e attraverso le render farm (come appunto la rendering in cloud della Autodesk). Il software usa tecniche di accelerazione come lo scanline per la determinazione primaria della superficie visibile e un partizionamento binario dello spazio per i raggi secondari. Supporta inoltre le caustiche e una simulazione fisicamente corretta dell'illuminazione globale usando mappe di fotoni. Possono essere simulate anche combinazioni di riflessioni e trasmissioni diffuse, lucide, e speculari.
Mental ray è stato sviluppato per essere integrato all'interno di applicazioni di terze parti usando delle API, ma anche per essere usato come programma indipendente usando file di scena .mi per i batch rendering. Fino ad ora ci sono molti programmi che integrano questo renderizzatore come Autodesk Maya, Autodesk Revit, Autodesk 3ds Max, Softimage XSI, Side Effects Software's Houdini, SolidWorks e CATIA della Dassault Système
Di seguito le nostre analisi in merito ai tempi di renderizzazione da cui si è scelto di utilizzare il render on cloud
Queste lampade poi sono state modellate in Revit, assegnando tutti i parametri sulla luminosità, la temperatura di colore e il wattaggio, come spiegato nei post precedenti.
Vista dell'emeroteca il 21 giugno alle ore 09:00, illuminazione artificiale completamente disattivata.
Nel rendering sopra ( vista del 21 giugno ore 17:00), e stata evidenziata l'accenzione degli scaffali (accesi da Revit). Il loro dimmeraggio consente con il passar delle ore e quindi del minor ingresso di luce di colmare il gap con l'illuminamento con la parte di ambiente affacciata all'esterno.
Vista dell'emeroteca il 21 dicembre alle ore 12:00, illuminazione artificiale completamente disattivata.
Vista dell'emeroteca dall'interno, ultimo passaggio in Revit (con accensione degli apparecchi) e renderizzazione in cloud
Ecco le differenze tra il pov-ray ed il rendering in cloud relativamente alle stesse condizioni di illuminazione
risolto il problema del cloud. non accetta solamente le luci artificiali contenenti file IES
Conclusione
Se all'inizio l'improvviso cambio di ambiente mi ha spaventato, mi sono accorto che è stato abbastanza facile cambiare ambiente:
- Per lavorare in Dialux è stato sufficiente esportare un differente locale in gbxml in questo modo ho potuto cominciare da subito a lavorare sul nuovo ambiente
- La modellazione in Ecotect è valida per poter considerare le condizioni di illuminamento durante le varie stagioni dell'anno ma presenta delle problematiche legate alla gestione degli apparecchi di illuminazione artificiale ( funzione a dir la verità limitata agli spot direzionali che non consente la calibratura del solido fotometrico in base alla sorgente, cosa invece possibile in Revit). E' consentita l'importazione da Revit ad ecotect delle tipologie di illuminazione create in Revit ma questo presenta i limiti sopra indicati.
- la destinazione d'uso e l'arredo molto simile ha ridotto al minimo il lavoro di creazione di nuove lampade.
- Tramite il servizio render cloud dell'autodesk ho ottenuto i nuovi render in pochissimo tempo
Tuttavia si sono manifestati anche i vari punti deboli del sistema:
- E' necessario avere un locale già modellato in Revit
- Se le lampade da inserire nei locali fossero state molto diverse ciò avrebbe comportato una grande mole di lavoro
- Il servizio render cloud non renderizza le scene con luci artificiali troppo complesse, bisogna preventivare quindi i tempi molto lunghi del Revit
- Nei nostri render, ed in particolare nel render in notturna, l'illuminazione delle lampade linari viene diversa dalle nostre aspettative iniziali (compare infatti una striscia di luce troppo definita sul pavimento).
Conclusione: Se all'inizio la metodologia sembra abbastanza valadi e conveniente, non è risultata essere all'altezza delle aspettative: i render dei due motori (revit e pov ray) hanno gravi lacune, uno nella precisione della luce l'altro nella resa grafica. Nel momento in cui decidessi di effettuare un cambio nelle luci dovrei applicare il cambiamento separatamente ai due software. Inoltre la difficoltà di un software molto poco user friendly come ecotect non ci hanno ancora permesso di lavorare sull'interazione tra luce artificiale e luce naturale. Ovviamente questo non è stasto lavoro perso, poichè nonostante lo scarso dialogo dei software, seguendo questo percorso, si ottiene una progettazione sia a livello di luce naturale che artificiale, completamente consapevole.