De Octavian LIPOVAN
Ce ar fi de spus?.. Multe.
Si as īncepe cu o amintire. Am avut prilejul sa vad o particica din doua mari orase europene: München si Viena. Nu vreau sa ma refer la atributele lor citadine care le distanteaza la departari cosmice de orasele noastre. Ar fi redundant. O sa ma refer īn schimb la o impresie care m-a urmarit din momentul īn care am vazut īn cele doua orase cladiri recent construite sau aflate īntr-un stadiu avansat de executie. Dincolo de aspectul lor variat prin care, normal, īsi reclamau propria personalitate, aveau un "nu stiu ce" comun. Am fost tentat sa pun acest lucru numai pe seama modei si a tehnologiilor de executie. Perfect posibil si explicabil, īnsa mai era ceva, mai aveau un numitor comun pe care, cred eu, l-am descoperit īn zilele urmatoare: erau case "proiectate pe calculator". Privindu-le cu atentie am avut sentimentul puternic ca īn aceste cazuri arhitectii, motivati si de lipsa unor soft-uri destinate studiilor de volumetrie, au preferat sa utilizeze facilitatile puse la dispozitie de tehnologia informatica si au capitulat, vremelnic, īn fata limitelor acesteia.
Īntr-un fel - fie-mi iertata comparatia - cladirile īn cauza pareau construite dupa cataloage de proiecte si detalii tip īn genul celor de care am avut si noi parte nu cu multa vreme īn urma. Sigur, īn cazul lor nivelul era cu totul altul, iar cataloagele au fost īnlocuite de bibliotecile existente īn pachetele de software. Folosirea lor a evitat probabil complicatiile, proiectantii multumindu-se cu obiectele prefabricate ale acestora. Si este mult mai comod sa lucrezi pe calculator folosind elementele predefinite ale bibliotecilor din soft, decīt sa te chinui sa inventezi, īn afara acestora, obiecte cu forme sau volume "libertine", greu controlabile uneori, chiar si sub aspectul comportarii ca element de program. De aici a aparut probabil si moda suprafetelor "curate" cu goluri simple si uniforme cu diferentieri doar la nivelul etajelor si fara variatii īn cīmp. Pentru ca soft-ul folosit, la vremea respectiva, nu a putut mai mult sau chiar daca da, efortul era prea mare si din considerente probabil comerciale, nu merita osteneala. Cei care utilizeaza calculatorul pentru proiectarea de arhitectura īnteleg, cu siguranta, foarte bine la ce ma refer. Īn ce masura acest aspect dauneaza actului de creatie, nu stiu. Cu toate ca acele cladiri aveau un aer "comercial", nu mi-au displacut.
Pe de alta parte, īntr-unul din numerele recente ale revistei Domus (779, februarie 1996), am vazut o casa - un pavilion pentru vizitatori construit īn New Canaan, Connecticut, numit Gatehouse, autori Philip Johnson, Alan Ritchie si David Harrison - care, din punctul meu de vedere, reprezinta tocmai opusul celor relatate mai sus. Cred ca aceasta Gatehouse va deveni un moment de referinta pentru posibilitatile puse de informatica la dispozitia si īn slujba imaginatiei arhitectilor care nu se opresc la nivelul unui "utilizator comod".
Ambele referiri au ca nota comuna concluzia ca informatica nu are cum sa strice actul de creatie arhitecturala mai mult decīt o face arhitectul īnsusi, ba mai mult, utilizarea inteligenta a resurselor acesteia nu poate fi decīt benefica pentru arhitect si - implicit - pentru capacitatea sa de creatie si pentru produsul de arhitectura. Sīnt unul dintre adeptii folosirii calculatorului īn arhitectura si nu pot sa nu fac pledoarie pentru aceasta.
Am facut cunostinta "pe viu" cu posibilitatile tehnologiei informatice pe vremea stagiului, cīnd am vazut pentru prima oara, undeva īn provincie, īncercari de proiectare īn urbanism cu ajutorul calculatorului. Cītiva informaticieni entuziasti de la o sectie de proiectare judeteana reusisera sa obtina variante de mobilare a terenului cu tronsoane de blocuri de locuinte tipizate. Asta se īntīmpla acum opt sau noua ani si marturisesc astazi ca la momentul acela am apreciat eforturile, dar n-am fost prea entuziasmat de rezultatele la care ajunsesera cei de acolo. Mai ales ca pentru a lucra cu calculatorul trebuia sa īnveti un limbaj de programare si, mai grav, sa stii matematica. Asa ca m-am limitat la a privi totul ca pe o curiozitate spunīnd precum vulpea ca, deocamdata, strugurii sīnt acri.
Acum patru ani m-am īntīlnit pentru prima data mai īn detaliu cu un program profesionist, destinat proiectarii asistate de calculator (binecunoscutul AutoCAD). A fost momentul īn care m-am convins ca este mai bine sa fii īn interiorul informaticii decīt īn afara ei. Este foarte adevarat ca īntre timp informatica evoluase spectaculos coborīnd din turnul de fildes al specialistilor īn mijlocul multimii utilizatorilor "profani". De aceasta data nu a mai fost nevoie de intermedierea unui matematician pentru conversatia cu calculatorul. Modul, relativ simplu, de lucru si interfata "umana" a programelor m-au determinat sa admit ca strugurii au īnceput sa se coaca.
De atunci am renuntat la multe altele si am īnceput sa īnvat "calculator". Pe parcurs am īnteles si faptul ca nu trebuie sa ceri acestuia "sa faca totul". De fapt, se poate spune ca lucrurile īncep sa mearga atunci cīnd ai īnteles corect limitele programului (oricare ar fi el), si te-ai acomodat cu rigorile acestuia. Este momentul de "maturizare" de la care se poate vorbi de utilizarea informaticii īn folosul tau. Sa ma explic.
Arhitectura este un act complex de creatie si, ca orice act de creatie, contine īn ea drumul parcurs de la idee la obiectul finit materializat īn teren. Pentru cuprinderea fenomenului, acest parcurs poate fi demontat īn trei etape: prima, īn care (simplist spus), ideea capata contur īn imaginatia arhitectului si este redata de acesta celorlalti prin intermediul desenelor sau machetei, o a doua īn care schitele capata consistenta si devin germenii materializarii, si o a treia, īn care se realizeaza constructia propriuzisa. Dintre cele trei etape, doar prima apartine īn totalitate arhitectului. Aici opereaza cu volume si spatii. Acum se naste "spiritul" a ceea ce va deveni mai tīrziu obiect de arhitectura. Celelalte doua etape trebuie sa fie controlate de arhitect, dar nu-i mai apartin. Īn aceste doua momente ale parcursului ceea ce am denumit mai īnainte "spirit", prin intermediul specialistilor din proiectare si al constructorilor, este īnvelit īn "materie". Maestrul de ceremonii al acestui īntreg demers ramīne, fara nici un echivoc, arhitectul. Si orice instrument pus la dispozitia acestuia (de la plastilina la informatica) nu poate fi decīt benefic. Numai ca fiecare dintre etapele descrise are propria specificitate, necesita o anumita abordare si un anumit tip de instrumente, multe dintre ele neputīnd fi utilizate decīt īn acea etapa. Macheta, de exemplu, nu poate īnlocui rigurozitatea planselor de executie, iar acestea din urma nu pot suplini listele cu cantitatile de materiale. Este evident faptul ca fiecare dintre etapele descrise anterior īncearca sa raspunda unor probleme ce se completeaza reciproc, dar au enunturi diferite. Si pentru a oferi raspunsuri corecte abordarea lor trebuie sa fie diferita.
Referindu-ma la produsele de informatica create pentru uzul celor care lucreaza īn proiectarea de arhitectura si constructii, pot spune ca lucrurile stau la fel ca īn proiectarea clasica - īn fond problemele sīnt aceleasi. Nu am vazut īnca un program care sa raspunda la cerintele īntregului demers arhitectural. Am constatat ca, din motive evidente, soft-urile din acest domeniu se adreseaza cu precadere momentului de mijloc al procesului: atunci cīnd arhitectul stie deja cum va arata casa si trebuie sa-i dea consistenta materiala. Cu alte cuvinte soft-urile īn cauza devin operationale pentru partea tehnica a proiectarii, dupa ce arhitectul a definit "spiritul" obiectului de arhitectura, īn momentul īn care spatiile si volumele trebuie cuantificate īn elemente de constructie (ziduri, plansee, stīlpi etc.), si īn unitati de masura (metri patrati, metri cubi, numar de bucati, kilograme, metri liniari etc.), pentru a fi transpus pe teren. Aceste soft-uri nu sīnt capabile sa raspunda corect cerintelor reclamate de studiile de perspectiva sau de volumetrie premergatoare oricarei solutii de la care īncepe munca de detaliere, pentru ca ele nu au fost gīndite pentru asta. Ele permit modelarea tridimensionala la nivel de detaliu a unor solutii concepute anterior si nicidecum generarea de solutii. Faptul ca aceasta modelare permite si o forma de studiu volumetric este cu totul altceva. Toate acestea provin probabil de la faptul ca proiectantii de software pentru arhitectura au pornit īn demersul lor de la planse spre obiectul finit, motivati de:
Gīnditi-va la ArchiCAD. Poti desena, foarte riguros de altfel, ca si cum ecranul ar fi o coala de hīrtie iar programul este capabil oricīnd sa-ti ofere o replica tridimensionala, care īnsa este "īnghetata": nu poti face modificari asupra ei decīt revenind īn plan si corectīnd desenul. Sīnt sigur ca acest mecanism a fost gīndit pentru corelarea desenelor cu solutia preexistenta si nu pentru modelarea 3D. Iar acest mod de abordare este specific majoritatii soft-urilor din domeniu.
Prima parte si poate cea mai importanta a actului de creatie arhitecturala a ramas, īntr-o buna masura, fara acoperire īn ceea ce priveste instrumentele informatice avute la dispozitie. Singur arhitectul, utilizīnd obiecte abstracte (ex: solide sau mesh-uri), poate sa modeleze o replica tridimensionala virtuala a viitorului obiect arhitectural. Aceasta se poate realiza relativ usor cu AutoCAD-ul, sau cu orice alt produs software de grafica 3D. Dificultatea intervine īn transformarea unor astfel de obiecte, amorfe din punctul de vedere al informatiilor de specialitate continute īn ele, īntr-un sistem de cuante de constructii, pentru a asigura continuitatea proiectarii. Si asta pentru ca exista o mare labilitate īn stabilirea granitelor īntre diversele zone ale volumelor amorfe. Gīnditi-va de exemplu la ce ar īnsemna transformarea unui solid complex, rezultat al scaderii īntre doua solide prismatice, īntr-o structura compusa din ziduri si planseu. Care ar putea fi criteriile de sortare sau de ierarhizare pe baza carora un soft sa poata stabili cu precizie ca zona plana a solidului, cuprinsa īntre limitele a, b, c,..n devine planseu iar restul se transforma īn ziduri? Este greu de raspuns si, cu siguranta laborios. Asta nu-l īmpiedica īnsa pe arhitect sa se foloseasca de resursele realitatii virtuale pentru a-si defini si verifica solutiile si pentru a le controla cīt mai bine. Cu alte cuvinte, pentru studiul premergator solutiilor tehnice modelarea chiar numai cu elemente amorfe este de un folos real, chiar daca pentru transformarea īn planse de lucru pentru santier este nevoie de o munca de modelare, aproape paralela, cu un soft specializat din categoria celor amintite anterior. Lipseste deasemeni, sau mai corect spus nu am stiinta despre existenta vreunui soft de restitutie perspectiva. Un astfel de instrument ar fi mai mult decīt util īn elaborarea solutiilor, pentru studiile de implantare īn situ a cladirilor, si nu numai.
Avīnd īn vedere toate acestea, cred ca multi dintre arhitecti, tentati si de usurinta relativa cu care programele existente au permis obtinerea de volumetrii acceptabile au īncercat exercitiul drumului invers: de la planuri la volum, generīnd o moda a caror rezultate sīnt case de tipul celor la care m-am referit la īnceputul acestui articol. O alta parte a speculat - mult mai benefic zic eu - resursele puternice pe care le ofera informatica, fara a inversa demersul arhitectural si a rezultat Gatehouse. Este vorba de doua atitudini diametral opuse a caror rezultate chiar daca nasc controverse, nu sīnt de loc neglijabile. Si mai presus de toate acestea, ramīne un loc comun faptul ca ambele atitudini au īmbogatit creatia de arhitectura. Īntelegerea acestor lucruri este esentiala pentru stabilirea ponderii ce trebuie acordata informaticii īn procesul proiectarii de arhitectura. Este bine de stiut ca instrumentele pe care ni le pune la dispozitie nu sīnt nici panacee din care sa facem fetisuri, dar nici rebuturi pe care sa le ignoram cu aroganta. Afirm acesta pentru ca īn timp am avut ocazia sa īntīlnesc la colegi de breasla o atitudine de suficienta, usor dispretuitoare - chiar daca neafisata explicit - fata de preocuparile īndreptate īn aceasta directie, sau dimpotriva un entuziasm nejustificat de mare. Asta ca sa nu mai vorbim de complexele de inferioritate pe care unii le dobīndesc datorita orgoliului propriu care īi īmpiedica sa accepte ca mai au de īnvatat, sau ca nu sīnt singurii care gīndesc. Cred deasemeni, ca nici tabara informaticienilor nu este straina uneori de sentimentul de suficienta - īn raporturile cu "ceilalti" - dat de cunosterea unor mecanisme care ramīn tabu pentru profani. Mai ales cīnd aceasta cunoastere creeaza senzatia de "demiurg", de stapīn al domeniului pentru care aceste mecanisme sīnt folosite. Atitudine la fel de periculoasa, pentru ca a sti - de exemplu - sa utilizezi corect comenzile unui "Picture Publisher" nu īnseamna ca esti pictor. Dar astea sīnt mici scapari ale naturii umane si īn fond sīnt lipsite de importanta.
Revenind la utilitatea informaticii ,īn ce ma priveste, pot spune ca folosirea calculatorului īn practicarea meseriei a fost si este benefica. Am observat si la mine si la colegii mei ca aceasta unealta ne-a facut sa gīndim lucrurile altfel decīt am facut-o pīna acum inducīndu-ne o rigurozitate mult mai mare si ajutīndu-ne sa descoperim mult mai repede si mai usor zonele care īn proiectarea traditionala, de regula, ramīn īn penumbra. Totodata, ne este de folos īn risipirea īndoielilor pentru cazurile unor rezolvari aflate pe muchie de cutit. Cert este ca micile autopacaleli de genul "lascancape la 1:50" nu mai au suport.
Am avut privilegiu de a participa la crearea unui soft dedicat proiectarii pentru arhitectura; este vorba de "Arcade". Sīnt convins ca aceasta experienta m-a ajutat foarte mult īn īntelegerea fenomenului informatic dincolo de suprafata si mi-a permis sa fac o evaluare mai apropiata de realitate a raporturilor sale cu meseria mea. La aceasta s-a adaugat si faptul ca legaturile mele cu lumea informaticii au devenit puternice prin contactul strīns cu cei care au dat viata revistelor "PC Report", "Open IT", "BYTE Romānia" si mai nou "CAD report". Am fost aproape de evolutia spectaculoasa a acestui domeniu si am gasit īntotdeauna pe līnga informatiile de ultima ora, raspunsuri competente si documentate la nedumeririle sau īntrebarile mele. Ceea ce recunosc ca nu este putin lucru si nici la īndemīna tuturor.
Atunci cīnd ne-am decis sa facem programul pentru arhitectura, primul pas a fost sa stabilim segmentul de proiectare īn care acesta ne-ar fi adus foloase cīt mai mari īn practicarea meseriei de zi cu zi. Evident ca am ales zona de mijloc (vezi motivatiile de mai sus), urmīnd ca īn viitor sa īncercam abordarea unor teme cum ar fi restitutia perspectiva sau modelarea libera, de la care sa fie posibila trecerea inteligenta spre soft-uri destinate partii tehnice a proiectarii. Si am considerat ca drumul trebuie sa fie cel natural: de la tridimensional catre conventiile de desenare 2D. O alta premisa de la care am plecat a fost aceea ca programul trebuia sa fie capabil sa abordeze generalul, sa nu devina o colectie de cazuri particulare cum se īntīmpla īn multe programe din domeniu. Cu alte cuvinte, primitivele arhitecturale definte prin program trebuiau sa fie capabile sa se comporte "natural" īn toate ipostazele lor si nu doar īn pozitii particulare. Cel mai edificator exemplu īn acest sens īl constituie acoperisurile: de regula, īn programele consacrate apelarea unei comenzi de acest gen deschide o fereastra de dialog īn care sīnt "ofertate" utilizatorului cīteva posibilitati: acoperis īntr-o apa, īn doua ape (cu pante egale), si īn patru ape (la fel, cu pante egale),... si cu asta cam ... basta. Īn "Arcade" lucrurile stau ceva mai bine: este posibila realizarea de acoperisuri cu oricīte ape (fete), fiecare dintre acestea putīnd avea orice panta; se pot executa operatii de reunire a doua sau mai multe acoperisuri, pot fi editate separat fiecare dintre fetele acoperisului, iar corpurile de tip AutoCAD pot fi transformate īn entitati de tip acoperis si tratate ca atare.
Punctul de pornire, de la care programul urma sa devina operational, l-am considerat a fi momentul īn care solutia volumetrica a fost conturata si arhitectul a elaborat ceea ce īn mod traditional se cheama "schita de schita". Programul trebuia sa puna la dispozitie utilizatorului procedee de modelare 3D, cu care sa poata obtine īn realitatea virtuala a calculatorului un "model viu" al schitei de schita, si procedee de "exprimare" a modelului īn conventii traditionale de desenare si de masurare. Acest "model viu" trebuia sa fie capabil sa devina o replica 1:1 a realitatii (ex. sa fie construit din ziduri care sa fie ziduri si nu linii cu thickness, din scari care sa fie scari si nu altceva etc.), sa fie usor modificabil direct īn 3D si sa se constituie ca o referinta permanenta pentru transferul 2D si pentru calculul economic (volume, suprafete, bucati etc.).
Si cred ca am reusit. Pentru argumentare voi face o referire succinta la cīteva puncte forte ale acestuia. Uneltele de modelare "Arcade" confera multa usurinta īn generarea de volumetrii "neortodoxe" precum si o mare libertate de decizie utilizatorului, atīt īn ceea ce priveste editarea primitivelor arhitecturale direct īn 3D, cīt si īn modul liber de raportare al acestora la layer-e (entitatile nu sīnt "ancorate" īn mod automat de layer-e cu nume impuse de program - ca īn cazul modului A/E/C).
Am convingerea ca la capitolul modelare tridimensionala "Arcade" este unul dintre cele mai puternice soft-uri existente pe piata. O alta facilitate creata a fost mecanismul de obtinere a imaginilor perspectivate. Pornind dintr-un punct de observare ale carui coordonate pot fi precizate cu rigurozitate, poate fi realizata o "plimbare" īn interiorul sau exteriorul cladirii cu posibilitatea modificarii pe parcurs a mai multor parametri (distanta focala, tinta, punctul de observare, marimea "pasilor"). Pentru a controla constructia din punct de vedere cantitativ si pentru a identifica fiecare element de constructie generat, au fost create mecanisme de etichetare si de calcul ce permit identificarea obiectelor si obtinerea de rapoarte de cantitati pentru fiecare dintre ele. Iar reprezentarea 2D se face pornind de la modelul tridimensional. Este posibila realizarea de sectiuni si vederi dupa o directie data precum si de proiectii plane care (pe līnga contururile zidurilor), redau īn mod conventional scarile si tīmplariile, cu valori atasate (h treapta, h parapet, h gol, etc.). Desi nu am pus accent pe bibliotecile de elemente (din considerentul ca fiecare utilizator are o personalitate proprie), ne-am gīndit la un mecanism prin care pot fi create, īntretinute si apelate cu usurinta biblioteci "personale" care sa stocheze elemente sau subansambluri concepute de utilizator. Soft-ul rezultat s-a dovedit a fi un instrument de lucru foarte bun (nici nu se putea altfel), iar rezultatele obtinute de noi cu ajutorul lui au fost dosebite. Mai ales ca nu am īncercat sa-l folosim pentru ce nu a fost proiectat.
Viitorul va impune cu siguranta folosirea pe scara larga a calculatorului īn proiectarea de arhitectura. Aparitia limbajelor de programare orientate obiect precum si accesibilitatea din ce īn ce mai larga a utilizatorului la masini cu putere de calcul din ce īn ce mai mare vor face ca multe din dorintele de astazi sa devina realitate si multe din neajunsurile īntīmpinate acum sa dispara. Deja este posibila crearea de obiecte cu "constiinta de sine" care reactioneaza inteligent īn functie de context (ex: ziduri care se extind automat daca vecinii "se muta" si se racordeaza cu zidurile vecine proiectate din acelasi material, plansee care īsi schimba conturul daca peretii limitatori īsi modifica pozitiile, scari ce īsi modifica traseul prin simpla tragere de "linia pasului" etc.). Si evident, toate acestea se īntīmpla īn 3D, iar aceste exemple nu sīnt decīt partea vizibila a aisbergului. Este de la sine īnteles ca īn acest caz modelarea tridimensionala va deveni mult mai accesibila si mai placuta decīt este īn prezent si ne va permite noua, arhitectilor sa ne concepem solutiile "direct pe calculator".