Dal simulato al reale: la luce in Med in Italy 2012

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)

 

Mar, 21/10/2014 - 18:51
Panasiti Ombres - Workflow Revit Ecotect Dialux

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 MayaAutodesk RevitAutodesk 3ds MaxSoftimage XSISide Effects Software's HoudiniSolidWorks 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.

Mar, 21/10/2014 - 18:48
Il Lighting & la Simulazione

Fino al XVIII secolo, gli uomini disponevano solo di due sorgenti luminose: la luce naturale del giorno e, fin dall'età della pietra, della fiamma come sorgente luminosa artificiale. Questi due tipi di illuminazione hanno condizionato per lungo tempo la vita e l'architettura. Con l'invenzione dell'illuminazione a gas, e in seguito delle sorgenti luminose elettriche, ebbe inizio una nuova epoca. Gli architetti cominciarono ad usare diversi metodi per rappresentare le idee ed i dettagli tecnici e per comunicare con gli altri soggetti che partecipano al progetto. A partire dagli anni '80 la tecnologia digitale della simulazione ha superato gli affermati metodi degli schizzi, della produzione di modelli, campioni e disegni. La simulazione nella progettazione illuminotecnica comprende due campi. La simulazione quantitativa mira ad ottenere dei valori numerici fisicamente corretti per controllare il rispetto delle luminanze e degli illuminamenti previsti nelle normative. La simulazione qualitativa invece porta in primo piano l'atmosfera dell'ambiente. Il progettista illuminotecnico può così comunicare la sua idea estetica del progetto di illuminazione. Detto questo, quale precisione possiamo raggiungere? e vale la pena perseguirla?

L'illuminamento simile alla luce diurna con l'illuminazione elettrica divenne un problema di profusione di impegno tecnico. Alla fine del XIX secolo, con l'impiego per l'illuminazione stradale di luce intensa mediante torri luminose si ottennero più svantaggi che vantaggi, a causa dell'abbagliamento e delle ombre proiettate. Quindi questa forma d'illuminazione esterna ebbe vita breve.
Se in un primo tempo il problema principale erano le sorgenti luminose inadeguate, in seguito balzò in primo piano il trattamento intelligente di un eccesso di luce. Con l'espandersi dell'industrializzazione, nel settore dell'illuminazione degli ambienti di lavoro si fecero ricerche intensive sull'influsso dell'intensità e del tipo di illuminazione sull'efficienza produttiva. Ne nacque un ricco corpus di regole che indicavano sia gli illuminamenti minimi, che le qualità della resa cromatica e la limitazione dell'abbagliamento. Travalicando il settore degli ambienti di lavoro, questo catalogo normativo servì da linea guida per l'illuminazione in genere e ancora oggi definisce la prassi della progettazione illuminotecnica. Questo approccio non prendeva però in considerazione la percezione. Rimanevano al di fuori delle regole quantitative dell'illuminazione le modalità in cui l'uomo percepisce chiaramente le strutture e l'illuminazione comunica anche un effetto non solo estetico, ma anche di comfort e benessere fisiologico dovuta alla qualità della luce.

"Persino l'occhio tocca" Juhani Pallasmaa

La scissione tra simulazione quantitativa e qualitativa, ci allontana da un processo progettuale "organico"?

 

La luce naturale ed articiale nella realtà sono spesso insieme, è giusto progettarle insieme? in che modo?

Nei videogiochi la simulazione della luce è in tempo reale, ma quanto deve essere veloce la simulazione?

Per tutti quelli che intendono approfondire l'argomento, consiglio i libri:

Juhani Pallasmaa "Gli occhi e la pelle"

Francesco Bianchi "Architettura dell Luce"

Mar, 21/10/2014 - 18:46
Vadevecum sui Render Engine

 

Piccolo vadevecum sui principali motori di rendering - tratto da ERCO Light Scout

Radiosity

Nel calcolo dell'illuminazione con processi Radiosity i raggi luminosi partono dalle sorgenti luminosi e vengono riflessi quando incontrano una superfice. Questo processo continua in un dato numero di iterazioni e tiene conto anche della luce riflessa di altre superfici.
Un vantaggio significativo di Radiosity consiste nella memorizzazione delle caratteristiche della luce in una rete basata sulla geometria del modello. Si può così successivamente variare il punto di vista senza dover eseguire di nuovo i calcoli.
Come svantaggio con Radiosity si ha l'effetto di allungamento dei tempi di calcolo dovuto ai dettagli, alle sfere o alle scene complesse che richiedono una quantità molto elevata di poligoni. Selezionando una rete relativamente grezza di valori luminosi per velocizzare il calcolo si possono avere invece degli errori nel calcolo della distribuzione luminosa.
Radiosity è stato uno dei primi processi di calcolo della luce e si è diffuso molto per la sua capacità di calcolare l'illuminazione indiretta diffusa. Se nell'animazione di un modello architettonico si modifica solo il punto di vista ma non l'illuminazione, basta un unico calcolo per avere a disposizione le diverse prospettive.

Photon mapping

Il Photon Mapping funziona in modo simile al processo di Raytracing. Mentre il Raytracing funziona con raggi che partono dall'occhio, il Photon Mapping impiega i raggi che partono dalla sorgente luminosa. Il Photon Mapping funziona con particelle virtuali, cosiddetti "fotoni", dai quali la luce irradia nello spazio. Se incontrano una superfice vengono riflessi ed i valori luminosi vengono memorizzati. Una cartina a sé stante (Photon Map) memorizza le impostazioni dei fotoni. Non è quindi legata alle geometrie e può essere impiegata per le simulazioni con calcoli distribuiti sulla rete. La posizione del punto di vista può essere modificata senza eseguire nuovamente i calcoli - sebbene questa procedura non sia possibile interattivamente.
Quanti più fotoni presenta il modello, tanto più accurate saranno le transizioni nel Rendering e tanto maggiore sarà la quantità di calcoli da eseguire. Dopo una determinata quantità di riflessioni la cartina dei fotoni ha la precisione desiderata. In un ulteriore processo si possono fondere i punti con un'ulteriore procedura di calcolo detta Gathering.
Il Photon Mapping serve come base per successive procedure di calcolo. Per rappresentare al meglio i dettagli lo si impiega in combinazione con il Raytracing. Un metodo basato esclusivamente sul Raytracing può essere più dispendioso nei modelli con sorgenti luminose molto piccole e molto forti.

Raytracing

Il calcolo della luce con Raytracing, detto anche Monte Carlo Raytracing, a differenza di Radiosity e Photon Mapping, non parte dai raggi luminosi emessi dalle sorgenti luminose. I raggi partono invece dal punto di vista ed arrivano al modello ed alle sorgenti luminose. Quando i raggi che partono dal punto di vista incontrano una superficie, si controlla se vi sono altri raggi che la illuminano, se riflette la luce o se è in ombra. Il risultato per ciascun punto viene rappresentato come un pixel dell'immagine. Maggiori sono la risoluzione selezionata per l'immagine e il numero delle superfici riflettenti, maggiore il numero di raggi e quindi la complessità del calcolo della simulazione.
Il vantaggio del Raytracing consiste nella rappresentazione precisa dei dettagli e delle ombre. Siccome questo modo dipende dal piano scelto per l'immagine, una modifica del punto di vista e della direzione dello sguardo richiede un nuovo calcolo. Le scene con molti contrasti sono critiche, in quanto le radiazioni incidenti partono dal punto di vista e delle sorgenti di luce, come ad esempio delle piccole finestre in una grande parete, potrebbero essere tralasciate nel calcolo.

Quest'ultimo viene utilizzato da Mental Ray, il motorre di render di Revit. La caratteristica principale di mental ray è il raggiungimento di alte prestazioni attraverso il parallelismo su macchine a multiprocessore e attraverso le render farm. 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.

 

Mar, 21/10/2014 - 18:40

Pagine