IKTA-KÉPI 00101/2000 projektSzerzõdés számok: OMFB-00179/2001, OMFB-00190/2001

Fotorealisztikus képszintézis CAD rendszerekben

FELHASZNÁLÓI ÉS INTERFÉSZKÖVETELMÉNYEK

1.1 verzió: 2001.05.19.

ÍRTA:Csonka FerencAntal György

dr. Sparing LászlóKelemen CsabaKovács LászlóPolyák TamásPalotás Csaba

ELLENÕRIZTE:dr. Szirmay-Kalos László

dr. Horváth Tamás

I

Tartalomjegyzék

1. Bevezetõ ................................................................................................................1

2. Képszintézis igények építészeti CAD rendszerekben........................................5

2.1. Mûveleti megjelenítés...................................................................................52.2. Prezentációs megjelenítés .............................................................................62.3. Világítás- és színtervezés..............................................................................72.4. Fizikai alapú anyagjellemzõk........................................................................92.5. Fizikai alapú fényforrások.............................................................................92.6. Cache-lés .......................................................................................................10

3. Az ArchiCAD inkrementális képszintézise........................................................13

3.1. Az ArchiCAD jelenlegi jellemzõi.................................................................133.1.1. Transzformációk...................................................................................133.1.2. Tárgydekompozíció és elhelyezés a virtuális világban........................13

3.1.2.1. Felhasználói oldal........................................................................143.1.2.2. Reprezentáció..............................................................................14

3.1.3. Elhelyezés a kamera koordináta-rendszerben......................................143.1.4. Térbeli vágás........................................................................................143.1.5. Láthatósági és takarási problémák megoldása .....................................15

3.1.5.1. Pásztalapú megoldás ...................................................................153.1.5.2. Mélységi puffer alapú megoldás.................................................16

3.1.6. Árnyalás ...............................................................................................173.1.6.1. Fényforrások................................................................................173.1.6.2. Anyagjellemzõk ..........................................................................173.1.6.3. Megvilágítási modell...................................................................183.1.6.4. Textúrakezelés.............................................................................18

3.1.7. Effektek ................................................................................................193.1.7.1. Árnyék.........................................................................................193.1.7.2. Köd..............................................................................................19

3.1.8. Színleképezés.......................................................................................203.1.9. Elõzetes képeken alapuló szintézis ......................................................20

3.1.9.1. QuickTime VR............................................................................203.1.9.2. Fotogrammetriai képességek.......................................................21

3.1.10. Igények...............................................................................................22

3.2. A tudományos élet kapcsolódó eredményei..................................................223.2.1. Árnyékvetés..........................................................................................23

3.2.1.1. Sugárkövetett árnyékok...............................................................233.2.1.2. Mélységi puffer alapú árnyékvetés .............................................233.2.1.3. Árnyéktérkép...............................................................................24

3.2.2. A mélységi puffer gyorsítása................................................................25

II

3.2.3. Sugárkövetés gyorsítása mélységi pufferrel.........................................253.3. Hardveresen gyorsított háromdimenziós megjelenítés .................................25

3.3.1. A mai videókártyák képességei............................................................263.3.2. A statikus megvilágítási modell gyorsítása..........................................263.3.3. A dinamikus megvilágítási modell gyorsítása .....................................273.3.4. Hardveres transzformáció és megvilágítás...........................................273.3.5. Mélységi puffer gyorsítási módszerek .................................................27

3.3.5.1. Az ATI HyperZ módszere...........................................................283.3.5.2. A tile-based deferred rendering...................................................28

4. További grafikus rendszerek bemutatása..........................................................31

4.1. Integrált, modellezõ alrendszerrel rendelkezõ programok............................314.1.1. 3D Studio MAX...................................................................................32

4.1.1.1. Anyag- és fényforrásjellemzõk ...................................................324.1.1.2. Kezelt fájl formátumok ...............................................................324.1.1.3. Plugin renderer interfész.............................................................344.1.1.4. mental ray....................................................................................34

4.1.2. Maya .....................................................................................................364.1.2.1. Anyag- és fényforrásjellemzõk ...................................................374.1.2.2. Kezelt fájl formátumok ...............................................................404.1.2.3. Rendering plugin.........................................................................414.1.2.4. Lightflow Rendering Tools .........................................................41

4.1.3. Desktop Radiance.................................................................................434.1.3.1. Radiance......................................................................................434.1.3.2. AutoCAD ....................................................................................444.1.3.3. Kezelt fájl formátumok ...............................................................444.1.4.4. Desktop Radiance........................................................................454.1.3.5. Könyvtári elemek ........................................................................46

4.1.4. trueSpace ..............................................................................................484.1.5. Architech.PC ........................................................................................49

4.1.5.1. A kezdetek...................................................................................494.1.5.2. Az új képszintézis alrendszer ......................................................504.1.5.3. A második verzió ........................................................................514.1.5.4. A harmadik verzió.......................................................................524.1.5.5. A negyedik verzió .......................................................................534.1.5.6. Jövõbeli tervek, prototípusok ......................................................54

4.2. Csak képszintézis alrendszerrel rendelkezõ programok................................564.2.1. Lightscape ............................................................................................57

4.2.1.1. Könyvtári elemek ........................................................................574.2.1.2. Kezelt fájl formátumok ...............................................................584.2.1.3. Globális illuminációs megoldása ................................................59

4.2.2. Artlantis................................................................................................604.2.2.1. Egyszerû felhasználói felület ......................................................614.2.2.2. Anyag- és fényforrásjellemzõk ...................................................62

III

4.2.2.3. Kezelt fájl formátumok ...............................................................644.2.2.4. Globális illuminációs megoldása ................................................64

4.2.3. RenderPark...........................................................................................664.2.3.1. Beépített algoritmusok ................................................................674.2.3.2. A RenderPark további jellemzõi.................................................674.2.3.3. Új algoritmus fejlesztése .............................................................69

5. Az ArchiCAD és más grafikus rendszerek összehasonlítása ...........................71

5.1. Az ArchiCAD jelenlegi képszintézis alrendszerének jellemzõi....................715.2. Az ArchiCAD hiányosságai..........................................................................725.3. Más grafikus rendszerek jellemzõibõl leszûrt tapasztalatok.........................725.4. A jelenlegi rendszer javítására, gyorsítására vonatkozó javaslatok ..............72

5.4.1. Rövid távú javaslatok...........................................................................735.4.2. Hosszú távú javaslatok.........................................................................73

6. A globális illuminációs elvû program és az ArchiCAD összekapcsolása........75

6.1. Offline kommunikáció ..................................................................................756.1.1. I/O add-on alapú megvalósítás.............................................................756.1.2. Fájl formátumok...................................................................................76

6.1.2.1. SCE formátum.............................................................................766.1.2.2. MGF formátum............................................................................766.1.2.3. VRML formátum.........................................................................776.1.2.4. 3DS formátum.............................................................................776.1.2.5. XML............................................................................................78

6.2. Online kommunikáció...................................................................................806.2.1. Rendering add-on.................................................................................80

7. A globális illuminációs elvû program felhasználói felülete ..............................81

7.1. Az önálló, globális illuminációs elvû program.............................................817.1.1. Bejárás, kamera elhelyezése.................................................................817.1.2. Véges elemes felbontás paramétereinek beállítása ..............................82

7.2. Az integrált, globális illuminációs elvû program..........................................827.2.1. Bejárás, kamera elhelyezése.................................................................827.2.2. Véges elemes felbontás paramétereinek beállítása ..............................82

Irodalomjegyzék.......................................................................................................83

1

1. Bevezetõ

A számítógépi grafika és ezen belül a képszintézis alapvetõ célkitûzése, hogy aszámítógépben tárolt virtuális modellt lefényképezze és a felhasználóban a valóságszemlélésének illúzióját keltse. Az alábbi ábrán balra a virtuális modell, jobbra pedig amodellrõl készült kép látható.

1.1. ábra: a képszintézis feladata a virtuális modell lefényképezése

A valós világéval megegyezõ hatású képi inger elõállításához ki kell számítani, hogy amonitor pixeleinek megfelelõ térszögbõl milyen spektrális eloszlás és spektrumonkéntmekkora fényintenzitás érkezne a megfigyelõ szemébe. Azonosítani kell tehát a pixelbenlátható felületi pontokat és azok szem irányú sugársûrûségét (radiancia). Asugársûrûséget az optika törvényei szerint az ún. árnyalási egyenlet (rendering equation)megoldásával lehet meghatározni.

Leegyszerûsítve azt is mondhatjuk, hogy a számítógépi grafika képszintézis (rendering)ága ezen egyenlet megoldásával foglalkozik. Mivel a feladatot több tényezõ nehezíti csaknagyon speciális eljárásokkal és a fizikai modell durva egyszerûsítésének árán kaphatunkelfogadható sebességgel képeket. Ezek az egyszerûsítések az integrál operátoron belüliismeretlen sugársûrûséget a fényforrások ismert emissziójával közelítik, azaz a láthatópont színének meghatározásánál csak a fényforrásokból érkezõ direkt megvilágítástveszik figyelembe, a más felületekrõl visszavert indirekt megvilágítást nem. Mivel ekkora pont színe a fényforrásokon kívül csak a lokális anyagjellemzõktõl és geometriátólfügg, a módszerek közös neve lokális illuminációs modellek. A durva elhanyagolásokmiatt a lokális illuminációs módszerekkel létrehozott képek, legyenek azok bármilyenszépek, vizuálisan és fizikai értelemben is pontatlanok, így mérnöki alkalmazásokban -például világítás- és látványtervezésben - nem használhatóak. Ezekben azalkalmazásokban fizikailag pontos eredményt várunk el, ezért nem tekinthetünk el azárnyalási egyenlet integrálegyenletkénti megoldásától. Ekkor tehát az indirekt

2

megvilágítás hatását is figyelembe kell venni, így egy pont sugársûrûségét elvileg azösszes többi felületi pont sugársûrûrége is befolyásolja. A csatolás hangsúlyozására ezenmódszereket globális illuminációs modellként ismeri a szakirodalom. Az 1.2. ábrán kétlokális és egy globális illuminációs modellel készült kép látható.

1.2. ábra: három golyó lokális (fent) és globális (lent) illuminációs modellel valómegjelenítése. A felsõ sorban a három golyó árnyék nélküli (bal oldali kép)

és árnyékkal (jobb oldali kép) rendelkezõ képei láthatók.

A projekt célja egy új megközelítésû, CAD rendszerekhez illeszthetõ, globálisilluminációs elvû képszintézis program elkészítése. A CAD rendszerek és a globálisilluminációs program közötti kapcsolat megvalósítására két alternatívát dolgozunk ki. Azegyik alternatíva az offline megoldás, amely azt jelenti, hogy a két alkalmazás egy

3

közbülsõ fájl formátumon keresztül kommunikál. A másik megoldás online jellegû,amely azt jelenti, hogy a globális illuminációs program beintegrálódik a CAD rendszerbe.

A továbbiakban CAD rendszer alatt a Graphisoft ArchiCAD nevû programját értjük([21]), és az integráció is az ArchiCAD rendszerében fog megtörténni. Ez nem jelenti azeredeti feladat leszûkítését, mert mindvégig olyan megoldásokra törekszünk, amelyeketmás CAD rendszereknél is alkalmazni lehet. Éppen ezért e dokumentum egyik fõ céljaazon megoldások összegyûjtése, rendszerezése, amelyek használatával más CADrendszerekhez is készíthetõ globális illuminációs alkalmazás, illetve a projekt keretébenelkészülõ programot is lehet majd hozzájuk illeszteni. Ezért a 4. fejezetben részletesáttekintést kívánunk nyújtani más, már mûködõ rendszerek offline és onlinemegoldásairól. Természetesen, ezeknél a rendszereknél a felhasználói felületi jellemzõketis megvizsgáljuk, hisz ezek figyelembevételével készíthetünk csak tényleg általánosanhasználható globális illuminációs elvû alkalmazást.

A dokumentum másik célterülete a CAD rendszer jelenlegi képszintézis alrendszerénekfeltárása. Megvizsgáljuk, hogy a jelenleg alkalmazott módszerek, algoritmusok és elvekmilyen mértékben alkalmazzák a tudományos eredményeket, mennyire vannaklemaradva napjaink tudományos élvonalától. Az elemzés egyrészt a Graphisoftnakrálátást ad CAD rendszere naprakészségérõl, amely jó alap lehet más CAD rendszerekkelvaló összehasonlításhoz. Másrészt feltárja a rendszer képszintézisben rejlõ hiányosságait,és ezzel jó összehasonlítást tesz lehetõvé a projekt keretében létrejövõ alkalmazással. Afeltáró munka eredményeit a 3. és 5. fejezetek tartalmazzák.

A dokumentum utolsó két fejezetében az elõzõekben összegyûjtött megoldásokfelhasználásával az elkészítendõ alkalmazás felhasználói és interfész követelményeitadjuk meg.

4

5

2. Képszintézis igények építészeti CAD rendszerekben

A projekt azt szeretné bizonyítani, hogy a mai globális illuminációs képszintézisalgoritmusokat lehet kommerciális alkalmazásokban, különös tekintettel építészeti CADrendszerekben használni. Ezért ebben a fejezetben azokat a problémákat kívánjukbemutatni, amelyeket a globális illuminációs képszintézis felvet. Ezen problémákmegfogalmazásához áttekintjük, hogy a mai építészeti CAD rendszerekben melyfeladatokra milyen képszintézis igények merülnek fel. A fejezet végén bemutatunk egyolyan módszert, amely azt mutatja, hogy milyen tipikus problémák merülhetnek felszimulációs feladatok megoldásánál, illetve a felvetett problémára milyen megoldástérdemes választani.

Az építészeti megjelenítési feladatok három alapvetõ kategóriába sorolhatók. Az elsõbeaz interaktív mûveletek, míg a másodikba a prezentációs célú alkalmazások tartoznak. Aharmadik kategóriába azok a feladatok tartoznak, amelyek - egyelõre még - nemelterjedtek, sõt, jelenleg is kutatottak, és mérnöki igényû világítástervezésre alkalmasak.Ezek a szolgáltatások várhatóan bonyolultak és a korábbiakhoz képest igenmûveletigényesek lesznek.

2.1. Mûveleti megjelenítés

Az interaktív grafika az építészeti tervezõ szoftverek elengedhetetlen feltétele. Ez arra afelismerésre épül, hogy ha a kétdimenziós alaprajzi tervezés még nem is sokkalhatékonyabb, mint a hagyományos rajzasztali megoldás, a bevitt geometriai adatokbólmég egy korai PC - ma már mulatságosnak ható teljesítménye - is szemvillanásnyi idõalatt volt képes tetszõleges nézõpontból háromdimenziós vonalas képet produkálni. Már akezdetekkor is igény merült fel a vonaltakart képekre, sõt, a kitöltöttekre is. Utóbbiakatszínezett vagy árnyalt képeknek is hívhatjuk. Ezek hagyományosan a számítógépeskorszak elõtt is - szükség szerint - a tervi dokumentáció részét képezték. A CADalkalmazások kezdetén az árnyalt képek elõállítása még nem tartozott az interaktívszolgáltatások közé.

Ezen a téren a lehetõségek igencsak kibõvültek a grafikus gyorsító alrendszerek révén,amelyek elképesztõ teljesítménynövekedést jelentenek, így igényesebb megoldások isszerepelhetnek a tervezési folyamat mûveleteiben, a grafikus szerkesztésekben. Ateljesítményrobbanás ellenére mégis azt gondoljuk, hogy ezen a területen igazán nagyproblémát nem a megjelenítõ algoritmusok jelentenek (noha az analitikus pontosságúvonaltakarás feladat még mindig érdekes téma lehet), hanem ezek megfelelõ beágyazásaa tervezõ rendszerbe, amely igen munkaigényes. Vagyis a mûveleti megjelenítéskategóriájában fõleg programszerkezeti problémákkal találkozunk. Az objektumtechnológia használatával elérhetjük, hogy ezek az eszközök újrafelhasználhatóak ésviszonylag könnyen használatba vehetõvé váljanak - észben tartva azt a szempontot is,hogy nemcsak a képernyõre, hanem más perifériára (például rajzgépre) is irányíthatólegyen az eljárás. Sajnos, az elterjedt OpenGL technológiában, amely CAD-es

6

alkalmazásának - a számítástechnikában rangot jelentõ - több mint egy évtizedes múltjavan, nem megoldott a rajzgépek és egyebek támogatása.

Ebben a kategóriában elsõsorban a geometriára kerül a hangsúly. Fõleg a geometriahatározza meg az elvárásokat, ezért az igazán bevált megoldások a legegyszerûbb, nemvalószerû megjelenítési módszerek. Noha az OpenGL igen nagy teljesítményével márkifinomultabb képi hatásokat is produkálhatunk, a tervezés nagy része mégis aszerkezetre irányul és nem a fényviszonyokra. Ezért - sajnos - itt az egyszerû '70-eséveket idézõ, de immáron valósidejû grafika jelent megoldást.

Ma már az nem vitatható, hogy az építészeknek is ki kell lépniük az alaprajzi tervbõl és aháromdimenziós képeken nemcsak szemlélõdniük, hanem tervezniük, szerkeszteniük iskell. Az OpenGL szerencsés példáját mutatja annak, hogy a két, eredetileg távolimegjelenítés mód, vagyis a 2D és 3D mennyire közös nevezõre hozható azzal azelfogadható pazarlással, amely a grafikus gyorsító rendszerben végbemegy, amikor akétdimenziós rajzokat is térbeli alakzatként kezeli.

2.2. Prezentációs megjelenítés

A prezentációs megjelenítéshez a szép képek és az animációk tartoznak, amely feladatokesetén a geometria egyszerû bemutatása ma már nem elegendõek. Szükség van avalóságos látványt közelítõ, de azért kellemesen nagystílû fényhatásokra, amelyeknekvégsõ soron az a célja, hogy az építész a tervét elõnyös megvilágításban bemutathassa.Természetesen az is igaz, hogy a tervezõrendszer készítõje is elõnyre tehet szert, haprospektusaiban nemcsak a triviálisan árnyalt ábrák egyhangúsága szerepel.

A szórólapok egy-egy sikerültebb kép mellett azt is állítják, hogy ezek fotorealisztikusak,vagyis olyanok, mintha fotók volnának valamirõl, amely meglehet meg sem épült, de amögöttes eljárások oly' hûen utánozták a fény szóródását, tükrözõdését, árnyékait, hogy afelhasználó elõre megkapja épületének külsõ-belsõ látványát, sétálgathat benne, körülrepkedheti stb. Mi több! A termekbe lámpákat helyezhet el, amelyek megvilágító hatását- belsõépítészi igényekkel - a képrõl megítélheti. Ehhez nincs szükség a kész épületre,elég a virtuális is.

Ez természetesen nem igaz! Ugyanis még ha a látvány nagyon is valószerû, az még a hûmodellezésre egyáltalán nem utal. Ténylegesen ilyen nincs is mögötte. Mégis ma aháromdimenziós számítógépi grafika legjövedelmezõbb felhasználása éppen az "olyanmintha" hatás, amelynek "varázslásához" az egzakt szimulációs gondolkodás számárameglepõen "gátlástalan" megoldásokhoz is folyamodnak. Rengeteg "fizikailag" pontatlanvagy egyenesen értelmezhetetlen attribútummal látják el a geometriai modellt és aképelõállító eljárást. Tipikus eset a 3D Studio, illetve utóda, a 3D Studio MAX,amelyekben a felületi fényvisszaverõ tulajdonságokat úgy be lehet állítani, hogy avisszavert fény megháromszorozódik a beérkezõhöz képest. Ehhez persze szükséges azis, hogy kellõ jártasággal rendelkezzünk egy meglehetõsen bonyolult párbeszédablakparaméterezésének kezelésében. Egy építésznek szerencsésebb volna, ha kapna valami

7

egyszerûbbet (az integráltság elõnyével kiegészítve), amely képes arra, hogy atervezésben használt elemekhez eleve megfelelõ attribútumok kapcsolódjanak és ezekután egy hatásos színes kép elkészítéséhez elég legyen egy gombnyomás.

Sajnos, ebben a "varázslásban" jelenleg az építészek áldozatok: kénytelenek egyanimációra napokat várni, egy tökéletes nagyfelbontású képre órákat. Ráadásul a "hadddolgozzon a gép, a legjobbat akarom!" szemlélet is jellemzõ.

Ezért a prezentációs megjelenítés szintjén az eljárások interaktívvá gyorsítása nem igazánérv. Sokkal fontosabb, hogy az optikai attribútumok beállítása a lehetõ legkevesebbmunkát igényelje és biztosítva legyen ezek "könyvtárazása". Fontos, hogy ezekkel azattribútumokkal az "újrafelhasználható" építészeti és berendezési modellelemekmegfelelõen felruházhatók legyenek. Ekkor zökkenõmentesen biztosítható, hogy a tervmódosításakor a megjelenítés miatt ne legyen szükség külön munkára.

Igaz ugyan, hogy a számítási idõre mindig panasz van ha nem OpenGL alapú algoritmusthasználunk, de az OpenGL-lel csak igen sok bonyodalom árán tudunk azalapszolgáltatások körébõl kilépni. Ezáltal nem juthatunk el ahhoz a képminõséghez,amelyet a hagyományos sugárkövetéssel - elvébõl következõen - viszonylag egyszerûenelérhetünk. Ezért e területen a sugárkövetés (ray-tracing) módszere komoly tényezõnekszámít, míg az OpenGL az igazán gyors, fejlesztõknek is egyszerûen kezelhetõmegjelenítés területén játszik fontos szerepet.

Az elsõ sugárkövetõ programot Whitted publikálta ’80-ban ([18]). Rekurzívsugárkövetése az ideális tükrözõdés irányában továbbkövette a szembõl kibocsátottfényutat. Ezt az eredményt követte Cook elosztott sugárkövetése (distributed ray-tracing)’84-ben ([19]), amely már sztochasztikus fényforrás-mintavételezéssel dolgozott.Matematikai alapokkal Kajiya szolgált ’86-ban ([20]): az árnyalási egyenlet megadásávalés egy olyan sztochasztikus sugárkövetés kidolgozásával, amely - a fény mikro-tulajdonságaitól eltekintve - megoldotta a globális illuminációt.

Az épülettervek animált megjelenítése azzal a figyelemreméltó elõnnyel bír, hogy amodell nem mozog, általában mozgó alkatrészei, elmozduló fényforrásai sincsenek, csaka nézõpont vándorol. Emiatt a radiozitás (radiosity) ([3]) eljárás felhasználása, amelyszintén klasszikus a maga nemében, csábító lehetõség. Bár egyszerûsége miatt csak afényt szóró diffúz esetre szól, ez a kompromisszum azzal az elõnnyel jár, hogy azOpenGL adta gyorsítás itt ismét bevethetõ és az épület bejárása teljesen interaktívvátehetõ.

2.3. Világítás- és színtervezés

A világítás- és színtervezés, szemben az elsõ pont sematikus, s a második hatásvadászcéljaival, már mérnökit és tudományost jelent - a fény és a tagolt tér kölcsönhatásánakmodellezését tekintve.

8

Ezen a területen a kulcsfogalom a "fizikai alapú modellezés". Alapja az úgynevezettárnyalási egyenlet (rendering equation) ([20]), amelynek megoldására már rengetegmódszert dolgoztak ki, de igazándiból egyik sem oldja meg az eredeti problémát, csakapproximált megoldásokat képesek nyújtani. Felmerülhet a kérdés, hogy ennek mi köze avilágítástervezéshez? Egyáltalán miért van erre szükség?

Ezt a kérdést jogosan vetheti fel egy statikus, aki olyan egyszerûsített modellel dolgozik,amelyen már könnyû számolni. Vagy például egy fûtéstervezõ, aki szintén valamilyenséma szerint saccolja meg fûtõtestek teljesítményét és helyét. Ezek után mégerõteljesebben felmerül a kérdés: a világítástervezéshez miért nem elegendõek a beváltmódszerek, amelyek már a számítógépes támogatás elõtt is rendelkezésre álltak?

Látnunk kell, hogy a számítógéppel - a manuális módszerekhez képest - valamilényegesen új jelent meg a tervezésben. Már régtõl nem egy jobb rajzasztalról beszélünk,hanem egy olyan egyedülálló képességrõl, amely a bevitt tervbõl képes egy sajátvalóságot generálni. Ezt virtuálisnak is szokták nevezni. Ez az alapvetõ tulajdonságerõsödik a tervezõ rendszerekben, illetve az az igény, hogy a virtuális valóság minéljobban hasonlítson a valódira. Ezért egyre mûveletigényesebb és kifinomultabbalgoritmusok jelennek meg. Másképpen fogalmazva, arra kell törekednünk, hogy atervezõ ne egy elvonatkoztatáson dolgozzon, hanem a számítástechnikát, mintmegvalósítót adjuk kezébe, hogy általa már a virtuális térben megítélhesse mûvét.

Vitathatatlan, hogy ebben a "leglátványosabb" eredményeket a számítógépi grafikátólvárhatjuk. Ehhez "csak" megfelelõ algoritmust kell találnunk. Ezen felül fizikailagmeghatározott karakterû fényforrások, fénnyel kölcsönhatásba lépõ felületek és közegekpontos, kimért adatsorát kell biztosítanunk. Az algoritmus feladata az, hogy ebbõl azadathalmazból elõállítsa azt a képet, amelyet a virtuális kamerában kapnánk. Sajnos, ez afeladat tisztán elméletileg nem is algoritmizálható. Ez némi magyarázatot ad arra, miértvan ezen a területen ennyi megoldás kisebb-nagyobb hibákkal és egyáltalán, miért olyannem várt módon nehéz a feladatunk. Szerencsére a gyakorlat már mutatott néhány biztatóeredményt.

A másik nagy problémakör nem ilyen természetû. Szükség van a tervben szereplõtárgyak és szerkezeti elemek fénytani tulajdonságainak pontos bevitelére. A szerencsés azvolna, hogy ezeket már maguk a gyártók elektronikus formában, sõt a program nyilvánosadatszerkezetében leírva adnák meg. A lámpagyártóktól ez különösen elvárható lenne.

Az épületek látványában, valamint termeik félhomályában az égbolt a fõ megvilágító.Változatos színhatásait durva egyszerûsítések nélkül kell modelleznünk. Továbbágarantálnunk kell, hogy az egész feldolgozási láncban nincs torzítás, a színek végülhelyesen kerülnek a képernyõre vagy a nyomtatóra.

Csak ebben az esetben beszélhetünk olyan virtuális valóságról, amely a világítástervezésalapját adhatná. A színdinamikai vizsgálatok különösen érzékenyek, mert a különbözõszínek olyan harmóniacsoportokat alkothatnak, mint a zenében az akkordok, amelyeketegy kis pontatlanság is eltorzíthat, meghamisíthat.

9

2.4. Fizikai alapú anyagjellemzõk

Már a prezentációs szinten megfogalmaztuk, hogy szükség lenne a maianyagmodellekhez viszonyítva az anyagjellemzõk egyszerûbb leírására. Ahhoz, hogy eza megadási módszer elterjedtté váljon könyvtárak kialakítására van szükség. Akönyvtárak használatával a gyártók termékkatalógusokat alakíthatnak ki. Megjegyezzük,hogy a Graphisoft a GDL (Geometry Description Language) leíró nyelvével pont ilyenkönyvtárazási lehetõséget biztosít.

Ráadásul ennek az új leírási módnak mérhetõ tulajdonságokat kellene tartalmaznia, hiszegyrészt ez a világítás- és színtervezésnél alapkövetelmény. Másrészt, a gyártókfizikailag korrekt attribútumokkal termékkatalógusaikat könnyen létrehozhatják, nem kellhónapokat tölteniük ambiens, diffúz stb. tényezõk beállításával. Ezáltal a "varázslási"idõszakra fordított hatalmas pénzösszegek radikálisan csökkenthetõk. Ráadásul ezlehetõséget biztosítana a hasonló célú termékek valódi összehasonlítására.

Az alábbiakban öt jellemzõt foglaltunk össze, amelyek mérhetõek és jól jellemzik a valósvilágban elõforduló anyagokat:

• az anyag diffúz sugárzó képessége (emittance)• az anyag diffúz és spekuláris visszaverési képessége (reflectance)• az anyag diffúz és spekuláris áteresztõ képessége (transmittance)• az anyag törésmutatója

2.5. Fizikai alapú fényforrások

A világítás- és színtervezés szintjén merül fel az igény a fizikailag meghatározottkarakterû fényforrások használatára. Természetesen, ez nem jelenti azt, hogy az elsõ kétkategóriába sorolt feladatoknál fizikai alapú fényforrások nem alkalmazhatóak. Azonbanezeken a szinteken fizikailag pontos képszintézisre nincs igény, így – eddig -megelégedtek a fényforrások nem fizikai alapú meghatározásával is.

Itt is elmondhatók azok az elõnyök, amelyeket már a fizikai alapú anyagjellemzõknél ispéldaként felhoztunk. Ezeket azzal egészítenénk ki, hogy a fizikailag meghatározottkarakterû fényforrások publikálására, könyvtárakba szervezésére a lámpagyártókoldaláról már régóta igen komoly igény mutatkozik. Mielõtt összefoglalnánk azokat ajellemzõket, amelyekkel egy fényforrás karakterisztikáját fizikailag meg lehet határozni,néhány alapfogalmat definiálunk.

A fényerõsség SI mértékegysége a kandela (jele: cd). 1 kandela a fekete sugárzó 1 :600000 m2-nyi felületének a fényerõssége a felületre merõleges irányban a platinadermedési hõmérsékletén (2042,5K) és 101325 Pa nyomáson. Megjegyezzük, hogy ezkb. egy viaszgyertya fényerõsségét jelenti.

10

A fényáram SI mértékegysége a lumen (jele: lm). 1 lumen fényáram azt jelenti, hogyadott pont 1 steradián térszögbe 1 kandela fényerõsséget sugároz.

A teljesítmény SI mértékegysége a Watt (jele: W). 1 Watt teljesítmény egységnyi idõ alatt1 J munka végzését jelenti.

Fizikailag meghatározott karakterisztikájú fényforrások megadására a következõjellemzõket használhatjuk:

• a fényforrás típusa: pontszerû, szpot, területi (párhuzamos fénnyel nemfoglalkozunk)

• a fényforrás teljesítmény Wattban megadva• a fényforrás fényerõssége kandelában (vagy fényárama lumenben) megadva• a fényforrás által kibocsátott szín különbözõ hullámhosszokon mérve• a fényforrás sugárzásának eloszlása

Természetesen, nem kötelezõ az összes adatot biztosítani ahhoz, hogy még fizikai alapúfényforrás- illetve anyagmegadásról beszéljünk. Például ha az alkalmazás csak fehér ésegyenletes eloszlású fénnyel dolgozik, de a szimulációhoz a teljesítmény, fényáram stb.tulajdonságokat használja, akkor is fizikai alapú modellezésrõl és képszintézisrõlbeszélünk.

2.6. Cachelés

A szimulációs eljárások az építészeti CAD rendszerekben kisebbségben vannak aszerkesztõ funkciókkal és más interaktív szolgáltatásokkal szemben, amelyek már azelõzõ évtizedben is - csekély számításigényük miatt - szemvillanásnyi futási idõtigényeltek. Viszont az igényes számítógépes grafika a körülményes módszerekrõl semmondhat le, amelyek a fejlesztõ és a gép számára is egyaránt próbára tevõk. Ezekben és akapcsolódó szolgáltatásokban jócskán szerepelnek olyan részfeladatok, amelyeknekeredményét hagyományosan fájlokba mentették, vagy adatbázisokba tették. Ez az eljárásbár szükségesnek látszik, naiv megvalósítása az alábbi hátrányokkal rendelkezik:

1. A származtatott adatok, vagyis az említett részeredmények keverednek atörzsadatokkal. Ezáltal az adatszerkezet áttekinthetõsége csökken, az adatállománymérete nõ.

2. A programozónak ügyelnie kell a származtatott adatok konzisztenciájára. Ezzel aprogramozói interfészeken is kell foglakozni, plusz a feladat bonyolódást és így hibát isjelenthet.

3. Ha a részeredmény több adattól is függ, akkor ennek már nincs nyilvánvaló helye, ígya programozó egyedi megoldásokba kényszerül, amely megint bonyolódáshoz vezet, éshibaforrás lehet.

11

4. A részeredmények akkor is tárolva vannak, ha azok eddig még egyszer sem, vagy márrégóta nem lettek használva. Ez is pazarlásnak látszik.

Szemléltetõ példának kiváló az anyagmodellek könyvtárazása és kezelõi felületen valómegjelenése. Ehhez szükség van modellenként egy viszonylag kisfelbontású képre,amely hûen mutatja, hogy miként jelenik meg, mit várhatunk a fotorealisztikus képen. Ekép elkészítése 1-2 másodperc tipikusan, amely nem sok, de már ezt is gyötrelmes volnatallózáskor mindig kivárni. Tehát tegyük el a kis képeket az anyagmodellt leíró rekordokmellé! Ezáltal viszont az alábbi négy hátrányból részesülünk:

1. Az eredeti leíró úgy 30-100 bájtos rekord, míg a szemléltetõ kép 20-60KB, tömörítveesetleg kevesebb.

2. Leíró rekord változásakor automatikusan változnia kell a szemléltetõ képnek is, vagyjelezni kell érvénytelenségét. Ez egy nem magától értetõdõ mechanizmus, jó volnaelkerülni.

3. A képek függhetnek például a képernyõre vonatkozó beállításoktól (gamma érték,logikai felbontás stb.) is.

4. Ha már hetek óta nincs használatban az anyagmodelleket tallózó funkció, akkor is aháttértáron helyet foglalnak a kis képek - nagyjából 10-20MB-ot.

Vegyük észre, hogy a képek semmi olyan információt nem hordoznak, amelyet egymegjelenítõ algoritmus nem másikakból állított volna elõ, tárolásukra csupán azidõtényezõ miatt van szükség.

Az eredeti eljárás így nézne ki:

// a szemléltetõ kép elõállítása a paraméterek szerintsampleImage = render (materialRekord, screen.gamma, solid);

// a szemléltetõ kép megjelenítésedialog.draw (sampleImage);

Ha képet megõriznénk, akkor megfelelõ helyet is találnunk kell neki, és gondoskodnunkkell annak aktualitásáról is. Nyilván ez egy bonyolultabb eljárás volna, és találkoznánk azemlített hátrányokkal.

A C++ illetve Java objektum-orientált technológiáját használva olyan univerzáliscsomagoló õsosztályt készíthetünk, amely elvégzi az eljárás termékének ún. cache-lését -az adott paraméterezést figyelembe véve. A módszer globális háttértárterületet használ,illetve azt tartja karban. Ez azt jelenti, hogy valamilyen szempont szerint eldönti melyinformációkat hagyja meg és melyeket törli le. Itt feltételezzük, hogy már rendelkezünkegy ún. streamelõ infrastruktúrával, amely a C++ nyelvnek nem része, a Javanak viszontigen. Erre azért van szükség, mert az általános megoldás elvárja, hogy az eljárás értéke,valamint paraméterei - eltérõ okok miatt - "streamelhetõek" legyenek. Egy érték

12

"streamelése" a mentéshez és beolvasáshoz szükséges, A paramétereké viszont azt atetszõlegesen hosszú bit sorozatot szolgáltatja, amelybõl alkalmas függvénnyel 64 bitnyimintát állítunk elõ. Ez a minta azonosítóként szolgál. Elméletileg lehetséges, hogy ígykülönbözõ paraméterezések a fenti eszközzel képzett azonosítója megegyezik és emiattcsúnya hiba történhet - bár ez nem valószínû. Egy gyors becslés szerint úgy 10-100milliárd évente lehetséges ilyen és a több éves gyakorlatból azt tûnik ki e problémainkább csak elméleti, még nem találkoztunk ilyen ütközéssel.

Tehát az elõnyök:

1. Nincs keveredés a törzsadatokkal.2. A köztes adat rejtett, tehát nincs is gond az aktualizálásával. A használat egyszerû.3. Közömbös, hogy hány paramétertõl függ az eljárás.4. A háttérben futó "cache karbantartó" eldönti mely információkat érdemes megtartaniés melyeket törölni, így valószínû, hogy a régen használt adatok is az utóbbi sorsrajutnak.

A "cache karbantartó" jelenlegi változata a régen használtakat törli, de érdekes elméletikérdés vajon milyen elv volna itt az optimális.

13

3. Az ArchiCAD inkrementális képszintézise

A számítógépi grafika három fõ területének a modellezést, a képszintézist és az animációttekintjük. Utóbbi területtel az ArchiCAD esetében nem kívánunk foglalkozni, csak amodellezés és a képszintézis alrendszerekben alkalmazott algoritmusokat, elveketvizsgáljuk meg. Mivel az ArchiCAD inkrementális képszintézist alkalmaz, így amodellezést és a képszintézist ebben a keretrendszerben mutatjuk be.

A fejezet további részeiben a jelenlegi módszerek lehetséges továbbfejlesztéseittárgyaljuk. Az ArchiCAD képszintézis alrendszerének alapjait a ’90-es évek elején raktákle, így fontos azokat a módszereket, elveket áttekinteni, amelyek azóta a tudományosvilágban születtek. Másrészt mára az alsókategóriás háromdimenziós gyorsítókártyák és agrafikus processzorral rendelkezõ videókártyák olyan technikai szintet értek el, hogyalkalmasak az ArchiCAD-ben számos, ma még szoftverbõl megoldott feladatelvégzésére. Ráadásul ezek a kártyák ma már szinte minden PC-ben és Macintoshbanmegtalálhatóak, így mindenképpen érdemes megvizsgálni lehetõségeiket.

Megjegyezzük, hogy a projektnek nem az a célja, hogy az alkalmazott módszerekimplementációjának minõségérõl adjon információt, hanem a használt algoritmusok,elvek naprakészségérõl. Ezért az alkalmazott módszerek, elvek áttekintésekor próbáltunkolyan szintig hatolni, amíg az így elkészült összefoglaló nem tartalmaz belsõ, kifelé nempublikus információkat.

3.1. Az ArchiCAD jelenlegi jellemzõi

Az ArchiCAD jelenlegi háromdimenziós megjelenítéséért felelõs modulja és képszintézisalrendszere a növekményes (inkrementális) képszintézis módszerét valósítja meg. Eztháromdimenziós szerelõszalagnak ([1]) is hívják. A következõ alfejezetekben aszerelõszalag lépéseit külön-külön mutatjuk be.

3.1.1. Transzformációk

A háromdimenziós szerelõszalag számos lépéséhez szükséges affin és nem-affintranszformációk végrehajtása, amelyeket az egységes kezelhetõség kedvéért homogénkoordinátás (4x4-es) alakban szokták megadni. Ez azért is fontos, mert a mai hardverekis a homogén koordinátás alakot támogatják. Az ArchiCAD jelenleg 3x4-es mátrixokkaldolgozik memóriafoglalási szempontok miatt. Jelenleg is vizsgáljuk, hogy érdemeslenne-e átállni a 4x4-es megadásra.

3.1.2. Tárgydekompozíció és elhelyezés a virtuális világban

A modellezés lehetõségeinek bemutatása felhasználói és reprezentációs oldalról ismegtehetõ. A felhasználói oldal alatt azt értjük, hogy az ArchiCAD-ben milyenmodellezési lehetõségek állnak a felhasználó rendelkezésére. A reprezentációs oldal alatt

14

pedig azt értjük, hogy az ArchiCAD ezeket a modellezési primitíveket hogyanreprezentálja.

3.1.2.1. Felhasználói oldal

Mivel a felhasználó két és három dimenzióban is modellezhet, sõt, GDL-ben (GeometryDescription Language) is, amely egy BASIC-hez hasonló szkriptnyelv, ezért azArchiCAD-ben a geometriai jellemzõk definiálásának számos módja létezik. Ezeket nemcélunk bemutatni, hisz ezekbõl a háromdimenziós megjelenítésért felelõs modul, a 3DEngine a háromdimenziós épületmodell elkészítésekor úgy is poligonokat hoz létre, aképszintézis alrendszer pedig ezekkel a poligonokkal dolgozik.

3.1.2.2. Reprezentáció

Az ArchiCAD háromdimenziós megjelenítését végzõ modul általános poligonokkaldolgozik, azaz lehetnek konvexek, konkávok, de akár lyukasak is. Mivel számosképszintézis algoritmus csak háromszögekkel dolgozik, vagy azokkal tudja hatékonyanmegoldani a képelõállítást, ezért szükséges a poligonok háromszögekre bontása. AzArchiCAD számos háromszögekre bontó módszert alkalmaz: a füllevágást, a Delanuayháromszögelést ([2]), egy „sweep” algoritmust, amely mûködik rektilineáris alakzatokrais és egy egyszerû módszert. Ez utóbbi módszer annyit tesz, hogy minden csúcspontotmegpróbál összekötni a szomszédjain kívüli összes csúccsal. Ha azonban egy összekötéskeresztezne egy elõzõt vagy a poligon vonalát, akkor azt az összekötést eldobja. Ezzel amódszerrel eléggé elnyúlt háromszögeket is elõ lehet állítani, amelyek pedig a radiozitás(radiosity) ([3]) és más globális illuminációs módszerek számára nem megfelelõek.Megjegyezzük, hogy az OpenGL kiegészítéseként megjelent GLU ([4]) könyvtárban levõháromszögelõ algoritmus is jól használható háromszöghálót (triangle mesh) hoz létre,ezért az ArchiCAD OpenGL add-onjában érdemesnek tartjuk használni.

3.1.3. Elhelyezés a kamera koordináta-rendszerben

Az ArchiCAD a hagyományosnak mondható kamera modellt alkalmazza. Az ablakközéppontját egy nézeti referencia pont definiálja. Az ablak orientációját egy felfelé irányés az ablak síkjának normálvektora definiálja. Az ablak vízszintes és függõleges méreteikülön-külön megadhatók. Perspektív vetítés esetén a szempozíciót, párhuzamos vetítésesetén pedig egy vetítési irányt kell megadni. A tárgytér látható objektumai egy végtelengúlában helyezkednek el. Ezt a teret korlátozhatjuk vágósíkok definiálásával.

3.1.4. Térbeli vágás

Ez a terület igen komoly és bonyolult saját algoritmusokat alkalmaz. Ezekrõl jelenkeretek között nem kívánunk szólni. Az algoritmusok alapja azonban a Sutherland-féletérbeli vágó algoritmus ([2]), amelyet az ArchiCAD számos esetre általánosított.

15

3.1.5. Láthatósági és takarási problémák megoldása

A színtér képsíkra való vetítése néhány objektumot a képernyõ ugyanazon pixelére képezle ha ezek részlegesen, vagy teljesen takarják egymást. A háromdimenziós grafikában akép adott pixelén azon felületi pont színét használják, amely a legközelebb van akamerához.

A láthatósági, takarási problémákat megoldó algoritmusokat 1974-ben Sutherlandosztályozta ([5]). A módszereket aszerint csoportosította, hogy alapvetõen a tárgy- vagy aképtérben dolgoznak, illetve vizsgálta a koherenciák használatát. A koherencia azt jelenti,hogy az algoritmus egyedülálló pontok, pixelek helyett geometriai egységekkel (példáulterületekkel, pászta (scan line), szegmensekkel) dolgozik.

A láthatósági problémák legegyszerûbb megoldását, a triviális hátsólap eldobást(backface culling) ([6]) az ArchiCAD-ben is alkalmazzák. Ez azt jelenti, hogy azokat apoligonokat, amelyek a kamera szempontjából "hátra néznek", eldobjuk, hisz ezek biztos,hogy nem lehetnek legközelebb a kamerához. Ez az algoritmus a tárgytérben dolgozik.Megjegyezzük, hogy a módszert csak zárt testekre alkalmazható. A nyílt testeket azArchiCAD – szerencsére - nem két, egymással ellentétes normálvektorral rendelkezõfelületek kombinációjával kezeli, hanem mindig a nézési iránnyal ellentétesirányitottságú normálvektorral dolgozik.

Egy másik egyszerû módszert, a poligonos takarást is tartalmazza az ArchiCAD, amelyeta 3D Windowsban lehet használni.

A megoldások közül még kiemelnénk a különbözõ térpartíciónáló ([7]) megoldásokat(kd-fa, nyolcasfa, BSP-fa stb.), amelyek közül az ArchiCAD-ben egyet semimplementáltak. Ezekkel részletesebben a "Globális illuminációs számítási módszerekspecifikációja" címû dokumentum foglalkozik.

A takarási problémák megoldására számos további megoldást javasoltak, de agyakorlatban csak két megközelítés maradt fenn: a pásztalapúak (scan line based) és amélységi puffer alapúak (z buffer based). Az ArchiCAD mindkét megközelítéstalkalmazza képszintézis alrendszerében.

3.1.5.1. Pásztalapú megoldás

Az elmúlt évtizedek során számos pásztaalapú algoritmust publikáltak. Ezek mindképtérbeli módszerek, amelyek közül kétségkívül a legelterjedtebb a szakaszos pászta(spanning scanline) algoritmus ([5]). Az ArchiCAD alapértelmezés szerinti képszintézisalgoritmusa, az "ArchiCAD Rendering Engine" is ezt alkalmazza. Történelmi okok miattezt az algoritmust nem rendering add-onként valósították meg.

A módszer sokban hasonlít a kétdimenziós grafikából ismert, poligon kitöltésrealkalmazott aktív éllistás módszerhez ([2]). Az algoritmus lényege az, hogy mindenpásztára megkeresi azon szakaszokat, amelyeket árnyalt színnel kell megjeleníteni.

16

Természetesen a módszer olyan szakaszokat keres, amelyek egy felülethez tartoznak, ígyegyszerre több pixelhez tartozó színt tehet ki a képernyõre. Tehát a módszer az x irányúkoherenciát használja.

A módszer legfõbb elõnye, hogy a koherencia használatával megfelelõen gyors. Viszontaz algoritmus komoly hátránya, hogy az inkrementális árnyalási számításokatmegnehezíti. A másik problémája a komplexitása, amely miatt hardverben nem isvalósították meg. Bizonyított tény, hogy igen nagyszámú poligon esetén, amely azArchiCAD-nél igencsak jellemzõ, a mélységi puffer alapú módszerek hatékonyabbak.

3.1.5.2. Mélységi puffer alapú megoldás

A mélységi puffer módszert 1975-ben Catmull publikálta ([8]). A módszer - a sutherlandiosztályozás szerint - képtérben dolgozó algoritmus, amely nem használ koherenciát. Amélységi puffer algoritmus egy akkora puffert hoz létre, amelynek dimenzióimegegyeznek a készítendõ kép méreteivel. A puffer a képernyõ pixeleihez tartozómélység értékeket tartalmazza.

A poligonokat egyenként dolgozzuk fel: meghatározzuk a képernyõn lévõ vetületüket,majd egy kétdimenziós poligonkitöltõ algoritmussal a hozzájuk tartozó pixeleket. Mindenpixel esetén kiszámítjuk a felületi pont Z koordinátáját és összehasonlítjuk a mélységipufferben lévõ értékkel. Ha a mélységi pufferben lévõ érték nagyobb (azaz az eddigfeldolgozott poligonok ott távolabb vannak, mint az aktuális poligon), akkor az éppenfeldolgozás alatt lévõ elemet kell kirajzolni. A szín puffer megfelelõ pixelét ekkormódosítjuk a poligon adott ponton felvett színével és aktualizáljuk a mélységi puffert azúj Z értékkel. A módszer helyes mûködése érdekében inicializáljuk a mélységi pufferminden értékét végtelenre, amely a gyakorlatban a lehetséges legnagyobb ábrázolhatóértéket jelenti.

Az algoritmus egyik elõnye, hogy független a tárgyak reprezentációjától. Bárlegtöbbször, így az ArchiCAD-ben is poligonháló (polygon mesh) alapú képszintézisnélalkalmazzák, bármilyen reprezentációval együtt használható. Például CSG (ConstructiveSolid Geometry) objektumokra is használható ([9]), amelyeket az ArchiCAD egy késõbbiverziójában remélhetõleg támogatni fog. Ezért is érdemes lenne a mélységi pufferhasználatára nagyobb hangsúlyt fektetni.

Mégis a módszer talán legnagyobb elõnye az egyszerûségében rejlik. Ezért majdnemminden mai gyorsítókártyán és grafikus processzorral rendelkezõ videokártyánimplementálták. A módszer legfõbb hátránya, hogy nem gazdaságos, hisz mindenpixelnél számos poligon pontjának árnyalt színét kiszámítja - fölöslegesen. Ez a problémaaz ArchiCAD-es implementációnál, a rendering add-on-ként létezõ "Z Buffer RenderingEngine"-ben nem létezik, ugyanis az add-on kétmenetes mélységi puffert alkalmaz: azelsõ menetben a látható poligonokat határozza meg, a második menetben pedig csakezekhez számolja ki a színértékeket. Az évtizedek során - fontossága miatt - a módszergyorsítására számos ötletet javasoltak, amelyeket a 3.2.2. és a 3.3.5. alfejezetekbentárgyaljuk.

17

3.1.6. Árnyalás

Az inkrementális képszintézis e lépésekor minden pixelben ismert már, hogy ott melyikfelületi pont látszik. A ponthoz tartozó színérzet meghatározása az ArchiCAD-ben lokálisilluminációs modellel (lásd 1. fejezet) történik.

3.1.6.1. Fényforrások

Az árnyalás szempontjából fontosak a fényforrás megadási lehetõségei. Az ArchiCADszámos fényforrás típust ismer. Pontszerû és szpot fényforrások is megadhatók, de kezelpárhuzamos fényt (például Napot) is. A felületekhez rendelhetõ ugyan emisszió, azArchiCAD nem kezeli ezeket a felületeket területi fényforrásként. A fényforrásoktulajdonságai nem fizikai alapúak (lásd 2.5. alfejezetet), amelyre pedig egyre nagyobbigény mutatkozik nemcsak a képszintézis, hanem például a lámpagyártók oldaláról is. ANap pozíciójának számítása fizikai alapokon nyugszik. Az ArchiCAD-banfényforrásonként (és testenként is) lehet az árnyékvetést szabályozni.

Az ArchiCAD ambiens fénye vagy másnéven derítõfénye biztosítja, hogy egy sötétgyárban is lehet látni valamennyit. Számos képszintézis alrendszerrel rendelkezõ programezt nem biztosítja, így a példaként felhozott sötét gyárban fekete képernyõt kapunk.

Megjegyezzük, hogy az ArchiCAD szpot lámpa fogalma az általánoshoz képest eltér,ugyanis egy hengerszerû térrészben azonos fényenergiát biztosít, és csak a hengertõltávolodva cseng le a fény intenzitása. Ráadásul minden lámpához saját köd definiálható,amelynek célja az volt, hogy azonos erejû fényforrásoknál is lehessen állítani a távolságszerinti lecsengést.

3.1.6.2. Anyagjellemzõk

Az ArchiCAD-ben a testek geometriai tulajdonságait és a testhez kapcsolódó egyébtulajdonságokat külön választották. Utóbbi jellemzõket attribútumoknak hívjuk. Aképszintézis alrendszer szempontjából egyik legfontosabb attribútum, a (direkt)megvilágítás számításakor középpontba kerülõ anyagjellemzõ. A geometriaitulajdonságok és az anyagjellemzõk szétválasztásával elérték azt, hogy nem kell mindenfelülethez külön megadni minden anyagi jellemzõt (például szín, textúra stb.), hanemelegendõ egy globális anyaglista egy elemére hivatkozni. Ez egyrészt kevesebb memóriátigényel, másrészt egy anyagi jellemzõ módosítását nem kell külön-külön mindenszükséges felületen elvégezni. Az ArchiCAD-ben az anyagjellemzõk ma még nem fizikaialapúak (lásd 2.4. alfejezetet). Ez számos hiányosságot fog maga után vonni a globálisilluminációs elvû program input adatainak elõállításánál.

Az ArchiCAD-ben minden anyag rendelkezhet ambiens, diffúz és spekuláris jellemzõvel,amelyek százalékos formában adhatók meg. A diffúz és a spekuláris tényezõk nagyjábóla diffúz és a spekuláris albedonak feleltethetõk meg, de mivel a két tényezõ összege

18

nyugodtan lehet több mint 100 %, az ArchiCAD fizikailag nem plauzibilis. Esetünkben ezazt jelenti, hogy elõfordulhat, hogy a felület a bejövõ energiánál többet ver vissza.

Bár az ArchiCAD támogatja az áttetszõ anyagok használatát, a fénytörés jelenségét nemtudja megjeleníteni. Komoly hiányosságnak tekinthetõ a tükrözõdõ felületek hiánya is.

3.1.6.3. Megvilágítási modell

Az ArchiCAD egy felületi pont színének meghatározásához a következõ lokálisilluminációs modellt alkalmazza: a pont emissziójához hozzáadja a direktmegvilágításból visszavert sugársûrûséget és az ambiens fény bizonyos hányadát.

A lokális illuminációs modellek a visszavert sugársûrûséget úgy számítják ki, hogy abejövõ radianciákat szorozzák a beesési szögek koszinuszaival, valamint a beesési ésvisszaverõdési szögek által meghatározott BRDF (bidirectional reflection distributionfunction) függvényértékekkel, majd ezeket összeadják. Mivel az ArchiCAD kezeli adiffúz és a spekuláris visszaverõdéseket, ezekhez eltérõ BRDF függvényeket kellhasználnia. A diffúz visszaverõdésre konstans BRDF-t alkalmaz, míg a spekulárisra aPhong modellt ([10]). Ez utóbbi BRDF modellrõl ismert tény, hogy nem elégíti ki aHelmholtz-féle szimmetria-törvényt. Ez azt jelenti, hogy ha a bejövõ és a kimenõirányokat felcseréljük, akkor nem ugyanazt a BRDF értéket kapjuk. Ez azért van, mert aPhong modellben szerepel a bejövõ szög koszinusza. Tehát az ArchiCAD a spekulárishatások megjelenítésére fizikailag nem plauzibilis BRDF modellt alkalmaz. Az éveksorán a Phong modell számos módosítását javasolták, amelyek már fizikailagplauzibilissá teszik a BRDF-t. Ezek közül jelenleg a maximum Phong modell ([11]) tûnika legjobbnak. A Phong modell különbözõ módosításaival részletesebben a "Globálisilluminációs számítási módszerek specifikációja" címû dokumentum foglalkozik

Az ArchiCAD az árnyalás során - természetesen - interpolációs megoldást alkalmaz: aPhong-féle színinterpolációt ([12]). Alternatív lehetõség az OpenGL rendering add-onesetében a kevésbé szép, de hardverrel könnyen számítható Gouraud árnyalás..

3.1.6.4. Textúrakezelés

Az anyagi jellemzõk közül kiemeljük a textúrák széleskörû kezelését. A többi CADrendszerhez hasonlóan az ArchiCAD is képes a textúra koordinátákat megadni. AzArchiCAD a textúrák alfa csatornáját számos feladatra tudja használni: az áttetszõség(transparency mapping), az ambiens (ambient mapping), a diffúz (diffuse mapping) és aspekuláris (specular mapping) tényezõk alfa csatornából való állítására. Ezeken kívül azArchiCAD egy klasszikus alfa csatornás módszert, a bucka leképezést (bump mapping) isismer ([6]), amely az alfa csatorna alapján módosítja a felületi normálist. Mivel anormálvektor a megvilágítási modellben fontos szerepet játszik, így a bucka leképezésselazt a hatást kelthetjük, mintha a textúrázott felület göröngyös lenne. A bucka leképezésgyors, de mivel a geometrián nem változtat, így könnyen észrevehetõ a "csalás": a felületkörvonala nem változik meg. Ezt a hatást csak displacement mappinggel ([13]) lehetelérni.

19

3.1.7. Effektek

Az ArchiCAD képszintézis alrendszerét az építészek igényeinek megfelelõen valósítottákmeg. Ez az eddigiekbõl is látható volt, hisz az átlag építész számára az is bõven elegendõ,ha épülettervét nem valószerû, fizikailag nem pontos képekkel is el tudja adni. Viszontszámos felhasználói igényelné a valószerû, fizikailag pontos képek elõállítását is. Ezenfelhasználók igényeit az ArchiCAD különbözõ effektek alkalmazásával próbálja kikielégíteni. Ma az ArchiCAD a lokális illuminációs modell kiegészítéseként az árnyék ésa köd effekteket ismeri.

3.1.7.1. Árnyék

Az ArchiCAD árnyékszámításra a lassú és nagy memóriaigényû, de megfelelõen pontosárnyéktest (shadow body) algoritmust ([5]) használja. Az algoritmus lényege az, hogycsak a fényforrásokból látható poligonok vetnek árnyékot. Tehát minden fényforrásrameghatározzuk a látható poligonokat, majd meghatározzuk a fényforrásokból kiinduló apoligonok körvonalán átmenõ „virtuálisan tömör” testeket, az ún. árnyéktesteket. Példáulegy négyszög esetén így egy csonkagúlát kapunk. Ezeket az árnyéktesteket az ArchiCADbeveszi a többi geometria közé, de a kép elõállításakor csak az árnyékok meghatározásárahasználja õket.

A képszintézis során minden pixelnél megszámoljuk, hogy hány árnyéktestbe léptünk beilletve ki, amíg a legközelebbinek vélt felületi ponthoz érkezünk. Belépéskor eggyelnöveljük a számlálót, kilépéskor pedig eggyel csökkentjük. Ha egy adott pixelhezlegközelebbinek vélt felületi pont esetén a számlálóban pozitív értéket kapunk, akkor azazt jelenti, hogy a pont valamelyik árnyéktest belsejében van. Ilyenkor ez a pontárnyékban van. Ha viszont nullát kapunk, akkor biztos, hogy nincs egyik árnyéktestbelsejében sem, azaz nincs árnyékban.

Az algoritmus nagy színterek esetén igen lassú lehet, amely az ArchiCAD-bentapasztalható is. Másrészt mivel pontosan számolja az árnyékok helyét, ezért CADrendszerekben - alternatívaként - érdemes használni.

A módszerrel nem éles árnyékokat (soft shadows) is lehet készíteni. Azonban azArchiCAD az emittáló poligonokat nem kezeli területi fényforrásként, azaz csakpontszerû fényforrásaink vannak, így a CAD rendszerben nincs lehetõség nem élesárnyékok elõállítására, amelyre pedig nagy igény lenne.

3.1.7.2. Köd

Mivel az ArchiCAD nem rendelkezik sugárkövetés alapú képszintézissel, így a ködhatását empirikus úton próbálja szimulálni. A módszer a következõ: a felületekrõl érkezõsugársûrûséget a köd erõsségének és színének megfelelõen módosítja. Így például egyfehér fal pirosas köd esetén pirosas falként fog megjelenni, de a fal környezetének színenem fog megváltozni. Ez a megoldás nem ad valószerû hatást.

20

3.1.8. Színleképezés

Bár a képszintézis során kiszámoljuk, hogy a monitor pixeleinek megfelelõ térszögbõlmilyen spektrumú fény érkezne a megfigyelõ szemébe, a monitorok megjelenítõképességei az emberi szem dinamikájánál jóval kisebbek. Ezért szükséges a kiszámoltintenzitás értékekbõl a monitor adatainak megfelelõ mennyiségek kiszámítása. Ezt afolyamatot nevezzük színleképezésnek (tone mapping).

Az ArchiCAD egy lehetséges megoldást nyújt a problémára az Image menüben szereplõPhotoRendering Settings menüpont alatt található Brightness fülecskénél. Itt az ún.túlexponálás problémájának megoldása miatt lehet a megjelenítendõ képet sötétíteni,illetve világosítani.

Szerintünk az ArchiCAD azért ennél jóval komolyabb színleképzõ algoritmusokat isalkalmazhatna. Például Ward, Rushmeier módszerei közül lenne érdemes választani,amelyekkel a "Globális illuminációs számítási módszerek specifikációja" címû könyv isfoglalkozik.

3.1.9. Elõzetes képeken alapuló szintézis

Miután a '80-as években elérhetõvé váltak a grafikus munkaállomások, amelyekben amélység puffer hardveresen volt implementálva, a képszintézis kutatások teljes egészébena valószerû, fotorealisztikus képelõállítás irányába tolódtak. A '90-es évek elején tisztánlátszódott, hogy a képszintézis kutatások számos problémát még jópár évig, évtizedignem tudnak megoldani, ezért ezekre egy teljesen új megközelítést kellett kidolgozni.Például mind a mai napig és még hosszú évekig komoly problémát fog jelenteni aszintetizált kép valószerûségét nagyban nõvelõ fák, levelek, felhõk, fû stb. környezetielemek használata, hiszen ezek óriási mennyiségû poligont jelentenek. Ráadásul a maiigényeknek megfelelõ, egyre bonyolultabb színterek igen nagyszámú poligonthasználnak, amelyek csökkentése bár a képelõállítás sebességét növelik, a végeredményvalószerûségét jelentõsen rontják.

Az egyik legígéretesebb irányvonalnak az elõzetes képekre alapuló szintézis (image basedrendering) mutatkozott, amelynek bizonyos területei be is váltották a hozzá fûzöttreményeket. Ezek közül kettõt az ArchiCAD-be is beépítettek.

3.1.9.1. QuickTime VR

A Graphisoft a kutatások kezdeti sikereit látva, az egyik legfontosabb partnerének, azApplenek '94-ben kihozott QuickTime VR eljárását az ArchiCAD-be beépítette. Amódszer lényege, hogy a színterekben panoráma kamerák helyezhetõk el és 360 fokoskörképeket készíthetõk. Ezeket a körképeket elmentve, bármikor újrafelhasználhatóakadott pozíciókon valósidejû körbenézésekre. A módszer fõ hátránya a pozícióhozrögzítettség, amelyet a módszer úgy próbál feloldani, hogy az egyes kamerákösszeköthetõek és ezáltal egyikbõl a másikba át lehet ugrani. További korlátozás, hogy

21

míg az elkészült panoráma teljes horizontális forgást tesz lehetõvé, vertikális iránybankorlátozott. Az ArchiCAD képes RealSpace VRML formátumban is képet elõállítani,amelynek sajátossága, hogy gömbökre is általánosította a QuickTime VR módszert.

Az eljárás minden kötöttsége ellenére óriási sikert aratott az építészek körében. Mivel azArchiCAD volt az elsõ és hosszú ideig egyetlen CAD rendszer, amelyben VR panorámakamerákat lehetett elhelyezni, ez óriási elõnyt jelentett a konkurens CAD rendszerekkelszemben.

3.1.9.2. Fotogrammetriai képességek

Gyakran a modellezett objektumot nem csupán önmagában szeretnénk látni, hanemvalamilyen környezetben. Ez a környezet – háttér – lehet fiktív, amelynek célja a modellszebb környezetben történõ bemutatása, vagy maga a valóság, ahová a modellt beszeretnénk illeszteni. Az utóbbi esetrõl lesz a továbbiakban szó, amikor is az az igény,hogy egy valóságos környezetbe (legyen az egy meglévõ tárgy, vagy valamilyen egyébtáj) tervezzük az új objektumot, és végeredményképp azt szeretnénk látni, hogy hogyanilleszkedik oda.

A számítógépi grafika már 1979-tõl kínál megoldásokat erre a problémára. Ezenmódszerek lényege, hogy egy digitalizált fényképet használnak háttérképként, amelyre azúj épület - számítógép által generált - háromdimenziós modelljét ráképezik. Az éveksorán számos eljárás keletkezett, amely megvalósítja a modell beillesztését a képbe.Minden módszernél a legnagyobb nehézséget a lehetséges megoldások megismerése és alegmegfelelõbb kiválasztása, illetve kialakítása jelenti. Adott módszerrel együtt jön azalkalmazandó algoritmus, amelyhez használható felhasználói felületet kell tervezni. Azalgoritmus végsõ célja a nézõpont, a dõlési- és elfordulási szög, valamint a látószögmegállapítása. Tehát reprodukálni kell a fényképezést úgy, ahogy a háttérnek berakottképet rögzítették. Ezeknek, és még egyéb méret adatoknak a birtokában valósulhat meg ahiteles montázs elkészítése, amelyben megegyeznek az arányok, a szögek stb. Ennek afeladatnak a megoldása a fotogrammetria tudományán alapszik, amely képfeldolgozással,képekrõl való információnyeréssel foglalkozik.

Az ArchiCAD 7.0-ás verziójában már tartalmaz olyan modult, amely képesmontázskészítésre. Az alkalmazott algoritmus érdekessége, hogy csak 4 referencia pontotigényel, amelyekkel a képen szereplõ objektum és a modell megfelelõ pontjait rendeljükegymáshoz. A 3.1. ábrán ezt a funkciót mutatjuk be.

22

3.1. ábra: az eredeti kép (balra) és a kombinált kép (jobbra)

3.1.10. Igények

Ebben a részben tételesen szeretnék bemutatni azokat a képszintézis funkciókat, amelyekjelenleg az ArchiCAD-ben nem léteznek és komoly hiányosságnak érezzük:

• Tükrözõdõ felületek: épületbelsõkben gyakran elõforduló tükrös anyagok nemtükörszerûen viselkednek.

• Láthatósági szûrések (visibility culling): egy szobában csak a szobában és aszobából látható poligonokkal kell foglalkozni, a kamerából induló térszögbenszereplõ összes poligonnal nem kell.

• Nem éles árnyékok: az éles árnyékok valószerûtlen képeket adnak.• Területi fényforrások: fontos lenne az emittáló poligonokat fényforrásokként

kezelni, hisz ez valószerûbb képek elõállításához és a nem éles árnyékokmegjelenéséhez vezetne.

• Fizikai alapú anyagjellemzõk és fényforrás megadások: fizikai alapúképszintézishez, világítástervezéshez stb. szükségesek. A projektben a problémáta nem-fizikai jellemzõk konvertálásával oldjuk meg, de a GDL (GeometryDescription Language) parametrizálási lehetõségeit kihasználva sokkaláltalánosabb megoldáshoz juthatnánk.

• Többszörös visszaverõdések : épületbelsõkre használt valószerû képszintéziselképzelhetetlen többszörös visszaverõdések kezelése nélkül.

3.2. A tudományos élet kapcsolódó eredményei

Az ArchiCAD képszintézis alrendszerének alapjait a ’90-es évek elején rakták le, ígyhasznosnak érezzük azokat a módszereket, elveket áttekinteni, amelyek azóta atudományos világban születtek. Ebben az alfejezetben megpróbáltunk olyan módszerekrekitérni, amelyek nem közvetlenül a globális illuminációs képszintézissel állnakkapcsolatban, hisz az ilyen megoldásokkal a "Globális illuminációs számítási módszerek

23

specifikációja" címû dokumentum részletesen foglalkozik. A sugár és poligonmetszéspontszámító módszereket is abban a dokumentumban tárgyaljuk.

3.2.1. Árnyékvetés

A számítógépi grafikában már a '60-as évek közepén megjelentek az elsõ árnyékvetõmódszerek. Ezek alapvetõen pásztaalapú (scanline) módszerek voltak. A '70-es évekmásodik felében jelentek meg azok a módszerek, amelyeket a legtöbb mai grafikusrendszer használ. Például az ArchiCAD-ben használt árnyéktestek (shadow body)módszer is. Az alábbiakban néhány másik módszert szeretnénk bemutatni, amelyeket -ahogy az a 4. fejezetben is látszik - számos mai grafikus programrendszer alkalmaz.

3.2.1.1. Sugárkövetett árnyékok

Az árnyékvetés azt jelenti, hogy a képernyõn megjelenõ felületi pontokról el kell dönteni,hogy minden fényforrásból láthatóak-e vagy legalább 1 elöl takarva vannak. Alegegyszerûbb és egyben legpontosabb megoldást a sugárkövetés (ray-tracing) adja. Anézõpont minden pixelen keresztül indítunk egy sugarat és meghatározzuk, hogy melyikfelületi pontot metszik el elsõként. Ezekbõl a pontokból minden fényforrás felé indítunk1-1 sugarat. Ezeket hívják árnyéksugaraknak (shadow rays). Természetesen, figyelembekell venni, hogy milyen típusú fényforrással (területi, szpot, pontszerû) kötjük össze apontot. Ha legalább 1 fényforrás esetén a sugár elsõként nem a fényforrást metszi, akkora felületi pont árnyékban van. Ezt a fajta árnyékvetõ módszert a sugárkövetett ányékok(ray-traced shadows) módszerének nevezzük.

A sugárkövetés hatékonyságát növelhetjük, ha az elsõ metszéspontokat nemsugárkövetéssel határozzuk meg, hanem más hardverrel támogatott takarásiproblémamegoldó algoritmussal (például mélységi pufferrel). Errõl a témakörrõlrészletesebben a 3.3.5. pontban írunk.

3.2.1.2. Mélységi puffer alapú árnyékvetés

Valószínûleg a legegyszerûbb árnyékvetõ módszer, amely a mélységi puffert használja([14]). A módszer minden fényforráshoz hozzárendel egy mélységi puffert. Egyelõfeldolgozási lépésben minden fényforrásból nézve kiszámolja a mélységi puffertartalmát, de a színértékeket nem. Ezzel megkapjuk a fényforrásokból nézve legközelebbipoligonok távolságértékeit.

Ezután minden fényforrásnál megjegyezzük azt a transzformációt, amellyel a színtérelemeit a fényforrások "képernyõjére" vetítjük. Ugyanezt a lépést a kamera szemszögébõlis megtesszük. Természetesen, ha a kamera nem mozdul el, akkor utóbbit elegendõegyszer megtenni.

Ezután a képek szintetizálásakor egy pixel (x, y) koordinátájából - a színtér -> képernyõtranszformáció inverzével - meghatározzuk a pixelben látható felületi pont (xw, yw, zw)koordinátáit. Ebbõl a koordinátából a fényforrásokhoz rendelt transzformációval

24

megkaphatjuk azt az (x', y') koordinátát, amelybõl a pont látszódhatna, ha a fényforrásbólszeretnénk a színtérrõl képet készíteni.

Ezután összehasonlítjuk a zw-t az egyes fényforrásokhoz rendelt pufferek (x', y')koordinátájú értékével. Ha a zw nagyobb mint az (x', y') koordinátán levõ z érték, akkorez azt jelenti, hogy a fényforrásból nézve az (xw, yw, zw) felületi pontnál van közelebbi.Ebbõl pedig az következik, hogy a pont árnyékban van. Ha a két z érték egy igen kicsiepszilon sugarú környezetben van, akkor a felületi pont mind a kamerából, mind az éppenvizsgált fényforrásból látható. Ez azt jelenti, hogy nincs árnyékban.

A módszer elõnye, hogy hardveresen gyorsítható, hisz a mai gyorsítókártyák hardveresmélységi pufferrel rendelkeznek. Viszont a hardveres mélységi puffer megvalósításokrögzített pontossággal (például 24 bit) rendelkeznek. Ezen felül figyelembe kell venni,hogy a homogén perspektív projekció miatt fellépõ és két projektált pont között lineárisanbecsült út pontatlan. Ez a perspektív torzítás jelensége. Ezért elõfordulhat, hogy amódszer "téved" és olyan pontokat is az árnyékban levõkhöz rendel, amelyek nincsenekárnyékban, illetve fordítva.

3.2.1.3. Árnyéktérkép

Az elõzõ megoldást könnyen átalakíthatjuk textúrázási feladattá ([15], [16]). Afényforrásoknál létrehozott mélységi pufferek tartalmát tekintsük egy kétdimenzióstextúrának, amelyeket árnyéktérképeknek (shadow maps) nevezzünk.

Ezután a képernyõ minden (x, y) pixelét felírjuk (x, y, z, w) homogén koordinátásalakban. Ezt transzformáljuk - a 4x4-es textúrázási mátrix segítségével - az (s, t, r, q)homogén koordinátás textúra koordinátává.

Ezután össze kell hasonlítani a textúra (s/q, t/q) pozícióján levõ z értéket az r/qtextúrázásból számított mélység értékkel. Ha a textúra (s/q, t/q) pozícióján levõ érték <r/q, akkor a fényforrásból nézve van közelebbi pont, azaz ez a pont árnyékban van. Ha a zérték egy igen kicsi epszilon sugarú környezetben van, akkor a felületi pont mind akamerából, mind az éppen vizsgált fényforrásból látható. Ez azt jelenti, hogy nincsárnyékban.

A módszer legfõbb hátránya, hogy a textúrák rögzített felbontással és színmélységgel(esetünkben mélységértékekkel) dolgoznak. Ezért az árnyéktérképekkel készült képekenaz árnyékok csipkések (aliasing). Ezt a problémát különféle csipkézettség megszüntetõ(antialiasing) és szûréssel (filtering) lehet orvosolni.

Természetesen az árnyéktérképes megoldást is lehet hardveresen gyorsítani, hisz gyorstextúrázó egységekkel minden mai gyorsítókártya rendelkezik.

A módszer CAD rendszerekben is hasznos lehet gyors, "preview" képek készítésekor.

25

3.2.2. A mélységi puffer gyorsítása

A mélységi puffer egy képtérbeli módszer. Ez azt jelenti, hogy nem veszi figyelembe aszíntér struktúrális viszonyait, hisz ezeket csak a tárgytérbeli módszerek használják ki.Viszont a tárgytérbeli megoldások meg a képtér jellegzetességeit, koherenciáit nemveszik figyelembe. Az ideális megoldás a két technika kombinálásával adódik. Az elsõkombinált algoritmust 1993-ban Greene javasolta ([17]).

A tárgytér koherenciájának kihasználására a térfelosztó módszerek (nyolcas-, kd-, BSP-fa) szolgálnak. A színteret egy egyszerû nyolcasfával (octree). szabdaljuk fel. Anyolcasfa egy csomópontja akkor és csak akkor nem látható, ha a benne lévõ összespoligon sem látható. Tehát ha egy csomópontról meg tudjuk állapítani, hogy nem látszik,akkor a benne levõ összes poligont eldobhatjuk a mélységi puffer szempontjából.

Mélység puffereléskor a nyolcasfa gyökerébõl kiindulva csak az egyes csomópontok(kockák) felületi polionjait tekintjük. Ha egy csomópont egyetlen felületi poligonja semlátszik, akkor a mélység puffer számolásakor a benne levõ összes poligont kihagyhatjuk.Ha van olyan poligon, amely látszik, akkor pedig egy szinttel lejjebb megyünk anyolcasfában és ott újra elvégezzük a fenti tesztelést.

3.2.3. Sugárkövetés gyorsítása mélységi pufferrel

A sugárkövetés elsõ lépéseként a szempozícióból minden pixelen keresztül egy sugaratindítunk és keressük az elsõ metszési pontokat. Ehhez minden pixel esetén rengetegsugár-poligon metszéspontszámítást kell végezni.

A sugárkövetés módszere nem használja ki a képtér koherenciáit, így az egyik pixelenbegyûjtött információk elvesznek a következõ pixelnél való sugárindításkor. Azinkrementális képszintézis viszont kihasználja ezeket. A színtér poligonjait sorszámaikkalindexelt, konstans színekkel jelenítjük meg. A kép elkészültekor a szín pufferben azonpoligonok indexei szerepelnek, amelyek az adott pixelen keresztül legközelebb vannak.Ha a takarási problémák kezelésére mélységi puffert használunk, akkor a képszintézisvégén ebben a legközelebbi felületi pontok z koordinátái lesznek. Ha eltesszük a világ ->kép transzformációt, akkor - ennek az inverzével szorozva a pixelek (x, y, z) értékeit -visszaszámolható a legközelebbi felületi pont (xw, yw, zw) koordinátái. Mivel azinkrementális képszintézis lépéseit hardveresen lehet gyorsítani, így ezzel a megoldássala sugárkövetés elsõ metszéspontjainak meghatározását jelentõsen fel tudjuk gyorsítani.

3.3. Hardveresen gyorsított háromdimenziós megjelenítés

Napjainkban az alsókategóriás háromdimenziós gyorsítókártyák és a grafikusprocesszorral rendelkezõ videokártyák olyan technikai szintet értek el, hogy alkalmasakaz ArchiCAD-ben számos, ma még szoftverbõl megoldott feladat elvégzésére. Ráadásul

26

ezek a kártyák ma már szinte minden PC-ben és Macintoshban megtalálhatóak, ígymindenképpen érdemes bemutatni lehetõségeiket.

3.3.1. A mai videókártyák képességei

Ma a piacon kapható videókártyák háromdimenziós gyorsítási képességei nagyjábólmegegyezõk, csak a sebességükben különböznek. Manapság már az összes kártyatámogat legalább két API-t (Application Programing Interface), amelyek közül azOpenGL-t és a Microsoft Direct3D-t kiemelt fontosságú interfészekként kezelik. A kétprogramozási felület meglehetõsen eltérõ, de az alaplogikájuk azonos:

• konvex poligon alapú háromdimenziós szerelõszalag• Gouraud árnyalás• gyors textúrázó egységek• poligononként egyszerre több textúra használható (multitextúrázás)• mélységi puffer (Z buffer)• stencil puffer• homogén koordináták használata• egyszerû bucka leképezés (bump mapping)

Ezeken felül ma már néhány olyan tulajdonság is hozzáférhetõ megfizethetõ áron, amelyegy évvel ezelõtt csak a professzionális munkaállomásokra volt jellemzõ:

• hardveres transzformáció és megvilágítás• per-pixel árnyalás• hardveres vágósíkok• teljes képernyõs csipkézettség megszûntetése (anti-aliasing)

Ezeket a képességeket felhasználva az ArchiCAD számos - képszintézishez kapcsolódó -funkcióját hardveresen gyorsítani lehetne. A következõ alfejezetekben néhányalkalmazási területet szeretnénk bemutatni. Azt is szeretnénk hangsúlyozni, hogy ahardverek hihetetlen tempójú fejlõdése miatt bár az ArchiCAD számos funkciója ma méghardveresen nem gyorsítható, de 1-2 éven belül várható. Ilyen lehetõségként említenénkmeg a displacement mapping ([13]) hardveres gyorsítását, amelynek elsõ prototípusánjelenleg is dolgoznak a Matrox fejlesztõi.

3.3.2. A statikus megvilágítási modell gyorsítása

A hardveres képszintézis legtöbb megoldása a gyors textúrázó egységeket használja fel.Az egyik ilyen módszer a fénytérképek (lightmap) használata, amelyeket bármelypoligonhoz hozzárendelhetünk. A fénytérkép egy elõre kiszámított textúra, amely azadott poligon megvilágítási tulajdonságait tartalmazza. A poligonok szintetizálásakor -kihasználva a multitextúrázást - egy lépésben megjeleníthetõk az anyagjellemzõk közöttdefiniált textúrák és a fénytérképek. A textúrák ilyenkor egymás erõsíthetik ésgyengíthetik is, hisz multitextúrázással lehetõség van a textúrák tetszõleges súlyozássaltörténõ kombinációjára. Utóbbiak számítási ideje és élethûsége függ az alkalmazott

27

algoritmustól, a fénytérképek felbontásától. Ezek a paraméterek könnyen személyreszabhatóak, viszont a képszintézis mindig optimális ideig tart. Ezek alapján hasznosnaktartjuk ArchiCAD-ben való implementálásukat.

3.3.3. A dinamikus megvilágítási modell gyorsítása

Árnyékvetés gyorsítására szolgál a stencil puffer (stencil buffer), amely 256 különbözõárnyalatot tud tárolni. Ezzel megoldható, hogy az olyan felületrészeken, amelyekre többtárgy is vet árnyékot, sötétebb árnyalatot kapjunk. A stencil puffer egy lehetségesalkalmazása lehet a plafonnál levõ ventillátorlapátok árnyékának padlón valómegjelenítése.

3.3.4. Hardveres transzformáció és megvilágítás

Az újabb videokátyák képesek a háromdimenziós szerelõszalag (rendering pipeline)feladatainak nagy részét átvállalni. A mai videokártyák képkockánként a háromtranszformációs mátrix (az objektum, a nézeti és a projekciós mátrixok) és a színtérpoligonjai alapján képesek a képszintézis végrehajtására. Az objektum mátrix a világkoordináta-rendszerben való elhelyezést szolgálja. A videokártyák a nézeti mátrixbólelkészítik a hat vágósíkot (közelsík, távolsík, jobb, bal, fent és lent), majd végrehajtják anézet ablakra vonatkozó térbeli vágást.

Számos videokártya ismeri az ún. per-pixel árnyalás (per-pixel shading) módszerét. Ezazt jelenti, hogy minden poligonhoz hozzárendelhetõ egy speciális textúra, amely - afénytérképhez hasonlóan - elõre kiszámított értékeket tartalmaz. Ezek az értékek azonbannem színértékeket jelölnek, hanem normálvektorokat. A képszintéziskor azok a felületek,amelyekhez ilyen textúrák vannak rendelve, a használt fényforrások jellemzõinekmegfelelõen lesznek megvilágítva. Különösen jól használhatóak érdes felületekemulálására, de a módszert tekinthetjük a Phong interpoláció hardveres támogatásának is.

3.3.5. Mélységi puffer gyorsítási módszerek

Ebben az alfejezetben szeretnénk - az ArchiCAD-nél is központi fogalomként jelentkezõ- mélységi puffer hardveres megoldásairól bõvebben szólni. Felhasználói szempontbólmaguk a megoldások talán nem annyira érdekesek, de mégis hasznosnak érezzük õket ittleírni, hisz a mélységi puffer hardveres implementációinak felhasználásakor jó ha tudjuk,hogy melyik kártya milyen módszerrel próbálja gyorsítani az eredetileg "kissé" pazarlómódszert.

A háromdimenziós szerelõszalag megvalósításokban a grafikus motorok a jelenetGouraud-árnyalt kiszámítása után sorra veszik minden egyes háromszög minden egyespontját, majd a megfelelõ textúrákban hozzájuk rendelt színekkel színezik ki õket. Ha amotor végzett a szín kiszámításával, a pont Z-, azaz mélységi koordinátája alapján Ztesztet végez, amelynek segítségével megállapítható, hogy az elkészült képen akiszámított pixel látható lesz-e, vagy egy másik pont eltakarja. Ha a frissen kiszínezettpont látható, akkor bekerül a szín pufferbe. Ha a pont takarásban van, a motor egyszerûen

28

eldobja és veszi az aktuális háromszög következõ pontját, amelyre újra elvégzi abekezdésben leírt mûveletsort.

Ez a megoldás rengeteg fölösleges számítást végez, így a videochip által elvégzett munkakárba vész. Ráadásul, minden pixelhez be kell tölteni a chipbe a megfelelõtextúraadatokat, amelyekrõl késõbb, a Z-tesztnél kiderül, hogy fölöslegesek voltak.Például a közismert Quake 3 Arena címû játékban három-négyszeres "overdraw" lép fel,amely azt jelenti, hogy a szükséges színértékek helyett 3-4x annyit számolunk ki. Ezpedig azt jelenti, hogy a szükséges adatmozgás többszöröse zajlik a videochip és agrafikus memória között. A felbontás növelésével - természetesen - az elvégzendõ munkaés az adatmennyiség is nõ, fõleg akkor ha bi- vagy trilineáris szûrést is alkalmazunk.Mindezekbõl látható, hogy a hagyományos megoldás elég pazarlóan bánik amemóriasávszélességel.

3.3.5.1. Az ATI HyperZ módszere

Az ATI által a Radeon chipben bemutatott HyperZ eljárás számos apró trükkel próbáljavítani ezen. Az ATI Radeon videochip tartalmaz némi memóriát, amely egyfajta belsõmélységi pufferként funkcionál. Ennek a memóriaterületnek az elérése természetesennagyságrendekkel nagyobb, mint a külsõ memóriáé, amely a kártyán található.

Az elsõ és talán legfontosabb megoldás a HyperZ esetében a mélységi puffer tömörítése.Erre egy változó hatékonyságú, veszteség nélküli eljárást alkalmaznak. A mélységipuffert 8- és 64-pixeles blokkokra bontják, amelyeket az eredeti méretük felére vagy akárnegyedére is össze lehet tömöríteni. Ha szükség van valamelyik blokk tartalmára, akkor akitömörítés a chipben található belsõ mélységi pufferbe történik. A mélységi puffermûveletekhez szükséges sávszélesség csökkentésén kívül ez az eljárás a pufferhelyigényét is csökkenti. Tehát a grafikus memóriában, ahol a külsõ, tömörített mélységipuffer található, sokkal több textúra férhet el.

A másik trükk a "gyors mélységi puffer törlés" (fast z-buffer clear) nevet kapta. Mindenegyes teljes kép elkészítése után, de még a következõ kép elkészítése elõtt, szükség van amélységi puffer törlésére, amelyet eddig úgy oldottak meg, hogy egyszerûen feltöltötték amaximális értékekkel. Fentebb már szóltunk arról, hogy a mélységi puffer blokkokból áll.A chip nem írja felül nullákkal a mélységi puffer minden elemét, hanem a blokkokategymás után töröltté nyilvánítja és egy címkét ad nekik. Amikor a kitömörítésnél ez atörlésre utaló címke megjelenik, a chip a belsõ mélységi puffert felölti maximálisértékekkel. Tehát a "gyors mélységi puffer törlés" egyrészt sokkal gyorsabban megyvégbe, mint a hagyományos törlés, másrészt, takarékosan bánik a sokat emlegetettmemóriasávszélességgel is.

3.3.5.2. A tile-based deferred rendering

A KYRO cég PowerVR videochipje a tile-based deferred rendering eljáráson alapul. Akép kiszámításának menete a Gouraud-árnyalásig ugyanúgy zajlik, mint azt ahagyományos eljárás során ismertettük. Ám ezután a chip a képet apró pixelblokkokra,

29

azaz mozaikokra (tile) osztja fel, és meghatározza, hogy mely háromszögek vannak azadott mozaikban részben vagy egészben. Majd ezeket a háromszögeket mélység szerintegymás mögé állítja (depth sorting). Ha ezzel végzett, végigfut a mozaik pontjain ésmegvizsgálja, hogy mely képpont melyik háromszöghöz tartozik, és az adott képpontot aháromszöghöz rendelt textúra színével kiszínezi.

A módszernek két elõnye van. Az egyik, hogy teljesen kiküszöböli az overdrawjelenséget, azaz nincsenek feleslegesen kiszámított, majd eldobott pixelek. A másikelõnye, hogy ha a mozaikot akkorára választjuk, hogy a mélységi puffer elférjen avideochipbe épített aprócska gyorsítómemóriában (cache), nem szükséges a chip és agrafikus memória közötti lassú adatbuszt olyan gyakran igénybe venni. Ez továbbcsökkenti a szükséges memóriasávszélességet. A módszer hátrányai közül kiemelnénk,hogy a mélységi rendezés nagy bonyolultságú chipet kíván, sok alkatrésszel, amely amagméretnél és az elérhetõ legnagyobb órajelnél visszaüt. Szintén komoly probléma,hogy a poligonszám növelésével a mélységi rendezés nagyon sok idõt vesz igénybe.

30

31

4. További grafikus rendszerek bemutatása

A projekt célja egy, CAD rendszerekben alkalmazható, globális illuminációs elvûprogram készítése. Minden kutatási+fejlesztési feladat a jelenleg mûködõ rendszerekáttekintésével, jellemzõik rendszerezésével kezdõdik, hisz a leszûrt tapasztalatokmegfelelõ kiinduló alapot nyújthatnak Ebben a fejezetben olyan grafikus rendszerekettekintünk át, amelyek globális illuminációs elvû képszintézissel rendelkeznek.

A fejezetet a grafikus rendszer és a globális illuminációs elvû program közöttikommunikáció fõ fajtái alapján két részre osztottuk. Az elsõ felében integrált, modellezõalrendszerrel rendelkezõ programcsomagokat mutatjuk be, amelyek az onlinekommunikáció megvalósításához adhatnak ötleteket. A második részben pedig azokat aprogramokat tekintjük át, amelyek "csak" képszintézis feladat megoldására alkalmasak.Ezek a rendszerek alapvetõen offline kapcsolatban állnak más grafikus rendszerekkel.

Minden programnál megvizsgáljuk, hogy az milyen anyag és fényforrás megadásilehetõségeket biztosít, különös tekintettel a fizikai alapúakra. Az így összegyûjtöttinformációk hasznosak lehetnek az ArchiCAD anyag- és fényforrásjellemzõinekátalakításában.

4.1. Integrált, modellezõ alrendszerrel rendelkezõ programok

A grafikus rendszerek piacán rengeteg integrált megoldással találkozunk, amelyekegyetlen programban biztosítanak modellezési, képszintézis és igen gyakran animációslehetõségeket. Ezek közül azokat a programokat választottuk ki, amelyek eléggéelterjedtek, a felhasználóiknak minél általánosabb megoldást próbálnak nyújtani, de azértaz igazi erejüket saját "szakterületükön" mutatják.

A fenti szempontok alapján két, kifejezetten animációs célokra készült csomagot (3DStudio MAX, Maya), egy ipari formatervezõ programot (trueSpace) és két CADrendszert (AutoCAD, Architech.PC) vizsgáltunk meg. Ezek közül alapesetben csak atrueSpace rendelkezik globális illuminációs elvû képszintézissel, de már a többihez is -nyitott architektúrájuknak köszönhetõen - fejlesztettek ilyen programokat. Azalábbiakban ezekre a megoldásokra is kitérünk.

A programok bemutatásánál külön megvizsgáljuk az alkalmazások és a globálisilluminációs alrendszerük közötti online kommunikációs megoldásukat, de részletesenkitérünk a programok funkcionalitására is.

Bár ebben az alfejezetben csak integrált megoldásokkal foglalkozunk, ahol offlinekommunikációra nincs szükség, hasznosnak tartjuk összegyûjteni a programok általkezelt fájl formátumokat. Ez hasznos alap lehet az ArchiCAD fejlesztése, illetve a projektsorán készülõ program számára is. Természetesen, csak a képszintézis szempontjábólérdekes formátumokat írjuk le.

32

4.1.1. 3D Studio MAX

A professzionális háromdimenziós modellezõ, animációs és képszintetizáló programokközül a 3D Studio MAX-ból ([22]) adják el a legtöbbet. A MAX felhasználóinakegységes, objektum-orientált platformot biztosít, amellyel vizuális effekteket, karakteranimációt és következõ generációs játékokat készíthetnek. A programot 1996-banmutatták be. Azóta 65 különbözõ díjat nyert és több mint 140.000 felhasználóvalrendelkezik.

4.1.1.1. Anyag- és fényforrásjellemzõk

A 3D Studio MAX nem fizikai alapú anyag- és fényforrásjellemzõket használ. A 4.1.ábrán balra egy Phong-szerû anyag jellemzõit láthatjuk. Felhívnánk a figyelmet amultitextúrázási lehetõségre. Ez azt jelenti, hogy egy anyaghoz több textúrát ishozzárendelhetünk. Az anyaghoz rendelt textúrák típusai a Maps szekcióban láthatók.

A 4.1. ábrán jobbra egy szpot lámpa tulajdonságait láthatjuk. Itt azt szeretnénk kiemelni,hogy minden fényforrásnál külön állítható az, hogy vessen-e ányékot vagy sem. Ezt azObject Shadows szekcióban állíthatjuk be az On checkbox kipipálásával. Ez alatt pedigaz is meghatározható, hogy milyen módszerrel számolja ki az árnyékot. A 3D StudioMAX két árnyékvetõ módszert ajánl: az árnyéktérképek (shadow maps) és asugárkövetett árnyékok (raytraced shadows) használatát.

Megjegyezzük, hogy a 3D Studio MAX nyitott architektúrájú alkalmazás, ezért lehethozzá fizikai alapú anyagokat és fényforrásokat is fejleszteni.

4.1.1.2. Kezelt fájl formátumok

A 3D Studio MAX számos fájl formátumot kezel, de továbbiakat is képes az ún. I/Oplugin-ok megvalósításával. A 3D Studio alapesetben a következõ formátumokat képesbeolvasni, azaz importálni:

• MAX: ez a 3D Studio MAX saját formátuma, amelynek a pontos felépítése nempublikus.

• 3DS: ez a DOS-os 3D Studio fájl formátuma, amelynek a felépítése publikus.Számos program, amely azt állítja magáról, hogy képes a 3D Studio MAX fájljaitkezelni, valójában ezt a formátumot kezeli.

• DXF / DWG: az AutoCAD által bevezetett formátumok, amelyek mára a CADrendszerek körében ipari szabvánnyá váltak. A DWG nem publikus. Mindkettõtartalmazhat ACIS szolid geometriai adatokat, amelyeket számos CAD rendszernem képes kezelni.

• IGES: az Initial Graphics Exchange Specification egy ANSI szabvány, amelyetCAD, CAM és számítógépes vizualizációs rendszerek közötti információcserérefejlesztettek ki.

33

• VRML: a Virtual Reality Markup Language a HTML-hez hasonló leírónyelv,amelyet böngészõbõl nézhetõ színterek leírására találtak ki. Mára ipariszabvánnyá vált. További részletek a 6. fejezetben olvashatók.

4.1. ábra: a 3D Studio MAX anyag- és fényforrásjellemzõit mutató dialógus ablakai

34

A 3D Studio MAX alapcsomagjában az alábbi formátumokat képes kiírni, azazexportálni (rövid leírást csak azoknál adunk, amelyek eddig nem szerepeltek):

• ASE: a 3D Studio MAX szöveges formátuma. Igazándiból csak olvasási,nézegetési célokra érdemes használni, mivel jelenleg igen kevés program tudjakezelni.

• MAX• 3DS• DXF / DWG• VRML

4.1.1.3. Plugin renderer interfész

A 3D Studio MAX nyitott architektúrájú alkalmazás, amely azt jelenti, hogy a programmagja fölé különbözõ célú, feladatú programokat lehet fejleszteni, amelyek a MAX-baintegrálva futtathatóak. Ezek a programok az ún. plugin-ok. A 3D Studio MAX egyáltalános célú modellezõ, animációs és képszintézis program, ezért a különbözõfeladatterületekhez eltérõ típusú plugin-okat alkalmaz, amelyek C++ nyelven készülnek.A 3D Studio MAX-ban plugin renderer írásával lehet globális illuminációs elvûképszintézist megvalósítani, amely a képszintézis alrendszerbe épül be.

Egy plugin renderer írásához az SDK-ban (Software Development Kit) szereplõ Rendererinterfész osztályt kell megvalósítani. A gyerekosztályban szereplõ virtuális metódusokata 3D Studio MAX hívja: a metódusokon keresztül inicializáltatja a plugint, felrakatja aplugin saját paramétereit tartalmazó dialógus ablakot, képet készíttet, végül befejezteti amunkát.

A plugin renderer saját adatstruktúrákkal dolgozik, amelyek nem jelennek meg a 3DStudio MAX globális adatszerkezetei között. Ez a megoldás óriási mennyiségû adatduplikálásához vezethet. Például a színtér teljes geometriája mind a 3D Studio MAXglobális adatszerkezeteiben, mind a plugin saját adatszerkezeteiben is meglesz. Ahogylátni fogjuk, az ArchiCAD is ezt a megoldást ajánlja. A módszer a lehetségesmemóriagondok és a duplikátumok ellenére külsõ fejlesztõk számára hasznosabb, mint arendszerbe való teljes integráció, hisz az újabb MAX verziók megjelenésekor csak aplugin renderer interfész ért minimális módosításokat kell a pluginban végigvezetni, így aplugin komolyabb újraírás / újragondolás nélkül ugyanúgy fog mûködni.

4.1.1.4. mental ray

A 3D Studio MAX készítõje, a Discreet a német Mental Images céggel közösen a MAX-ba integrálta - plugin rendererként - az egyik legismertebb professzionális képszintézisprogramot, a mental ray-t ([23]).

A mental ray képes a fény viselkedésének fizikailag korrekt szimulációjára. A mental rayglobális illuminációs algoritmusa az elõre- és a hátrahaladó sugárkövetõ módszereket

35

kombinálja azért, hogy az összes lehetséges fényutat megkapja. Ezért nemcsak diffúzvisszaverõdéseket tud kezelni, hanem fényes illetve spekuláris felületeket is. Ráadásul,képes megjeleníteni olyan fényfoltokat, amelyek fénytörés illetve visszaverõdéshatásaként jönnek létre. Például lencsék, üvegek képesek összegyûjteni a fényt és egydiffúz felületen apró, igen fényes foltként megjeleníteni. Az ilyen foltokat idegen szóvalkausztikus hatásoknak hívjuk.

4.2. ábra: mental rayjel megjelenített Cornell doboz

A mental ray globális illuminációs algoritmusai Monte Carlo mintavételezésen alapulómódszereket alkalmaznak. Azonban a mental ray módszerei mégiscsakdeterminisztikusak, ugyanis ezzel azt akarták elérni, hogy ha adott kameraállásból egyszínteret többször is "lefényképezzünk", akkor mindig ugyanazt az eredményt kapjuk,ami általában nem igaz a valószínûségekkel dolgozó módszereknél. Illetve azalgoritmusok determinisztikusságával megoldották, hogy az animációk során nincs"pattogás", "ugrálás", amely a randomizált módszerekkel készült animációknálelõfordulhat.

Azonban a mental ray nemcsak sugárkövetést használ képszintézisre, hanem egy gyorspásztaalapú módszert is. A program automatikusan választja ki, hogy mikor kellsugárkövetést alkalmaznia a fénytörések, árnyékok stb. számolására. A mental ray egyikfontos tulajdonsága a területi fényforrások nagypontosságú kezelése, amely nagyon szép,igen valószerû nem éles árnyékokat (soft shadows) eredményez.

36

4.3. ábra: mental rayjel megjelenített versenyautó

A mental ray képes hálózatos képszintézisre, azaz képes a képelõállítás folyamán ahálózatban elosztott erõforrásokat (processzorok, memória stb.) felhasználni. Sõt, egymental ray a hálózatban nemcsak 3D Studio MAX alatt futó társaihoz tud kapcsolódni,hanem a számos platformon (Windows, Linux, SGI IRIX, AIX, DEC UNIX, HP-UX,Sun Solaris) elérhetõ, önálló mental ray alkalmazásokhoz is. Ezzel egyedülálló módontöbb platformon elosztott képszintézisre is képes.

A mental ray fejlesztõi arra törekedtek, hogy a felhasználónak a képszintézishez nekelljen túl sok paramétert beállítania. A mental ray a paraméterek (például a poligonhálófelbontás (mesh resolution) stb.) állítását nem is a képszintézis feladatköréhez sorolja,hanem modellezési feladatnak tekinti. Ezzel a felhasználói felületi elemeket jelentõsenlecsökkentették.

4.1.2. Maya

Az Alias|Wavefront a világ egyik vezetõ szoftvergyártója. Két- és háromdimenzióstechnológiáival élenjáró szereplõje a film-, a videó- és a játékkészítõ, az interaktív média,valamint az ipari formatervezõ piacoknak. Az Alias|Wavefront filmes és videósfelhasználói többek között az ABC, CBS, CNN, Digital Domain, Dream Quest Images,Dream Pictures Studios, DreamWorks SKG, Industrial Light & Magic, Pixar.

Az Alias|Wavefront talán legfontosabb terméke, a Maya ([24]), amely egy karakteranimációs és vizuális effekteket készítõ programcsomag - kifejezetten professzionálisanimátorok részére. A Graphisoft szempontjából fontos megemlítenünk, hogy a Mayaegyike azon kevés programnak, amelyek elérhetõek Macintosh platformra is. A Mayaalapfilozófiáját egy procedúrális architektúrára, a függési gráfra (dependency graph)építi. Ehhez hasonló megoldással egyelõre csak a Houdini nevû animációs csomagrendelkezik. A Mayában minden fogalmat (színtér, mûveletek stb.) egy csomópont (node)képvisel, amelyek között összeköttetéseket, szabályokat állíthatunk fel. Például egypoligon alapú gömb paramétereit (sugár, tesszellációs szint stb.) a paraméterek

37

csomópont tartalmazza, a gömb tényleges megjelenését pedig egy alakzat csomópont. Akét csomópont úgy van összekötve, hogy az alakzat inputja a paraméterek. Tehát, ha afelhasználó a paraméterek csomópontban valamit változtat, akkor az hatással van azalakzat csomópontra is. Ezzel a megközelítéssel igen bonyolult feladatok is egyszerûenmegoldhatóak.

Az Alias|Wavefront egy sor újítással még könnyebbé és sokkal érthetõbbé teszi a Mayakezelõi felületét. Ez különösen az új felhasználók számára teszi még szimpatikusabbá aMayát, jelentõsen felgyorsítva az általános áttekinthetõséget.

A Maya számos egyedi funkciója közül kiemelnénk a IPR (Interactive PhotorealisticRendering) technológiát, amellyel a megjeleníteni kívánt kép egy részét kijelölhetjük ésinteraktívan módosíthatjuk. Ezzel a módszer például egy szpot lámpa pontoselhelyezését, végsõ képen jelentkezõ hatását valós idõben állíthatjuk be. A 4.4. ábrán egyûrhajón dolgozunk és a fényviszonyok pontos beállítására az IPR-t használjuk. A zöldtéglalap jelzi azt a területet, amelyet a Maya folyamatosan újrarajzol.

4.4. ábra: az IPR technológia használatával interaktív megjelenítés érhetõ el

4.1.2.1. Anyag- és fényforrásjellemzõk

A Maya csomópont alapú filozófiája az anyag- és fényforrásjellemzõk megadásánál isérvényesül. A jellemzõket a HyperShade-nek nevezett eszközzel lehet megnézni,módosítani. A 4.5. ábrán látható, hogy egy Phongszerû anyagot hoztunk létre, amelyhezegy Pine nevû textúrát rendeltünk hozzá. Az ábráról a két csomópont közötti kapcsolat isleolvasható.

38

4.5. ábra: a HyperShade-ben anyaghoz (phong1) hozzárendelt textúra (Pine)egyszerûsített megjelenítése a kapcsolat kijelzésével

A 4.6. ábrán pedig a két csomóponthoz kapcsolódó összes csomópontot láthatjuk, amelymutatja, hogy egyszerû feladat esetén is milyen "bonyolult" gráf épülhet fel. Az ábránlátható, hogy a Pine textúrához tartozik egy elhelyezési csomópont (place2dTexture1), aphong1 anyaghoz pedig egy árnyalási csoport csomópont (phong1SG). Az ábrán jólmegfigyelhetõ, hogy a textúra és az elhelyezését szabályozó csomópont között számoskapcsolat (például U és V irányok szerint skálázis faktorok, eltolási tényezõk stb.) állfenn.

4.6. ábra: a HyperShade-ben anyaghoz (phong1) hozzárendelt textúra (Pine) összeskapcsolódó csomóponttal való együttes megjelenítése. A place2dTexture1 a textúra

ráfeszítését szabályozza, a phong1SG pedig azt az árnyalási csoportot (shading group)jelzi, amelyhez az anyag tartozik.

Természetesen a Mayában nemcsak a kapcsolatokat lehet szabályozni, hanem a ténylegesparamétereket is lehet állítani. Ezeket a fenti ikonokra bökve érhetjük el. A 4.7. ábrán aPhong anyag tulajdonságait láthatjuk, amelyen látszik, hogy a Maya Phong shadere semfizikai alapú anyagjellemzõket tartalmaz.

39

A 4.8. ábrán egy szpot lámpa tulajdonságait mutatjuk be. Az ábráról leolvasható, hogy aMaya alapcsomagjában sincsenek fizikai alapú fényforrások. Itt is megjegyezzük, hogyminden fényforrásnál külön-külön lehet állítani, hogy vessen-e árnyékot vagy sem, illetveaz árnyékvetõ algoritmust is megmondhatjuk. A Maya a fényforrásoknál azárnyéktérképeket (shadow map) és a sugárkövetett árnyékokat (ray-traced shadows)képes kezelni.

A Maya - a 3D Studio MAX-hoz hasonlóan - nyitott architektúrájú program, így lehethozzá fizikai alapú anyagokat és fényforrásokat is fejleszteni.

4.7. ábra: Phongszerû anyagjellemzõk a Mayában

40

4.8. ábra: egy szpot lámpa jellemzõi a Mayában

4.1.2.2. Kezelt fájl formátumok

A Maya - nyitott architektúrájának köszönhetõen – számos formátumot képes kezelni. Azalapcsomag azonban csak a következõ formátumokat tudja beolvasni, azaz importálni:

• MA / MB: a Maya saját szöveges és bináris formátuma.• DXF: az AutoCAD által bevezetett formátum, amely mára a CAD rendszerek

körében ipari szabvánnyá vált.• OBJ: az Alias|WaveFront általános 2D / 3D formátuma.• IGES: az Initial Graphics Exchange Specification egy ANSI szabvány, amelyet

CAD, CAM és számítógépes vizualizációs rendszerek közötti információcserérefejlesztettek ki.

• RIB: a RenderMan Interface Bytestream a RenderMan által bevezetett formátum.

Viszont az alapcsomag csak a saját formátumait (MA / MB) képes kiírni, azaz exportálni.

41

4.1.2.3. Rendering plugin

A Maya - a 3D Studio MAX-hoz hasonlóan - nyitott architektúrájú program. A Mayábanis minden funkcióterületet más és más típusú plugin fed le, amelyek C++ nyelvenkészülnek. A projekt szempontjából a rendering plugin-okat érdemes részletesebbenmegvizsgálni.

A Maya csomópont alapú filozófiája a plugin-oknál is érvényesül. A Mayában a pluginokadatszerkezetei beépülhetnek a függési gráfba, de a konzol parancsok közé is. Ezzel azadatduplikálás lehetõségét minimálisra csökkentették, de megnehezítették a külsõfejlesztõk munkáját. A csomópontok között komplex kapcsolatok lehetnek, amelyekbõlbonyolult rendszerek építhetõk. Már egy egyszerûbb plugin számára is számoscsomópontot kell implementálni, ezért nehéz elõre felkészülni, illetve tesztelni acsomópontok felhasználásakor felmerülõ problémákat.

A rendering plugin-ok mûködését visszahívó (callback) függvényeken keresztül lehetszabályozni. Ehhez meg kell valósítani egy MRenderCallback osztályból származtatottgyermekosztályt. A Maya a visszahívó függvényeket a következõ esetekben hívja meg: aképszintézis kezdetén, az árnyékvetés számításánál és az utómunkák során. Amegvalósított gyermekosztályhoz egy csomópontot kell hozzárendelni, amelyhez afüggési gráfban a képszintézis algoritmushoz szükséges anyag, fényforrás, geometria stb.csomópontokat kell hozzá kötni.

Talán az eddigiekbõl is kitûnt, hogy nem egyszerû feladat a Mayában általánosanalkalmazható képszintézis algoritmust megvalósítani. Ezért a Mayához jóval kevesebbképszintézis plugin létezik, mint például a 3D Studio MAX-hoz. Ez a szám kifejezetten aglobális illuminációs elvû algoritmusoknál minimális. Ezek közül mi a LightflowRendering Tools nevû plugint választottuk.

4.1.2.4. Lightflow Rendering Tools

A Lightflow Rendering Toolst - a mental ray-hez hasonlóan - önálló alkalmazásnakfejlesztették ([25]), amelyet utólag integráltak a Mayával. A programot Jacopo Pantaleoniközel 5 évig fejlesztette, amelyet az ELF (Embedded LightFlow) projekt keretébenintegrált a Mayával. Ez azt jelentette, hogy a Lightflow Rendering Toolst a Mayábanrendering pluginként implementálta. Tervek között szerepel a 3D Studio MAX-szal valóintegráció is.

A program egyik alapötlete az volt, hogy olyan szoftvert hozzanak létre, amely azújonnan megjelenõ hardver technológiák támogatására is lehetõséget ad. Mindezt úgy ériel, hogy konzisztens interfészt és a legjobb sebesség / minõség arányt biztosítja. Ez akoncepció olyan hatásosnak bizonyult, hogy mára rengeteg egyedülálló vagy csak igendrága programcsomagokban létezõ funkciót is meg tudtak valósítani.

42

4.9. ábra: Lightflowval megjelenített Cornell doboz

A Lightflow Rendering Tools egy hatékony proxy megoldásnak köszönhetõen képesautomatikusan kezelni az elosztott képszintézist. Támogatja mind a párhuzamos, mind atöbbszálú rendszereket, így a képszintézis és az animáció készítés folyamatát jelentõsenfelgyorsítja.

4.10. ábra: Lightflowval megjelenített szobabelsõ

43

A globális illuminációs elvû képszintézise egy kombinált algoritmusra épül, amely azelosztott sugárkövetés (distributed ray-tracing), a radiozitás (radiosity), egy causticsmegjelenítõ és volumetric rendering módszerek elõnyeit ötvözi. A hibrid módszer igenvalószerû képeket eredményez, amelyeket különbözõ textúrázási megoldásokkal (sub-pixel displacement mapping, environment mapping, hipertextúrák) és effektekkel(mélységhatás (depth of field), fénycsillanás) még tovább javít.

4.1.3. Desktop Radiance

Greg Ward Larson a Lawrence Berkeley National Laboratory alkalmazásában 1985 és1997 között fejlesztette ki a Radiance nevû világítástervezõ és képszintézisprogramcsomagot. A Radiance hosszú ideig csak Unixokon mûködött, majd azADELINE projekt keretében Microsoft DOS-ra is implementálták. Az utóbbi években aMicrosoft Windows operációs rendszereinek nagyfokú elterjedtsége miatt jelentõs igénymutatkozott a Radiance csomag Windows alatti elérhetõségére. Ezt az igényt próbáljameg kielégíteni a Desktop Radiance, amely a Windows alatt futó AutoCAD rendszerrelintegrálta a Radiance programcsomagot.

4.1.3.1. Radiance

A Radiance ([27]) célja az volt, hogy a világítástervezõknek és az építészeknek olyaneszközt adjon a kezébe, amely egy térrész megvilágítási szintjeit, megjelenését még amegépítése elõtt bemutatja. Az alapcsomag számos konvertáló programot tartalmaz,amely különbözõ modellezõ programokban készített színtereket alakítanak a RadianceRAD fájl formátumára. Ezek közül a legfontosabbak az MGF (mgf2rad) és a WaveFrontOBJ (obj2rad) formátumokról konvertáló programok. A csomag legfontosabb eleme aszimulációt végzõ alrendszer, amelynek eredményképeit a csomagban szereplõ analizálóés manipuláló szoftverrel lehet felhasználni.

A megvilágítás szimulációja hibrid (Monte Carlo és determinisztikus megközelítésû)sugárkövetéssel (ray-tracing) történik, amellyel kivárható idõ alatt pontos eredményképekkapható. A sugárkövetés nyolcasfát alkalmaz térpartíciónáló algoritmusként. A számításhárom fõ részre osztható: a direkt megvilágításra, valamint a diffúz és a spekulárisindirekt komponensek kiszámítására.

A direkt megvilágítás a fényforrásokból felületekre - közvetlenül vagy tökéletesenspekuláris felületekrõl továbbverõdve - érkezõ fénymennyiséget jelenti. A nagyfényforrásokat - Monte Carlo mintavételezéssel - adaptívan osztja fel a pontosárnyékszélek kiszámítása érdekében. Nagy, síkfelületek spekuláris átvitelét a virtuálisfényforrások módszerével oldja meg. Ez azt jelenti, hogy az ilyen felületeket úgy kezelimintha áttetszõk lennének és mögöttük egy-egy virtuális fényforrás lenne.

A tökéletesen spekuláris indirekt komponenst a bejövõ sugár megfelelõ (visszaverõdésivagy áteresztési) irányba való továbbindításával kezeli. Nem tökéletesen spekulárisfénytovábbítás esetén pedig Monte Carlo mintavételezést alkalmaz a visszaverõdési /áteresztési irányra.

44

4.11. ábra: Dekstop Radiance-szal megjelenített épületbelsõ

A diffúz indirekt komponenst Monte Carlo becsléssel végzi, mivel a diffúz indirektkomponens a felületeken lassan változik. Megjegyezzük, hogy ez az alapfeltételezés aradiozitás (radiosity) módszernél is, bár az az input adatokra további megkötéseket tesz.A Radiance a Monte Carlo számításoknál elérhetõvé vált gradiens információtelraktározza a késõbbi interpolációk javítására. Ezt a technikát irradiancia cachelésnekhívják.

A Radiance képes az elõzõekben leírt alap szimuláción felül másodlagos fényforrásokatis kezelni. Ez azt jelenti, hogy a képszintéziskor figyelembe veszi a Napsugárzást, azablakokon beszûrõdõ, illetve minden más módon "bejutó" fényt. Ezt a szimuláció elõttegy elõfeldolgozási lépésben teszi meg, amellyel a végsõ képszintézis hatékonyságát éspontosságát növeli.

4.1.3.2. AutoCAD

Az AutoCAD ([26]) a világ legelterjedtebben használt CAD rendszere. A személyreilletve alkalmazásra szabható felülete miatt igen széles körben alkalmazható: építészek,mérnökök, tervezõk kedvelt eszköze. Az AutoCAD a mérnöki munka szerteágazófeladatait egyedi modulokkal valósítja meg.

4.1.3.3. Kezelt fájl formátumok

Az AutoCAD a saját fájl formátumain kívül kevés mást kezel. Az AutoCAD csak a sajátDXF / DWG fájljait képes beolvasni, azaz importálni. Kimentésnél - a DXF / DWG-nfelül - lehetõséget ad 3DS fájlok mentésére.

45

4.12. ábra: Desktop Radiance-szal megjelenített épületbelsõ

4.1.4.4. Desktop Radiance

A Desktop Radiance ([28]) egy olyan modul, amely beépül az AutoCAD-be. A DesktopRadiance öt funkciócsoportot foglal magába:

• grafikus editálást, modellezést• az anyag, a fényforrás és a bútor könyvtárak kezelését• a fényviszonyok szimulációját• interaktív képszintézist• az elkészített képek analizálását, manipulálását

Tehát a világítástervezés folyamata úgy zajlik, hogy a felhasználó elkészíti az épülettervrajzát, amelyhez - a modellezési fázisban - hozzárendeli a Radiance számáraszükséges elemeket (fényforrásokat, anyagokat, bútorokat, kamerákat stb.). Ezekbõl azelemekbõl könyvtárakat is létrehozhat. Ha a könyvtárak leíró formátuma megfelelõszinten elterjed, akár gyártóktól is letölthetõk lesznek. A modellezési fázis után aszimuláció következik, amely a színtérben szereplõ fény mennyiségét határozza meg. Aszimuláció során kiszámolt értékekbõl ún. szkenáriók jönnek létre, amelyek az interaktívképszintézis alrendszerrel (rview) megtekinthetõk. Az itt beállított paraméterek alapján aképszintézis alrendszer képeket készít, amelyeket utólag elemezni és manipulálni lehet.

46

A fényviszonyok meghatározására a Simulation Manager szolgál. Miután az AutoCADrajzban elhelyeztük és beállítottuk a Radiance számára szükséges elemeket, indítható aszimuláció. A számítások során a Radiance nemcsak a mellékelt elemek tulajdonságaitveszi figyelembe, hanem a helyszín földrajzi koordinátáit, a szimulálni kívánt idõpontot(dátum és óra / perc is állítható), és a pontosságra vonatkozó adatokat.

Az elkészült képek analízise az Image Analyser alrendszerrel (azaz a winimageprogrammal) végeztethetõ. A Radiance egyik elõnye a valós világ nagy dinamikaitartományának kezelése az RGBE képformátumban. A képek vagy skalár adatokat, vagyluminancia / illuminancia értékeket tartalmaznak. Ezt azért fontos kiemelni, mert a skalárképek nem alkalmasak analízisre, hisz ezekbõl hiányoznak a valós világ nagy dinamikaitartományának értékei.

4.1.3.5. Könyvtári elemek

A projekt során nem tekintjük feladatunknak anyag, fényforrás stb. könyvtáraklétrehozását és azok ArchiCAD modellekben történõ elhelyezését. Ennek ellenérefontosnak tartjuk kiemelni, hogy a Desktop Radiance könyvtári elemei milyenjellemzõkkel bírnak, hisz ez a tudás a késõbbiekben az ArchiCAD fejlesztésénél ishasznosítható. A 4.13. ábrán az anyag-, a 4.14. ábrán pedig a fényforrásjellemzõkmegadására szolgáló dialógus ablak látható.

4.13. ábra: fizikai alapú anyagjellemzõk megadása a Desktop Radiance-ban

47

A Desktop Radiance a következõ anyag tulajdonságokat ismeri:

• az anyag neve• az anyag Radiance-beli azonosítója• az anyag gyártója• az anyag gyártójának kódja• az adat forrása• az anyag visszaverési képessége (reflectance)• az anyag spekuláritása (specularity)• az anyag áteresztõ képessége (transmittance)• az anyag érdessége (roughness)

4.14. ábra: fizikai alapú fényforrásjellemzõk megadása a Desktop Radiance-ban

A Desktop Radiance a következõ fényforrás tulajdonságokat ismeri:

• a fényforrás neve• a fényforrás Radiance-beli azonosítója• a fényforrás típusa (pontszerû, szpot, területi)• a fényforrás gyártója• a fényforrás gyártói katalóguskódja• az adat forrása• a fényforrás teljesítménye Wattban kifejezve• a fényforrás fényárama lumenben kifejezve• a fényforráshoz kapcsolódó lecsengési tulajdonságok (dirt and lump depreciation)

48

4.1.4. trueSpace

A Caligari vállalat 1994-ben mutatta be a trueSpace-t ([29]), amely azóta már többverziót is megért. A trueSpace ipari formatervezõ programként a közepes teljesítményûszámítógépek szintjén olyan lehetõségeket kínál, mint az inverz kinematika, a hibridradiozitás (radiosity), a légkör megjelenítése, a pontos ütközés meghatározás, NURBS-okhasználata, a csontváz-deformáció stb.

A trueSpace a nyitott architektúrájú alkalmazások körébe tartozik, amely a programgyors, egyszerû továbbfejlesztését teszi lehetõvé. Ahogy már láttuk a 3D Studio MAX ésa Maya esetében is, ez azt jelenti, hogy plugin-okat írhatunk, amelyek a futtatás során aprogramhoz dinamikusan szerkesztõdnek. Egy plugin inicializálás után képes egydialógus ablakot felrakni, a programból bármilyen paramétert átadhatunk neki, amelyeketa beépített függvényeken keresztül visszaadhatunk a trueSpace-nek. A plugin-okatbármilyen fordító segítségével megírhatjuk, de jelenleg az elsõdlegesen a MicrosoftVisual C++ támogatott.

4.15. ábra: trueSpace-szel megjelenített épületbelsõ

A trueSpace program a radiozitás (radiosity) módszerével állítja elõ a képeket. Mivel ez aglobális illuminációs módszer csak a diffúz módon sugárzó felületeket és fényforrásokatképes kezelni, a felhasználó utólagosan sugárkövetéssel (ray-tracing) a spekulárisenergiaátvitelt is szimulálhatja. A teljes képszintézis folyamat kezelése felhasználóbarát.

49

4.16. ábra: trueSpace-szel megjelenített épületbelsõ

A trueSpace a következõ fényforrás típusokat engeedi meg: pontszerût, párhuzamost,szpotot, valamint az úgynevezett térfogati fényforrásokat (felületi, égbolt, projektor). Afelületi és égbolt fényforrások a radiozitás hatékonyabb használatát segítik elõ. Atérfogati fényforrások a fényforrás szórásának modellezését támogatják olyanhelyzetekben, amikor a fény az atmoszférán halad keresztül.

4.1.5. Architech.PC

Ebben az alfejezetben az Architech.PC nevû CAD rendszert mutatjuk be, amely fizikaialapú képszintézis alrendszerrel rendelkezett. Ezért ezt a programot nem a legutolsóverzió funkcionalitásának áttekintésével mutatjuk be, hanem a képszintézis rendszerénekfejlõdési stádiumaival. Az egyes lépéseknél felhalmozódott tapasztalatok nagyonhasznosak lehetnek az ArchiCAD képszintézis alrendszerének újratervezésekor.

4.1.5.1. A kezdetek

A tervezõ program fejlesztése a '90-es évek elején kezdõdött, amelynek már õse is közeltíz éves múltat tudhatott maga mögött. Akkor már mûködött egy árnyalt és vonaltakartmegjelenítési mód is, amelyekkel szemben az új tulajdonosok erõs fenntartásoknak éselégedetlenségnek adtak hangot. A vonaltakarás eljárásnak analitikus pontosságúmegoldására volt szükség, lévén a legfontosabb periféria a rajzgép volt. Ez a nagy papírfelületen tizedmilliméteres pontossággal képes vonalat rajzolni, így a raszteres eljárásalkalmatlan. Természetesen a korai változat is eredményként a takart vonalszakaszoksorát adta. E téren akkor még az AutoCAD is meglehetõsen lassú volt. Egyszerûenelfogadott, általánosan tudomásul vett tény volt e mûvelet lassúsága, amely aggasztómértékben fokozódott az elemszám növekedésével.

50

Ekkortájt az Architech.PC egyik fõ feladataként tûzte ki ennek az eljárásnak alecserélését jóval gyorsabb és pontosabb megoldásra. Utóbbira azért is szükség volt, mertaz örökölt változat számolt kimenete némi retusálást is igenyelt, ugyanis olykor tévedett,ezt-azt figyelmen kívül hagyott. Az új algoritmus egy hatékony elõszûrõ hálóra épült, ésmás kisebb ötleteknek köszönhetõen lényegesen gyorsult és precízzé vált. A korábbieljárás egy már bonyolultnak számító épület látványán 50 órát dolgozott és ezután 15-30perces kézi javítgatás következett, míg az új 12 perc alatt adta ki a pontos eredményt.

Az Architech.PC esetében is a fõ csapásirányt az árnyalt megjelenítés jelentette és ehhezsikerült alkalmas és gyors árnyékvetõ eljárást kidolgozni. Ez abban az idõben nem voltigazán elterjedt. A kiállításokon általában egy alapsíkra, padlóra vetített napfény árnyakavolt a képeken, amely meglehetõsen hiányos és elégtelen eljárás. A módszer legfõbbbaja, hogy az így átadott adatokban kell feltüntetni mi a "padló", amely erõsen sérti azt aleíró elvet, amely a geometriához tetszõlegesen rendelhetõ, de attól független optikai(például szín) attribútumokból áll. A padló tükrözése is hasonlóan kezelhetõ ésugyanezekkel a problémákkal bír. Sajnos ezek a megoldások ma újra elõkerültek azOpenGL elterjedésével.

4.1.5.2. Az új képszintézis alrendszer

Ezzel megkezdõdött egy új képszintézis program fejlesztése, amely a kortársaihoz képestnégy lényeges elõnnyel bírt:

Az elsõ a pontos árnyékvetés hatékony számítása, amelyet pontszerû fényforrásokraalkalmazott. Ez egy lényeges hatáselem, mert a vetett árnyékok kapcsolatot teremtenek atárgyak között. Árnyékok nélkül a bútorok csak "lebegnek" a padló felett. Noha azArchitech.PC fejlesztõi kipróbáltak más e célra elterjedt eljárást is, de ezek árnyékaielmosódottak voltak, amelyek bizonyos értelemben valószerûek, de éppen a tárgyakérintkezését, kapcsolatát (például egy keskeny székláb szintén keskeny árnyékát)"elmismásolja". A radiozitás (radiosity) eljárás szintén ezzel a hátránnyal bír. Képtelen afinom árnyékstruktúrák kezelésére, amelyek - csekélységük ellenére - meghatározószereppel bírnak a látott struktúra értelmezésében.

A második és akkoriban egyedül álló ötlet az volt, hogy a lámpák fényénél alkalmaztákaz ún. reciprok négyzetes törvényt, amely a fizikában fontos szabály pontszerû sugárzókesetén. Más programokban ezt a viselkedést befolyásolni lehet, és szerencsére ezt akarakterisztikát is ki lehet választani. Az Architech.PC fejlesztõi ragaszkodtak a fizikaimodellhez, hiszen ha nem ezt tennék, a legcsekélyebb mértekben sem tudtak volna afényforrások teljesítmény-arányát modellezni. Ez homlokzati megvilágításnál, ahol azinterreflexió és az égbolt fény elhanyagolható, valamint a fényforrások pontszerûnektekinthetõk, az Architech.PC eljárása mint világításmodellezõ ajánlható volt. Sõt,bizonyos mértékig ez az elõny a színpadi világítástervezéskor is megmaradt, így azArchitech.PC-t ezen a területen is használták. Mindezeken felül a képek valószerûeklettek. Különösen az épületbelsõk lámpafényei jelentek meg valószerûen.

51

A harmadik fontos újítás egy a valóságban nem igen tapasztalható, fizikailag azonbanlehetséges és korrekt reflexiós modell bevezetése volt, amelyet célszerû volt használni adiffúz modell helyett a látványos és plasztikus hatás elérésében. Ennek az a lényege,hogy minél kisebb szögbõl látjuk az ilyen felületeket, azok annál sötétebbekké válnak.Ezáltal közvetlen fény hiánya esetén, amikor csak általános ambiens fényértékkeldolgozhattunk, nem egy semmitmondó homogén színfoltot kaptunk, amelynek semmimélységi hatása nincs, hanem egy a mélységgel finoman változó ambiens árnyalást,amely következett a felület albedójából.

A negyedik és talán ebben a formájában szinte egyedülálló módszer újdonsága a számoltlátvány képernyõ színértékeire való transzformálásban volt. A már említett valósághûlámpa-karakterisztika a végletesen nagy hatáskülönbségek hátrányával bír. Valószínûlegez az oka annak, hogy kötelezõ érvényérõl a konkurens programokban lemondtak. Másszavakkal: emiatt a képen nagy dinamikai különbségek adódnak. Ezt a hatást afényképészek igen jól ismerik. Ezért a belsõ terek fényképezésekor igyekeznek deríteni, alámpa, illetve az ehhez közeli falfelület fénytócsáját a képkivágáson kívülre hagyni, merta fényérzékeny anyag igazából csak kis dinamikát tud leképezni. Az Architech.PCviszont élhetett a dinamika expanzió és kompresszió lehetõségével, amellyel a fotós csaka nagyított képek elõhívásakor dolgozhat. Az Architech.PC algoritmusa önmûködõenkalibrálta a képet, majd a szükséges dinamikamódosítással jelenítette meg a képernyõn.A képen lévõ információ néhány százalékos hányadáról lemondott. Ez alatt azt kellérteni, hogy a képelemek kisebb része lehet teljesen beégett fehér, vagy teljesen fekete.Az algoritmus dolga, hogy meghatározza azt az ablakot, amelyen kívül a pixelekheztartozó fényértékek elõírt százaléka esik. Ezzel lehetõvé vált, hogy a képek készítésekorviszonylag kevés selejtet kapjunk, és amennyire lehetséges volt, mégis csak a fizikailagmodelleztük a látványt - igaz a lényeges, de nehezen számolható interreflexió kimaradt.Másfelõl a számítógépes animációban szokatlan, a valóságban viszont természetesélmény, hogy a világosság változásakor a szem vagy a filmfelvevõ kameraalkalmazkodásánál bizonyos tehetetlenséget figyelhetjük meg. Tehát az animációkészítése nem egyszerûen sok független állókép generálásának egymásutániságát jelenti,hanem az említett algoritmust a korábbiaktól való függõséggel, tehetetlenséggel kellettfelruházni. Ezáltal a mozgás a különbözõ fényviszonyok közt természetes hatással bírt.

4.1.5.3. A második verzió

A program második változata teljes újraírás után született meg, de a sok apró újdonságközül csak egyet emelnénk ki. Az ambiens fényérték megválasztása eleve nem lehet másmint csalás, hiszen az interreflexiós járulékot cseréljük le jóval egyszerûbbre. Vegyükazokat a fényeket, amelyek a képre kerültek, átlagoljuk ki, a színtartalmát egy bizonyosmértékben hagyjuk meg és nevezzük ezt ambiens fénynek, amelyet ezután a felületekalbedójával szorzunk. Ez a "pofonegyszerû" elv harmóniát teremt a mesterkélt ambiensfény erõssége, színe és a fizikailag pontos közvetlen megvilágító hatás között.

52

Az Architech.PC célja az interreflexiók hû modellezése is volt. Ráadásul az említettesetekben a megjelenítõt már világítástervezéshez használták, így ez a funkció igenkívánatosnak látszott. Akkor reményt egyedül a radiozitás (radiosity) módszer vagy másnéven a véges elem feladat megoldása adott. Ha figyelembe vesszük, hogy egy épületimodell már egészen nagy bonyolultságot is elérhet, másrész az akkor használatos gépekteljesítménye durván század akkora volt, mint a maiaké, akkor ez a funkció talán kicsitfölöslegesnek tûnhet. Azonban az Architech.PC fejlesztõi azt látták, hogy ha sikerül aszámítást egy éjszakányi idõ alá szorítaniuk, akkor sok ügyfelük örülne és használná aszolgáltatást. Az akkor ismert megoldások számítási ideje a használt elemek számánaknégyzetével volt arányos, amely haladás jelent ahhoz képest, amikor a memória igény ishasonlóan nõtt. Nyilvánvalóan ezek a módszerek alkalmatlanok arra, hogy több százezerfelületelem fényértékeit kiszámíthassuk. A szakirodalomban közölt legbonyolultabbmodell is csak 50.000 elembõl állt.

Több kísérleti eredmény született: a "transzillumináció" azt ígérte, hogy ezzel elérhetjükaz elemek számával lineárisan növekvõ mûveletigényét, amely elõreláthatólag igendrasztikus gyorsulást jelentene a négyzeteshez képest. Végül a radiozitás (radiosity)feladatra sikerült is használni. Bár a módszer nem lett robosztus, hisz könnyenkreálhattunk olyan fényviszonyokat, amelyek között a transzilluminációs megoldás isrettenetesen lelassult. Komplementerével az ún. lövõ módszerrel házasítva vált teljessé,ezáltal pedig a megvilágítási helyzetekre jóval kevésbé érzékennyé. A tesztek aztmutatták, hogy 420 ezer elemre is kiválóan mûködik. Gyakorlatilag egy nap alatt megvolta megoldás. Bár a lövõ lépés nem lett kipróbálva, de a becslések szerint ez akár 4-5-szörös gyorsulással járt volna. Szintén némi gyorsulást jelentett a kvázi véletlen számokhasználata. Bár még megoldatlan problémát jelentett a kapott geometria elemekrebontása, amelyben leginkább nyugtalanítónak a síklapokkal közelített görbülõ felületekszögletmentesítése látszott.

4.1.5.4. A harmadik verzió

Bár itt a siker egyértelmû és lelkesítõ volt, az Architech.PC mégsem ebbe az iránybahaladt tovább. A trend azt mutatta, hogy a képek "felöltöztetésére", a textúra ésmindenféle anyagok megjelenítésére nagyobb szükség volt. Visszatekintve úgy tûniksikerült olyan paraméterezést és ennek megfelelõ párbeszédablakot választani, amelyviszonylag egyszerû volt, mégis rengeteg hatás beállítható volt rajta, és ezek megfeleltekaz alapvetõ fizikai modellezési elvárásoknak is. Az Architech.PC használt szolgáltatásavolt a "transzparencia maszk" képpel való textúrázása. Ezzel tetszõlegesen bonyolultkontúrú kétdimenziós alakzatot lehetett megjeleníteni (például levélerezetet), de volt rápélda, hogy egy építész egy kastély és kertjének rekonstrukciós tervét olyan színesképeken mutatta be, ahol a meghökkentõ részletezettséggel kidolgozott, felettébb díszeskovácsoltvas kapu legfinomabb cirádája sem hiányzott, míg bent a termek falaitstukkódíszítések tagolták. Ezeket és más látványos és pontos hatást a domborzati textúraés a maszkolós transzparencia eszközei produkálták. Mindez azt mutatta, hogy a pusztalátvány, amelynek elõnye mûszakilag nem feltétlenül racionális, a való életben piacieszközzé válik.

53

A megjelenítõ e harmadik változata egy másik fontos elõrelépést is tett az égboltfény hûmodellezése kapcsán. Az égbolt fényértékét egy kissé nehézkes algoritmus számolta egyirányhoz képest megadott szög alatt álló Nap adataiból és az égbolt felhõ lefedettségifokszámából. Ezzel a funkcióval az épületek már nem sterilen, egyhangú háttér elõttálltak. Más programokban erre tetszõleges háttértextúrát használnak, amelyet azArchitech.PC fejlesztõi azért vetettek el, mert ezen hátterek nem garantálják, hogy ahorizont jó helyre kerüljön. Ráadásul egyáltalán semmi kapcsolat nincs a virtuális kameraés e kép valódi kamerájának beállításai közt. Ez különösen "komikusnak" tetszhet,amikor egy animációban az épületet körbejárják és a képkivágásban mozdulatlan a felhõstáj. Tehát az Architech.PC reális égboltozata igen jól festett. Ráadásul még azzal azelõnnyel is bírt, hogy beépítettek egy opciót, amellyel a csillogó felületek valóditükrözést kaphattak. Ez úgy történt, hogy ezeken a felületeken az égbolt képe a beállítottmértékben tükrözõdött. Ezt külsõ nézetekben volt célszerû használni, mert egy sötétszobáról számolt képen ez igencsak zavaró, érthetetlen lett volna. Ez annak voltköszönhetõ, hogy a tükrözés mögött a takarási feladatot nem oldották meg, vagyis atárgyak ekkor még egymáson nem látszódhattak, csak a nagyon távoli környezet. Viszontaz üveg-acélpaloták, vagy úszómedencék ábrázolásában ez igen hasznos és látványosvolt.

Nos ezen a fokon a megjelenítõ annyi újdonságot és bevált megoldást tartalmazott, hogyvégül már ezekrõl lemondani nem lehet. Ez a magyarázata annak, hogy a radiozitásmódszer háttérbe szorult. Természetes volt a tükrözõdés, a fémes hatás, a textúrákhasználata - beleértve a domborzatit is. A megfelelõ kombinációkkal olyan hatásokatérhettek el, mint az említett rokokó kastély kerttel. Más modellezési eszközökkel arészletezettséget csak háromszögek millióival helyettesíthették volna. Az azonbanlátszott, hogy a mélységi pufferre alapozott módszer bonyolulttá vált. Néhány nem túlgyakori esetben túlságosan lelassult, így az Architech.PC fejlesztõinek érdeklõse asugárkövetés (ray-tracing) eljárás felé fordult.

4.1.5.5. A negyedik verzió

A megjelenítõ negyedik verziójában, a takarási megoldások teljesen lecserélõdtek asugárkövetés eszközeire. Ez egyszerûsített, de az is igaz, hogy a kritikus objektum ésfélegyenes metszéspontszámításnak csak sokadik változata vált elfogadhatóan gyorssá.Ez a módosítás valódi tükrözéseket is jól szimulált, a felületek paraméterezése éslátványa viszont maradt a régi.

A másik nagy elõny, hogy a kép kiértékelését tetszõleges helyen elkezdhettük és aképpontokhoz tartozó értékeket bármilyen sorrendben lekérdezhettük - a hatékonyságromlása nélkül. Ezáltal lehetõség nyílt kifinomultabb csipkézettség csökkentõ (anti-aliasing) módszerek kipróbálására. Végül is az ún. jittering beépítésével jobb eredménytkaphattunk, mint a korábbi módszerrel kétszer annyi idõ alatt. Másrészt így azArchitech.PC a kép generálását folyamatában mutatta: elõször nagy pixel mérettel éskisfelbontással, majd egyre finomodva. Az eljárás megszakítható volt, amelyet anézõpont változása idézett elõ. Ezt követõen - az új beállítások szerint - megint számolnikezdett és így e módszer gyors gépen a valósidejû bejárás illúzióját adta. Amikor a

54

mozgás leállt, a számítás folytatódott és a kép véglegesre finomodott. Bár ez utóbbimégsem vált a termék részévé, mert sajnálatos módon a modulok hatékony integrációjanem volt lehetséges. Mindenesetre a kezdeti aggályokat, amelyeket a sugárkövetésrõlkialakult kép táplált, azaz, hogy lassúnak tartják, e megoldások eloszlatták ésrugalmassága jelentõs gyorsulást is okozott.

Aztán berobbant a PC-s világba az OpenGL és egyre inkább szükségesnek látszott ennekkihasználása. Bár az eszköz bonyolult, de legalább konzisztens. A gyorsító hardverek ésOpnGL megvalósításaik viszont állandó problémát jelentettek. Ugyanis a gyártók azOpenGL szolgáltatásaiból csak néhány alapvetõt végeztettek el a célhardverrel, a többitszofveresen emulálták. Ráadásul a specifikációnak nem megfelelõ, vagyis hibáseredményeket is adtak. Ebben a "káoszban" indult és zajlott az Architech.PC fejlesztése.A fejlesztõk sok olyan cikket töltöttek le az Internetrõl, amelyek a szolgáltatások cseppetsem triviális kiaknázásával képesek voltak domborzati textúrákat, árnyékokat és lámpákfényét, valamint tükrözést is szimulálni. Ezekrõl azonban kiderült, hogy ez az akkorelérhetõ gyorsítók képgenerálását annyira lelassítja a szoftveres emuláció miatt, valamintminden hibát olyannyira kiemel, hogy célszerûnek látszott csak az alapszolgáltatásokatigénybe venni, és ezek kreatív felhasználásával a lehetõ legjobb képeket elérni.

Ezért az Architech.PC lemondott az árnyékvetésrõl, a lámpafényrõl és a tükrözõdésrõl, dea képek az olcsóbb hardvereken is valós idõben és textúráik teljes pompájában jelentekmeg, a domborzati minta és az átlátszóság sem hiányzott. Más kisebb trükkökkel,valamint a környezeti fény a valósidejû mozgás látványa elégedettséget váltott ki ésbonyolultabb eljárásokra már nem volt igény. Ha mégis volt ilyen igény, akkor azArchitech.PC fejlesztõi a felhasználóknak azt ajánlották, hogy használja a lassabb, deamúgy minden tekintetben jobb sugárkövetõ eljárást.

4.1.5.6. Jövõbeli tervek, prototípusok

Eközben az építészeti program negyedik verziójára szánt megoldások is kiérlelõdtek, deezek beépítésére már nem kerülhetett sor, mert a cég csõdbe jutott. Az Architech.PCfejlesztõi az ún. kétirányú sugárkövetés módszerétõl várták a legjobb minõségû képeket,amelyek leginkább megközelítik a valós látványt. Bár ezek számítási ideje több óra, de azépítészeket ez nem szokta eltántorítani. Ennek a módszernek a fejlesztése - többváltozaton keresztül - hat éven keresztül folyt. Ez azért mutatja azokat a nehézségeket,amelyek megoldása közül néhány kisebb még hátra maradt. A 4.17. és 4.18. ábrán láthatóképek ezzel a kétirányú sugárkövetõ módszerrel készültek.

Továbbá az OpenGL gyors megjelenítésének hála a radiozitás megoldás interaktívbejárása lehetõvé vált. A feladat megoldására az Architech.PC fejlesztõi nem az említettmódszert, hanem a valamivel lassabb, de már meglevõ és hatékonynak tetszõsugárkövetési takarási feladatot használták. Ezen új szolgáltatás nem növeli nagyon akódot: a sugárkövetéssel együtt használ egy kritikus modult, amely mérnöki szemmelnézve kedvezõ megoldás egyszerûsége miatt. Itt az Architech.PC lemondott a csillogóhatásokról, csak diffúz felületekkel dolgozott.

55

Egy évtized fejlesztése már tarthatatlanná tette azt a helyzetet, amelyben a tucatnyi létezõés tervezett megjelenítési mód beépítésének eltérõ idejû megvalósításából ésszoftvermérnöki elégtelenségbõl fakadt. Ennek az lett a következménye, hogy ezektöbbnyire külön interfésszel lettek a rendszerhez csatolva, amely így ésszerûtlenülbonyolulttá, szolgáltatásaiban nem igazán kihasználhatóvá vált. A közös interfészmegtervezése égetõen fontosnak látszott. A terv az volt, hogy az MVC (Model-View-Controller) architektúra alapján mûködjön. Ez gondoskodott volna a változások robosztuskezelésérõl. Vagyis ha a modell egy elemén módosítunk, akkor annak nézetei is egyszabatos mechanizmuson keresztül módosultak volna. Az OpenGL ún. megjelenítésilistáival (display list) kiegészítve az interaktív folyamatok optimális számításiszükséglettel, valamint optimális memória kihasználással mentek volna végbe. Itt egyfontos felismerés volt, hogy az eddig elõállított köztes adatok (például háromszög- ésvonallisták) tárolása szükségtelenné válik. A megjelenítõ feladata az említettmegjelenítési listában (display list) megjegyezni az adott módhoz és elemhez tartozóutasítássort. A tervezõrendszer felépítése azt mutatta, hogy egyedül itt indokolt a köztesadatok tárolása, a program ezeket megelõzõ fázisaiban már nem. Ez azért nem igaz, hiszezek között vannak idõigényes mûveletek (például fal-tetõvágás).

4.17. ábra: kétirányú sugárkövetéssel megjelenített Buddha szobor

56

4.18. ábra: kétirányú sugárkövetéssel megjelenített nõi szobor

Az Architech.PC fejlesztõi azt is feltételezték, hogy a modellelemekhez majd olyanuniverzális eljárások készülnek, amelyeket egy szintén univerzális interfész teszlehetõvé. Vagyis egy konkrét építészeti elem egy elõírt eljárása önmagát geometriaiprimitívekre bontja, azokhoz a szükséges attribútumokat õ vagy a hívója beállítja -függetlenül attól, hogy ez milyen megjelenítéshez kell. Ettõl a fejlesztõk jelentõsegyszerûsödést és nagyobb hatékonyságot vártak. Egy távolabbi tervben a kétdimenziósmegjelenítést cseréltük volna le erre, és egyáltalán minden grafikus mûveletet - beleértvea párbeszédablakok grafikáját, feliratait is.

4.2. Csak képszintézis alrendszerrel rendelkezõ programok

A képszintézis alrendszerrel rendelkezõ szoftverek igen nagy részét nem integrálják összevalamilyen modellezõ alkalmazással, hanem önálló programként funkcionálnak. Ilyenkora modellezõ programban létrehozott színtérmodellt a képszintézis program számáraelérhetõvé kell tenni. Az esetek igen nagy százalékában ez azt jelenti, hogy a két programközötti kommunikáció megvalósítására közbülsõ fájlt használnak.

57

Ebben az alfejezetben néhány jellemzõ globális illuminációs elvû képszintézisselrendelkezõ programcsomagot tekintünk át, amelyek nem rendelkeznek modellezõalrendszerrel. A kiválasztott programok két csoportba sorolhatók: kommerciálistermékek, illetve kutatási projektek keretében elkészült programcsomagok.

Vizsgálódási szempontjaink között kiemelt szerepet kapnak az offline kommunikációmegvalósítására használt fájl formátumok. Természetesen csak a képszintézisszempontjából érdekes formátumokat írjuk le. Ezt a tudást felhasználva a 6. fejezetbendefiniáljuk a projekt során elkészülõ önálló program interfész követelményeit.

4.2.1. Lightscape

A Lightscape ([30]) egy fejlett világítástervezõ program, amelyet az évek során számoscég tudott magáénak. Jelenleg az Autodesk vásárolta meg és ajánlja a mental ray mellettprofesszionális képszintézis alkalmazásként.

4.2.1.1. Könyvtári elemek

A Lightscape is fizikai alapú anyag- és fényforrásjellemzõket használ, amelyekbõlkönyvtárakat hozhatunk létre. A 4.19. ábrán az anyag-, a 4.20. ábrán pedig afényforrásjellemzõk megadására szolgáló dialógus ablak látható.

4.19. ábra: fényforrásjellemzõk a Lightscape-ben

Az anyagjellemzõk között a "szokásos" fizikai tulajdonságokat találhatók:

• az anyag neve• az anyag visszaverési képessége (reflectance)• az anyag spekulárissága (specularity)• az anyag áteresztõ képessége (transmittance)

58

4.20. ábra: anyagjellemzõk a Lightscape-ben

A Lightscape a következõ fényforrás tulajdonságokat ismeri:

• a fényforrás neve• a fényforrás típusa (pontszerû, szpot, területi)• a fényforrás teljesítménye Wattban kifejezve• a fényforrás fényárama candelában kifejezve

4.2.1.2. Kezelt fájl formátumok

A Lightscape a saját fájl formátumain felül kevés egyebet kezel. Ez elsõ körben meglepõlehet, de mivel olyan formátumokat választottak, amelyeket ipari szabványoknaktekinthetünk, így ezzel a döntéssel mégiscsak sikerült a színtérmodellek igen széles körétlefedni.

A Lightscape saját formátumain felül a következõket képes betölteni, azaz importálni:

• DXF: az AutoCAD által bevezetett formátum mára ipari szabvánnyá vált, így a2D / 3D CAD rendszerek kötelezõen támogatott formátumai közé került. Eznagyrészt annak köszönhetõ, hogy az USA-ban csak DXF-ben lehet tervrajzotbeadni.

• 3DS: a 3D Studio DOS-os fájl formátuma, amely általános, háromdimenziósobjektumok leírására szolgál. További részletek a 6. fejezetben olvashatók.

A Lightscape saját formátumain felül a következõket képes kimenteni, azaz exportálni:

• VRML: a Virtual Reality Markup Language a HTML-hez hasonló leírónyelv,amelyet böngészõbõl nézhetõ színterek leírására találtak ki. Mára ipariszabvánnyá vált. További részletek a 6. fejezetben olvashatók.

59

4.2.1.3. Globális illuminációs megoldása

A Lightscape globális illuminációs algoritmusa a radiozitást (radiosity) és a sugárkövetést(ray-tracing) kombinálja. A program fizikai alapú anyag- és fényforrás megadást használ.Ezekre alapozva valósítja meg a fényeloszlás fizikai alapú szimulációját, így azeredményképek nemcsak valószerûek, de egyben a megjelenített színtérbeli fényeloszláspontos "mérési" adatai is.

A Lightscape a radiozitás módszert arra használja, hogy a színtér diffúz megvilágításátkiszámolja, a képszintézis során a puha árnyékokat (soft shadows) és a felületek közöttiszínszivárgást (color bleeding) megjelenítse. Mivel a radiozitás nézõfüggetlen módszer,így a felhasználó a fényeloszlás kiszámolása után a színtérben interaktív sebességgelmozoghat.

4.21. ábra: Lightscape-pel megjelenített épületbelsõ

A radiozitás a számítógépi grafikában 1984-ben jelent meg. Azóta számos javítását,módosítását publikálták. Az egyik legjelentõsebb javítás a progresszív finomításmódszere volt. Ez azt jelenti, hogy minden iterációs lépéskor a legnagyobb energiávalrendelkezõ felületet tekintjük fényforrásként; a felület által emittált és visszavertfénymennyiséget pedig a fényforrás teljesítményének tekintjük. Az iteráció addig tart,amíg a színtérben az energia legnagyobb része el nem nyelõdik. Természetesen lehetõségvan arra is, hogy a felhasználó megállítsa az iterációt és néhány paraméter módosításaután továbbfutassa. Ilyenkor az iterációt nem kell a kezdõpontról újraindítani, így a végsõképet relatív gyorsan kaphatjuk meg.

A Lightscape nemcsak diffúz visszaverõdéseket tud kezelni, hanem spekulárisakat is,amelyek hatását a készítendõ képeken sugárkövetéssel jeleníti meg. A Lightscape szinténa sugárkövetést használja az árnyékok és az áttetszõ felületek kezelésére.

60

Bár a véges elemes iteráción alapuló módszereknek nagy memóriaigényük van, aprogresszív finomításnak és a sugárkövetésnek köszönhetõen ez az érték nem annyiramagas, mint más módszereken alapuló programoknak.

A színtérbeli fényviszonyok meghatározásakor - a Desktop Radiance-hoz hasonlóan - aLightscape is figyelembe veszi a helyszín földrajzi koordinátáit és a szimulálni kívántidõpontot (dátum és óra / perc is állítható).

Mivel a Lightscape egy fizikai alapú képszintézis program a radiozitás során kiszámoltfényeloszlás értékeket fel lehet használni a színtér fényviszonyának analizálására. ALightscape-pel a modellben levõ fényeloszlást pszeudo-színezési módszerekkel lehetmegjeleníteni, illetve a megvilágítási értékek számszerû kijelzésével. A Lightscapeinteraktívan képes különféle statisztikai adatokat (például átlagok, szélsõértékek stb.)szolgáltatni.

4.22. ábra: Lightscape-pel megjelenített szobabelsõ

Érdekes funkció a Lightscape-ben a "Mesh to Texture Wizard". Ez a lehetõség apoligonhálót (mesh) textúrává képes konvertálni. Az így létrehozott textúrátsíkfelületekre ráhúzva olyan hatást kelt mintha nagy komplexitású színteretszintetizáltunk volna. Tehát ezzel a módszerrel a színtér komplexitását jelentõsencsökkenthetjük. Ezeket a textúrákat az elõzetes kép alapú szintézisben (image basedrendering) imposztoroknak hívják.

4.2.2. Artlantis

Az Artlantis ([31]) az 1985-ben alapított Abvent leghíresebb és az építészek körében igenelterjedt képszintézis programja. Jelenleg a 4.0-s verziónál tartanak, amely az eddigihibrid (pásztaalapú és sugárkövetéses) képszintézisébe bevezette a globális illuminációselvet is. Tehát két szempontból is érdemes a programot megvizsgálni:

• építészek körében kedvelt, jól használható, gyors képszintézist biztosítóalkalmazás

61

• globális illuminációs elvû képszintézissel rendelkezõ, modellezõ alrendszerrelnem integrált megoldás

4.2.2.1. Egyszerû felhasználói felület

Az eddig bemutatott programok nagyrészt professzionális felhasználóknak készültek, ígyelég bonyolult kezelõ felülettel rendelkeznek. Az Artlantis egyik nagy pozitívuma arettentõ egyszerû felhasználói felület, amelyet az építészek gyorsan meg tudnak tanulni,szép képek elõállításához nem igényel komoly grafikai elõismereteket.

4.23. ábra: Artlantisszal megjelenített szoba

A 4.24. ábrán ennek demonstrálására a kamera beállítására szolgáló felületet mutatjuk be.Az ábrán balra fent látható a - kissé Macintosh érzést keltõ - kameraadatok tartalmazódialógus ablak. Jobbra fent az adatokat vizuálisan is módosíthatjuk. Lent pedig egy"preview" ablak látható, amelyben gyorsan, draft minõségû képeket lehet megjeleníteni.Tehát a felhasználónak nem kell háromdimenziós világokban mozognia, ehhez nem kellbonyolult interfészi elemeket megtanulnia. A felhasználónak azon sem kellgondolkodnia, hogy milyen nézetet válasszon, hisz a perspektív nézetet a preview ablakbiztosítja, az axonometrikus (felül, oldal, elöl) vetítéseket pedig az interaktív paraméterbeállításra szolgáló ablak. Ez a fajta egyszerûsítés jelentõsen csökkentheti a munkárafordított idõt. Bár hozzá kell tenni, hogy professzionális felhasználókban pont az ilyenegyszerûség okozhat frusztráló hatást is.

62

4.2.2.2. Anyag- és fényforrásjellemzõk

Az Artlantis kezelõ felületére és alapkoncepciójára jellemzõ, hogy olyan funkciókat ad,amelyek könnyen megérthetõk. Ezért sem az anyag-, sem a fényforrásjellemzõkbeállítására szolgáló dialógus ablakok nem túl zsúfoltak, szinte csak a minimálisfunkcionalitást biztosítják. Természetesen, egy ennyire a használhatóságra kihegyezettprogramtól nem várható el, hogy fizikai alapú anyagok és fényforrások használatáttámogassa. A 4.25. ábrán az Aged Copper nevû anyag jellemzõit mutató dialógus ablakotláthatjuk. Az ábrából jól látszik, hogy az eddig bemutatott programokhoz képest azArtlantis milyen kevés adattal próbálja a professzionális alkalmazások képességeitutánozni.

4.24. ábra: kamera adatok beállítása az Artlantisban

63

4.25. ábra: az anyagjellemzõk beállítására szolgáló dialógus ablak

4.26. ábra: fényforrásjellemzõk beállítására szolgáló dialógus ablak

64

Az Artlantis a 3.5-ös verzió elõtt csak szpot lámpát tudott kezelni, amelynek különbözõmódon paraméterezett verziót nevezte pontszerû illetve végtelen távoli fényforrásnak. A3.5-ös verzióban végre megjelent a párhuzamos fényforrás (heliodon) lehetõsége, ám aglobális illuminációs módszerek számára fontos területi fényforrásokat továbbra semhasználja.

A 4.26. ábrán egy szpot lámpa tulajdonságainak beállítására szolgáló dialógus ablakotmutatunk be. Érdemes megfigyelni, hogy az Artlantisban is fényforrásonként állítható,hogy vessenek-e árnyékot vagy sem. Az egyszerû kezelõ felület koncepciója miatt nincslehetõség arra, hogy kiválasszuk melyik árnyékvetõ módszerrel kívánunk dolgozni. A4.0-s verziótól kezdve az Artlantis nem éles árnyékokat (soft shadows) is meg tudjeleníteni.

4.2.2.3. Kezelt fájl formátumok

Az Artlantist számos építészeti CAD rendszerhez ajánlják kiegészítõ programként, ezértszámos formátumot képes használni. Az Artlantis a következõ fájl formátumokat képesbeolvasni, azaz importálni:

• OPT / DB: az Artlantis saját színtérleíró nyelve.• DXF / DWG: az AutoCAD által bevezetett formátumok, amelyek mára a CAD

rendszerek körében ipari szabvánnyá váltak. A DWG nem publikus. Mindkettõtartalmazhat ACIS szolid geometriai adatokat, amelyeket számos CAD rendszernem képes kezelni.

• FACT: átlagos gépeken (PC, Macintosh) elérhetõ, filmek animációs betéteinekelkészítésére is alkalmas képszintézis programok között az EletricImage fontospozíciót tölt be. A FACT az ElectricImage saját formátuma.

• IGES: az Initial Graphics Exchange Specification egy ANSI szabvány, amelyetCAD, CAM és számítógépes vizualizációs rendszerek közötti információcserérefejlesztettek ki.

• VRML: a Virtual Reality Markup Language a HTML-hez hasonló leírónyelv,amelyet böngészõbõl nézhetõ színterek leírására találtak ki. Mára ipariszabvánnyá vált. Érdekes, hogy az Artlantis csak a kissé elavultnak tekinhetõ 1.0-s szabványt támogatja. További részletek a 6. fejezetben olvashatók.

• RIB: a RenderMan Interface Bytestream a RenderMan által bevezetett formátum.• 3DS: ez a DOS-os 3D Studio fájl formátuma, amelynek a felépítése publikus.

Számos program, amely azt állítja magáról, hogy képes a 3D Studio MAX fájljaitkezelni, valójában ezt a formátumot kezeli.

4.2.2.4. Globális illuminációs megoldása

Az Artlantis marketing és fejlesztõi részlege semmilyen információt nem árul el aglobális illuminációs megoldásával kapcsolatban, ezért saját tapasztalatainkrahagyatkozunk.

65

Sugárkövetés paramétereinél a mélység szintje állítható. Ez alapján úgy gondoljuk, hogynem orosz rulett típusú sugárkövetõ algoritmust használ. A sugárkövetéssel képes kezelnia tükrözõdéseket és áttetszõ objektumokat. Elõbbire jó példa lehet a 4.27. ábra, ahol azüvegszerû pegazus felülete tükrözõ képességeket is mutat.

Minden fényforráshoz külön állítható a globális illuminációs "képesség", amelybõlsejthetõ, hogy az Artlantis nem fizikai alapú módszert alkalmaz, hanem inkább hasonlóhatást mutató effektet biztosít. Jellemzõ, hogy a felületek között színszivárgást (colorbleeding) is igazándiból csak a párhuzamos fényforrásnál, a Napnál vehetjük észre. Hiábaállítunk be egy szobába egy igen nagyteljesítményû fényforrást, alig-alig jön elõ aszínszivárgás hatása. Ez is mutatja, hogy az Artlantis csak imitálja a globális illuminációsképszintézis módszerek hatását. A 4.28. ábrán balra a lokális illuminációs modellel,jobbra pedig a globálissal készült képet mutatjuk be. Ezen az ábrán jól látható aszínszivárgás, ugyanis a színtérben az ambiens fényt igen magasra tettük és ennekhatására a párhuzamos fényeket számoló algoritmus jól kihozza a felületek közöttikölcsönhatásokat.

4.27. ábra: Artlantisszal megjelenített üvegpegazus

66

4.28. ábra: lokális és globális iluminációs modellek hatása az Artlantisban

4.2.3. RenderPark

A RenderPark ([32]) egy fotorealisztikus képszintézis alrendszerrel rendelkezõalkalmazás, amelynek fejlesztése a belgiumi Katholieke Universiteit Leuvenhez fûzõdik.E nem kereskedelmi célú projekt fõ célja, hogy implementációs alapot szolgáltasson alétezõ globális illuminációs algoritmusok kipróbálásához, egymással valóösszehasonlításához, valamint robosztus és hatékony alapalgoritmusokkal segítségetnyújtson új algoritmusok kifejlesztéséhez. A RenderPark jelenleg is számos kuriózum„state-of-the-art” algoritmust tartalmaz önmagába integrálva, amelyeket más képszintézisszoftverek nem alkalmaznak, még a nagyon drága kereskedelmi szoftverek sem.

Összefoglalva tehát a RenderPark legfontosabb célja egy tudományos alapokon nyugvótesztelõ rendszer nyújtása - elsõsorban új algoritmusok kifejlesztésére. E cél eléréséhezvezetõ úton számos algoritmust integrálva a RenderPark egy nagytudású, fizikai alapúglobális illuminációt megvalósító képszintézis szoftverré nõtte ki magát.

4.29. ábra: RenderParkkal megjelenített színtér

67

A projekt egyszemélyes vezetõje és programozója a leuveni egyetem tanára, PhilippeBekaert, aki a RenderPark fejlesztését doktori disszertációjához kapcsolódóan kezdte el1993 õszén. Bekaert 2000-ben fejezte be doktori disszertációját, a RenderPark fejlesztéseazonban azóta is folyik. A legutolsó release 2000. decemberében jelent meg.

A szoftver és a forrásfájlok is teljesen ingyenesen elérhetõek a projekt honlapjáról. Aprojekt azonban nem nyílt forráskódú (nem open-source). A forrásban változtatni csakBekaert tud.

4.2.3.1. Beépített algoritmusok

Objektum-térbeli radiancia algoritmusok:

• Galerkin radiosity (mind gyüjtõ, mind lövõ típusú). Felkészítve a hierarchikustesszellációs finomításra, magasabb rendû approximációra, clustering-re és view-importance-ra.

• Hierarchical Well Distributed Ray Set Radiosity: ez a legkönnyebben használhatóés leggyorsabb radiosity algoritmus.

• Monte Carlo és kvázi-Monte Carlo típusú véletlen bolyongáson alapuló radiosityalgoritmusok. Ezek közül a három legfontosabb:

o Pattanaik particle tracing algoritmusao Keller kvázi-Monte Carlo radiosity módszereo Sbert global multipath algoritmusa

• Stochastic Ray Radiosity• Density estimation

Képtérbeli (pixelenkénti) radiancia algoritmusok:

- sztochasztikus sugárkövetés (gyakran használatos többmenetes renderelésnélmásodik menetként)

- kétirányú sugárkövetés- fotontérkép

4.2.3.2. A RenderPark további jellemzõi

- MGF és VRML fájl formátumok olvasására képes- a szintetizált képek menthetõk TIFF és PPM formátumba. A PPM formátumhoz

nagyon sok konverterprogram létezik, amelyekkel más formátumokba a képátvihetõ.

- a radiosity-vel lerenderelt színtér elmenthetõ VRML’97 formátumban. Ekkor apoligonok radiosity-vel meghatározott színét menti el színinformációként a vrmlfile-ba, és így globális illuminációs színterek bejárása lehetõvé válik egytetszõleges VRML böngészõ program használatával.

- a RenderPark X-Windows/Motif alapra épül, ezért ilyen stílusú felhasználóiinterfésszel rendelkezik.

68

- OpenGL-es hardver támogatást is kínál (MesaGL-t könyvtárat használja), ezért aprogramon belül nagyon egyszerû (CosmoPlayer szerû kezelõi felülettel) és gyorsa színtérben való navigáció, a kamera pozíciójának és paramétereinek beállítása.

- elsõsorban ablakozófelülettel rendelkezõ program, azonban lehetõség van aszoftver parancssoros felparaméterezésére is. Ezzel akár egy távoli géprõl batch-futtatásokat is indíthatunk.

- a programnak meg lehet adni egy külsõ programból jövõ canvas-t is, hogy aképszintetizálást arra végezze. Ezzel a RenderPark képessé vált arra, hogy más pl.modellezõ-szoftverek „plug-in”-ként meghívják, és a RenderPark legyen a külsõképelõállító alkalmazásuk.

A RenderPark a következõ UNIX platformokon fordítható:

- SGI/Iris 6.4 (GNU make and MipsPro 7.2 C/C++ compiler).- SUN/Solaris (GNU gcc/SUN's cc + GNU make)- Linux (GNU gcc or egcs and GNU make)

Megjegyzendõ, hogy sem Macintosh, sem Windows platformon nem futtatható. Miveltechnológiai partner erre a két platformra fejleszt terméket, a mi projektünk számára ezeka platformok nagyon fontosak.

4.30. ábra: RenderParkkal megjelenített Cornell doboz

69

4.2.3.3. Új algoritmus fejlesztése

A RenderParkhoz új algoritmust fejleszteni nem túlságosan nehéz. Nagyvonalakban ez akövetkezõket jelenti: kell készíteni egy újabb fájlt (például UjRenderingAlg.cpp) ésebben implementálni kell egy RAYTRACINGMETHOD vagy RADIOSITYMETHODtípusú struktúrát. Ezt be kell szúrni abba a globális táblázatba, amely a renderelõalgoritmusokat tartja nyilván. Ha ezt megtettük, akkor a RenderPark ablakjánakmenüjébõl már ki is lehet választani az UjRenderingAlg nevû algoritmust, miután egyszínteret betöltöttünk a RenderParkba.

A RAYTRACINGMETHOD struktúra feltöltésénél meg kell adni például az újalgoritmus nevét, és rengeteg függvényt, amelyeket a RenderPark keretrendszere akkorhív amikor az UjRenderingAlg-ot inicializálni kell, képet kell szintetizálnia, amikor afelhasználó be szeretné állítani az UjRenderingAlg paramétereit (ilyenkor egy SetupDialogot kell megjeleníteni és a dialógus ablak megfelelõ mezõit fel kell programozni).Ezeken felül, amikor az UjRenderingAlg által elõállított képet nyomtatni kell, vagy fájlbamenteni. A függvénypointerek beállításával és a függvények megírásával renderingalgoritmusunk tökéletesen integrálódik a RenderPark keretrendszerébe: használni tudja aRenderPark belsõ globálisait, térpartícionálással támogatott sugár-háromszögmetszéspontszámítási algoritmusait, absztrakt Material osztályait a korrekt fizika alapúanyagmodellek megvalósításához stb.

70

71

5. Az ArchiCAD és más grafikus rendszerek összehasonlítása

A 3. és 4. fejezetben áttekintést nyújtottunk az ArchiCAD és más grafikus rendszerekképszintézis alrendszerének jellemzõirõl. Ebben a fejezetben rövid, összefoglaló jellegûösszehasonlításokat kívánunk mutatni, amelyeket a Graphisoft számos részlegehasználhat. A marketing részleg a jelenlegi rendszer képességeinek leírására, másrendszerekkel való összehasonlításra használhatja. Az ArchiCAD tervezõi és képszintézisalrendszerének fejlesztõi pedig a jelenlegi képességek továbbfejlesztésénél, újfunkciókról való döntésnél használhatják ezeket az információkat.

5.1. Az ArchiCAD jelenlegi képszintézis alrendszerének jellemzõi

• poligon alapú képszintézis• láthatósági és takarási problémák megoldása:

o zárt testekre triviális hátsólap eldobással (backface culling)o poligonos takarássalo szakaszos pászta módszerrel (spanning scanline)o mélységi pufferrel (z-buffer)

• nem fizikai tulajdonságokkal rendelkezõ fényforrások:o pontszerûo szpot lámpao párhuzamos fény (Nap) – pozíciószámítás fizikai alapokon nyugszik

• nem fizikai alapú anyagjellemzõk:o ambiens tényezõo diffúz visszaverõ képességo spekuláris visszaverõ képességo emittáló képességo áttetszõség

• lokális illuminációs megvilágítási modello diffúz visszaverõdés Lambert BRDF modellelo spekuláris visszaverõdés Phong BRDF modellel

• Phong- és Gouraud-árnyalás• alfa csatornát kezelõ textúra leképezés, ahol az alfa csatorna lehet:

o áttetszõség leképezés (transparency mapping)o ambiens leképezés (ambient mapping)o diffúz leképezés (diffuse mapping)o spekuláris leképezés (specular mapping)o bucka leképezés (bump mapping)

• árnyéktest (shadow body) alapú árnyékvetés• köd• VR panoráma és VR objektum kamerák• fénykép alapján kamera paraméterek állítása

72

5.2. Az ArchiCAD hiányosságai

• globális illuminációs megvilágítási modello fizikai alapú anyagok és fényforrásoko területi fényforrásoko tükrözõdõ felületeko nem éles árnyékok (soft shadows)

• láthatósági szûrések (visibility culling)

5.3. Más grafikus rendszerek jellemzõibõl leszûrt tapasztalatok

• hardveres gyorsítás• térpartíciónálás, láthatósági szûrések (visibility culling)• fizikai alapú anyagok és fényforrások• szakaszos pászta módszer és sugárkövetés kombinációjára alapuló képszintézis• a képszintézisnél és a háromdimenziós navigálásnál használható felhasználói

felület• árnyékvetés árnyéktérképekkel (shadow maps) vagy sugárkövetett árnyékokkal

(ray-traced shadows), mert az árnyéktest (shadow body) módszer lassú és sokextra memóriát igényel

• multitextúrázás• imposztorok használata• elosztott és párhuzamos képszintézis• megjeleníteni kívánt terület kiválasztása, amelyekrõl folyamatosan gyors preview

számítás (lásd Maya IPR technológiája)• hierarchikus vagy adaptív képszintézis: elõször az egyszerû részeket számoljuk ki

a képen, majd a komplexebbeket, így a végsõ kép nagy részét elég gyorsanmegkaphatjuk

5.4. A jelenlegi rendszer javítására, gyorsítására vonatkozó javaslatok

Az alábbiakban a jelenlegi rendszer javítására, gyorsítására vonatkozó szubjektívvéleményünket szeretnénk ismertetni. A javaslatokat munkaigényük és fontosságukszerint két szekcióra osztottuk: rövid- és hosszútávúakra.

73

5.4.1. Rövid távú javaslatok

• láthatósági szûrések (visibility culling): kd-, nyolcas- vagy BSP-fával• spekuláris visszaverõdés kezelésé Phong modell helyett maximum Phong

modellel• fényforrás jellemzõk átdefiniálása:

o megfelelõen általános fényforrás fogalom => felületek ne csakemittáljanak, hanem fényforrások is lehessenek (területi fényforrások)

o rövidtávon elegendõ a fizikai alapú információk konvertálása• OpenGL alapú hardveres gyorsítás javítása:

o hardveres transzformáció számításo árnyékvetés

§ mélység pufferel (z buffer)§ árnyék térképekkel (shadow map)

o fénytérképek (light map)o háromszögesítés OpenGL-lel

• sugár-háromszög metszéspontszámítás gyorsítása• multitextúrázás• imposztorok használata

5.4.2. Hosszú távú javaslatok

• globális illuminációs elvû képszintézis: mindegyik módszerhez (radiozitás,sztochasztikus iteráció, véletlen bolyongás simítással (filtering) stb.) kellenek akövetkezõk:

o fizikai alapú anyag és fényforrás könyvtári elemekként kezeléseo tükrözõdõ felületeko nem éles árnyékok (soft shadows)

• teljes körû hardveres gyorsítás• Delanuay háromszögesítés elterjesztése a "beteg" poligonhálók (mesh)

megszüntetésére• elosztott képszintézis• megjeleníteni kívánt terület kiválasztása, amelyekrõl folyamatosan gyors preview

számítás (lásd Maya IPR technológiája)• hierarchikus vagy adaptív képszintézis: elõször az egyszerû részeket számoljuk ki

a képen, majd a komplexebbeket, így a végsõ kép nagy részét elég gyorsanmegkaphatjuk

74

75

6. A globális illuminációs elvû program és az ArchiCADösszekapcsolása

Az ArchiCAD egy nyitott architektúrájú CAD rendszer. Ez azt jelenti, hogy a rendszermagja fölé különálló, de a mag szolgáltatásaira támaszkodó programokat, ún. add-onokatlehet fejleszteni. Az épülettervezés igen komplex tevékenység, ezért az eltérõrészterületek kiszolgálását különbözõ típusú add-on-ok végzik. Jelen keretek között csakaz ún. háromdimenziós I/O add-on-ok és az ún. rendering add-on-ok ismertetésévelfoglalkozunk, amelyek a globális illuminációs elvû program és az ArchiCAD közöttikommunikáció offline és online módjait végzik. Ebben a fejezetben a két alternatívaArchiCAD-specifikus megoldásait mutatjuk be.

6.1. Offline kommunikáció

Esetünkben az offline kommuniáció a következõt jelenti: az ArchiCAD-bõl bizonyosformátumú fájlt mentünk, amelyet a különálló alkalmazásként megvalósított globálisilluminációs elvû program be tud olvasni. Tehát ez a közbülsõ fájl tartalmazza azokat azadatszerkezeteket, amelyekre mindkét programnak szüksége van. A 6.1.1. pontban aztvizsgáljuk meg, hogy hogyan lehet ezt az ArchiCAD add-on rendszerében megvalósítani,a 6.1.2. pontban pedig a lehetséges fájl formátumokat mutatjuk be.

6.1.1. I/O add-on alapú megvalósítás

Azért, hogy az ArchiCAD-ben megtervezett épületmodelleket más gyártók termékeinél isalkalmazni lehessen, óriási igény merült fel a modellek különbözõ fájl formátumokbanvaló exportálására. Az ArchiCAD lehetõséget nyújt mind a kétdimenziós tervrajz, mind aháromdimenziós modell exportálására. Utóbbi kategória megvalósítására aháromdimenziós I/O add-on-ok szolgálnak.

Az ArchiCAD az épület háromdimenziós modelljét az I/O add-on-ok számára két pontontudja szolgáltatni1: a File menü Save As funkciójánál és az Image menü Create Fly-Through menüpontjánál. Az elõbbi a háromdimenziós modell lefényképezésére és / vagyszerkesztésére szolgáló 3D Window aktuális kamera beállításaival menti el a modellt. ACreate Fly-Through funkció pedig a háromdimenziós épületmodell egy bejárását jelenítimeg, illetve menti el. Az épület bejárásához az alaprajzon el kell helyezni néhányperspektív kamerát, amelyekre az ArchiCAD egy görbét illeszt. Ez a spline mutatja abejárás útvonalát; a kamerák pedig az animáció kulcskockáit (keyframe) jelentik. Aprojekt hosszú távú céljai között szerepel a kivárható idõben elkészülõ animációkkészítése is, ezért olyan I/O add-on-t írunk, amely mind a két helyrõl engedélyezi abelépést.

1 Az ArchiCAD-ban elérhetõ funkciók, menük, menüpontok neveit az angol nyelvû ArchiCAD verzióbólvettük.

76

Minden add-on tartalmaz egy ACNF nevû erõforrást (resource), amelyben az add-onjellegzetességeit lehet leírni. Ebben az erõforrásban kell megadni, hogy háromdimenziósI/O add-on-t írunk, amely támogatja az add-on elérését mind a Save As, mind a CreateFly-Through menüpontokból.

6.1.2. Fájl formátumok

Az offline megoldásoknál a legfontosabb kérdés, hogy a két alkalmazás akommunikációhoz milyen fájl formátumot használjon. Ahogy már a 4. fejezetbenkiderült, számos alkalmazás használ saját formátumot, de a többség azért 1-2 elterjedtebbformátumot is támogat. Mivel ez utóbbi lehetõség nélkülözhetetlen ahhoz, hogy olyanglobális illuminációs elvû alkalmazást készítsünk, amelyet bármely CAD rendszerhezlehet illeszteni, nem tekinthetünk el néhány elterjedt fájl formátum használatától.Ráadásul az Interneten számos olyan modell található, amelyeket ilyen elterjedt fájlformátumban (VRML, MGF, 3DS stb.) írtak le. Ezek használhatóságáról sem kívánunklemondani, hisz ezzel elõsegítjük a rendszer széles körben alkalmazhatóságát, illetve másképszintézis programokkal való összehasonlíthatóságát. Ettõl függetlenül egy „saját”formátumot is használunk azért, hogy minél jobban ki tudjuk használni az elkészülõglobális illuminációs elvû alkalmazás képességeit.

6.1.2.1. SCE formátum

A SCE formátumot néhány évvel ezelõtt a leuveni egyetemen fejlesztették ki, de aztánfeledésbe merült - köszönhetõen az elterjedtebb fájl formátumok használatának. Mivel aleuveni egyetemen számos modellt (például a klasszikusnak tekinthetõ Cornell dobozt)már leírtak ezen a nyelven, a Budapesti Mûszaki Egyetemen mûködõ grafika csoportátvette és továbbfejlesztette a fájl formátumot, amely mára egy jól használható, fizikaialapú képszintézist támogató formátummá nõtte ki magát. A grafika csoport eddigiglobális illuminációs elvû prototípusai ezt a formátumot olvasták, jellegzetességeit többé-kevésbé kihasználták, ezért a projekt keretében elkészítendõ alkalmazásnál is jogosanmerül fel a SCE támogatásának igénye.

Ahogy az már az elõzõ fejezetekbõl is kiderült, az ArchiCAD nem fizikai alapúanyagjellemzõket és fényforrás megadásokat alkalmaz. Ezért minden fizikai alapú fájlformátumnál, így a SCE-nél is, számos megkötéssel lehet csak konvertálni az empirikusjellemzõket fizikai alapúakra. Ezt a konvertálást az add-on fogja végezni.

6.1.2.2. MGF formátum

A legelterjedtebb, legismertebb globális illuminációs elvû program Greg Ward Radiancenevû alkalmazása, amelyet már az AutoCAD-be is integráltak Desktop Radiance néven.Ezt a programot a 4. fejezetben be is mutattuk. Ward a Radiance fejlesztése közben jöttrá, hogy óriási igény lenne egy egyszerû, általánosan alkalmazható, de mégis fizikaialapú anyagmegadást támogató fájl formátumra. Ezért 1994-ben kidolgozta az MGF(Material and Geometry Format) szöveges formátumot ([33]) és számos modellt írt le

77

vele. Azért, hogy a formátum minél jobban elterjedjen, számos konvertert írt: 3D Studio(3DS) formátumról MGF-re, Radiance (RAD) formátumról MGF-re oda-vissza stb.

Az MGF formátum fényforrásleíró részét az Észak-amerikai Világítással foglalkozóMérnökök Szövetsége (IESNA) az LM-63-1995 szabványba beleolvasztotta. Ez továbbnövelheti a formátum elterjedtségét, amely már ma is igen jelentõs.

A formátum elterjedtsége, széles körben alkalmazhatósága miatt a projekt keretébenlétrejövõ alkalmazásnak mindenképpen ismernie kell az MGF-et. Ez a Graphisoftszámára azért is hasznos lesz, hisz így egy MGF formátumot exportáló add-on-hoz is jut,amelyet beépíthet ArchiCAD nevû programjába, és ezzel rövidtávon megoldást tudnyújtani a fizikai alapú képszintézist igénylõ felhasználóinak. Természetesen itt is az add-on fogja az empirikus jellemzõket fizikai alapúra konvertálni és vissza.

6.1.2.3. VRML formátum

A ‘90-es évek közepén az Internet robbanásszerû elterjedésének köszönhetõen hamarigény mutatkozott egy olyan formátum létrehozására, amely böngészõben nézhetõháromdimenziós modelleket ír le. Ezért jelent meg a VRML 1.0-s verziója, amely mégerõteljesen támaszkodott az OpenInventorra. A 2.0-s verzió egy teljesen megújultformátumot jelentett: lényegében újradefiniálták a leíró nyelvet. Késõbb 1-2 apróbbmódosítással VRML97 néven szabványosították ([34]). A mai VRML böngészõkmindegyike támogatja a VRML2 / VRML97 formátumokat, de csak kevés kompatíbilisaz 1.0-s verzióval.

A Graphisoft épületmodelljeinek Interneten való publikálásához és a szépszámú virtuálisvalóság kutatás miatt még 1997-ben beépítette a VRML exportálás lehetõségét azArchiCAD-be. A formátum mind a mai napig óriási népszerûségnek örvend, ezért a hálónrengeteg VRML modell található. Az ArchiCAD-bõl menthetõ VRML épületmodellek ésa hálóról tölthetõ objektumok használatának támogatása elõsegíti a készítendõ globálisilluminációs elvû alkalmazás kapcsán kitûzött „általánosan használható” célunkat, ezért aprogramnak szabványos VRML97 fájlokat is kell olvasnia.

A 4. fejezetben bemutatott, kutatási projekt keretében készült RenderPark globálisilluminációs programcsomag nemcsak a szabványos VRML97 fájlokat tudja olvasni,hanem a leuveni egyetemen dolgozó Philippe Bekeart által kibõvített, fizikai alapúanyagmegadásokat támogató VRML fájlokat is. Ezeket a típusú fájlokat nem kívánjukolvasni, hisz a formátum – sajnos - nem terjedt el.

6.1.2.4. 3DS formátum

A '90-es évek elején jelent meg az Autodesk a 3D Studio nevû DOS-os programjával,amelynek célja az alsó kategóriás gépeken (tehát nem SGI és más munkaállomásokon)futó, de elfogadható sebességû és képminõségû animációs és képszintézisprogramcsomagok között az élre törés volt. Bár ez nem teljes mértékben sikerült, aprogram elég népszerûvé vált és számos program kezdte importálni, illetve exportálni az

78

adatokat 3DS ([35]) formátumban. 1995-ben az Autodesk a Kinetix leánycégévelalapjaiban újraíratta a 3D Studiot Windows platformra. Ez lett a 3D Studio MAX,amelyrõl már a 4. fejezetben részletesen szóltunk. A MAX hihetetlenül sikeres lett adesktop kategóriájú számítógépek között, ezért elengedhetetlen követelmény lett a MAX-szal való offline kommunikáció tartás. Mivel a MAX saját formátuma nem publikus,ezért a többi program továbbra is a 3DS formátumon keresztül tud kommunikálni a 3DStudioval.

A formátum elterjedtsége miatt a Graphisoft ArchiCAD programjába is beépítette azexportálás lehetõségét. Mára az ArchiCAD felhasználóinak széles tábora használja ezt aformátumot, amelyet jól mutatnak a gyakori továbbfejlesztési ötletek, igények. Ezekközül az egyik legfontosabb a 3DS fájlok importálásának megoldása. A projekt keretébena globális illuminációs elvû programhoz kidolgozott 3DS fájl importáló modult úgykívánjuk elkészíteni, hogy a késõbbiekben minimális munkával az ArchiCAD-hez isilleszteni lehessen.

A 3DS formátum sem fizikai alapú, ezért a VRML-hez hasonló megoldásokat kellalkalmazni, azaz a globális illuminációs elvû programnak kell az empirikus adatokatfizikai alapú jellemzõkké konvertálnia.

6.1.2.5. XML

Az Extensible Markup Language (XML) a Standard Generalization Markup Language(SGML) egy olyan részhalmaza, amelyet a World Wide Web-en (WWW) (Interneten aHTTP (HyperText Transfer Protocol) prokollon keresztül) történõ továbbításraoptimalizáltak. Az SGML-t (ISO8849) körülbelül 30 évvel ezelõtt definiálták szövegesinformációk markup nyelvvel történõ reprezentálására. Az XML SGML-bõl csak azokata részeket vette át, amelyek a Web-alapú felhasználáshoz illeszkednek, ennekköszönhetõen az XML sokkal kisebb és egyszerûbb lett, mint maga az SGML. Az XMLegyszerûségét és használhatóságát jellemzi az arány, miszerint: az XML komplexitásában20%-a, míg funkcionalitásában 80%-a az SGML-nek. Itt kell megjegyeznünk, hogy aHyperText Markup Language (HTML) nyelv is az SGML nyelvbõl származik, ahol másrendezõelv szerint választották ki a részhalmazba bekerülõ elemeket, mint az XMLesetében.

Az XML nyelv szabványosításán a World Wide Web Consortium (W3C) dolgozik, ezegy szoftvergyártóktól független szervezet, amely 1994-es alapítása óta a Web-hezkötödõ szabványok és ajánlások megalkotásával foglalkozik. Az XML nyelv jelenleg 1.0-s verzióval rendelkezik.

Az XML alapvetõen egy olyen meta-markup nyelv, amely formátumot definiálstruktúrált adatok leírására. Ez a formátum lehetõvé teszi az adatok részeit képzõinformációtartalom precíz deklarációját, ebbõl adódóan minden eddiginél hatékonyabb ésértelmesebb visszakeresést tesz lehetõvé platform független módon.

79

Az XML nyelv és a HTML nyelv kiegészítik egymást, ugyanis az XML egy egységesítettmódszert nyújt struktúrált adatok cseréjére és terjesztésére az Interneten (HTTPprotokoll) keresztül, míg a HTML ideális az ilyen módon terjesztett információmegjelenítésére. Ennek az oka az, hogy az XML adatleíró nyelv, míg a HTML egyreprezentáció (megjelenítés) leíró nyelv. Strukturált adatok nyílt, szöveges formátumúleírására és HTTP alapon történõ továbbítására két fõ okból van szükség: egyrészt azInterneten fellelhetõ dokumentumok tartalmának precíz deklarációja elõsegíti azinformáció értelmesebb alapokra helyezett keresését (a HTML alapú keresõmotorok általelõállított találati eredményeknél sokkal jobb keresési eredmények produkálhatók azinformációtartalom precíz deklarációja miatt). Másrészt, ha a keresett információ márhelyileg behatárolt, akkor az egységes formátum miatt eddig csak nehezen megoldhatómûveletek is elvégezhetõk az adatokon, illetve speciális megjelenítések is eszközölhetõk(például. adatok rendezése, szûrése, csoportosítása stb.).

A HTML és az XML nyelv nagyon hasonlít egymásra, ugyanis mindegyik tag-ekethasznál a vezérlõ instrukciók szöveges információfolyamba történõ beszúrására. A kétnyelvben használt tag-ek feladata azonban már eltér: a HTML-ben használt tag-ek adokumentumban tárolt szöveges információ megjelenítését vezérlik (pl. egy szó,bekezdés milyen betûtípussal jelenjen meg, a szavak dõlt- vagy vastag betûsek legyenekstb.); az XML-ben használt tag-ek pedig az önmaguk által reprezentált információtdeklarálják (például kiskereskedelmi ár, nagykereskedelmi ár, fogyasztási adó,hõmérséklet stb.). A két nyelv tag-jei abban is eltérnek egymástól, hogy míg a HTMLegy rögzített tag-készletet használ, addig az XML-ben miden felhasználó vagyalkalmazásfejlesztõ saját tag-készletet alakíthat ki az adatok minél precízebb leírásavégett

Az XML hatalmas ütemû terjedésének köszönhetõen már a Graphisoft is használja azXML formátumot. Ezen felül jelenleg nem létezik olyan séma definíció, amely globálisilluminációs elvû képszintézis program input adatainak leírásaként szolgálna. Ezenindokokból kifolyólag jogosan merült fel az igény, hogy a projekt keretében definiáljunkilyen sémákat. Úgy érezzük, hogy ez a feladat a projekt keretein túlmutat, hisz a sémákatúgy kellene definiálni, hogy nemcsak CAD rendszerekhez illeszthetõ globálisilluminációs elvû programoknál lehessen alkalmazni õket, hanem akár böngészõben futó,fizikai alapú anyag- és fényforrásmegadást támogató alkalmazásnál is. Például képzeljükel, hogy a lámpagyártók honlapjaikon is árulni kívánják lámpáikat, amelyek adatait ezenXML sémákkal adják meg. Ehhez megfelelõen általános leírást kell megadni. Ráadásulaz elterjesztéséhez is komoly erõforrásokra lenne szükség. Ezért a projekt keretein belülezzel a területtel nem foglalkozunk, de a téma fontossága, aktualitása miatt nemkerülhetjük ki annak további kutatását.

80

6.2. Online kommunikáció

Esetünkben az online kommunikáció a következõt jelenti: az ArchiCAD Imagemenüjének PhotoRendering Settings funkciójánál kiválaszthatóvá válik a projektkeretében létrejövõ globális illuminációs elvû képszintézis add-on. Ezután ha az Imagemenü PhotoRendering Projection funkcióját választjuk, vagy a Create Fly-Throughdialógus ablakában renderelt képet kérünk, illetve ha VR panoráma kiírást kívánunk,akkor ez az add-on készít képet. Tehát a projektben létrejövõ prototípus az ArchiCAD-del összeintegrálódik. Ahhoz, hogy ez az integráció megtörténhessen, egy ún. renderingadd-on-t kell készíteni.

6.2.1. Rendering add-on

A többi add-on típushoz hasonlóan a rendering add-on-ok is rendelkeznek egy sajátinterfésszel, amelyen keresztül kommunikálnak az ArchiCAD-del. Az interfész egyszerû,jól definiált, így ezen keresztül az ArchiCAD adatszerkezeteinek közvetlen lekérdezéseés egy saját belsõ szerkezet felépítése nem jelent problémát. Ha a különálló globálisilluminációs alkalmazás modellbeolvasó modulját erre a konvertáló modulra cseréljük,akkor ezzel az integráció kérdésköre interfész szinten megoldódott.

Az integráció további feladataihoz a felhasználói felületi elemek tartoznak. Ezekmegoldásáról részletesebben a következõ fejezetben szólunk.

81

7. A globális illuminációs elvû program felhasználói felülete

A projekt keretében egy önálló és egy integrált globális illuminációs elvû prototípustkészítünk el. Az elõzõ fejezetben összefoglaltuk azokat az interfész követelményeket,amelyek biztosítják, hogy számos CAD rendszerhez illeszthetõ alkalmazást készítsünk.Ebben a fejezetben programok kezelõi felületével kapcsolatban szeretnénk néhánykövetelményt meghatározni. Bár a két prototípus képszintézis alrendszere meg fogegyezni, a kezelõ felületi jellemzõik és logikájuk eltérõek lesznek, ezért a kétprogrammal kapcsolatos követelményeinket külön-külön fogalmazzuk meg.

7.1. Az önálló globális illuminációs elvû program

A legtöbb képszintézis alrendszerrel bíró alkalmazás rendelkezik a színtér interaktívbejárására használható funkcióval. A színtér geometriáján felül kamerák beállítására ishasználható szolgáltatást az önálló globális illuminációs elvû programbanalapkövetelménynek tekintjük.

7.1.1. Bejárás, kamera elhelyezése

A bejárás során kamerákat helyezhetünk el a színtérben és a már letettek közöttválthatunk. Természetesen, lesz lehetõség a kameraadatok perzisztenssé tételére, azaz kilehet menteni, be lehet tölteni õket.

Az interaktív megjelenítés felületi elemei között kiemelkedõ fontosságúak a mozgáshozszükséges funkciók. A 4. fejezetben bemutatott grafikus programok és néhány VRMLböngészõ használata után az alábbi tapasztalatokat gyûjtöttük össze:

• három jellemzõ mozgáscsoport:o nagyítás / kicsinyítés: a kamera nézési irányában elõre-hátrahaladáso forgatás:

§ a képernyõn síkjának forgatása az aktuális kamerapozíció körül§ a színtér forgatása a középpontja körül

o sraffolás: a kamera képernyõjének síkjában való mozgás• fontos a lépésköz és a forgásszög állítási lehetõsége• nehezen kezelhetõ a "fejemet felemelem, de továbbra is vízszintesen megyek

elõre" típusú mozgás2; ilyenkor mindenképpen szükség van egy "fejet egyenesbehozó" funkcióra

• hasznos lehetõség egy színtér több kamera használhatósága• a felülnézeti ábra (térkép) hasznos, mert jelentõsen felgyorsítja a színtér

áttekintését

2 Megjegyezzük, hogy vannak esetek amikor hasznos ez a funkció. Gondoljunk például a lépcsõn valóközlekedésre.

82

• a mozgás és a kamera pozíciójának meghatározását jelentõsen gyorsítja a térképenvaló elhelyezés lehetõsége

• a "menj arra a pontra, ahova mutatok" funkció szintén nagyon hasznos, hiszjelentõsen felgyorsítja a mozgás definiálásának a folyamatát

Ezen tapasztalatok alapján a következõ követelményeket tûztük ki az önálló program elé:

• több kamera kezelése• mindhárom mozgáscsoport megvalósítása - mindkét típusú forgatással együtt

A mozgáscsoportok kiválaszthatók és használhatók lesznek menüpontokból,eszközsávról. Lehetõség lesz mind billentyûzettel, mind egérrel való mozgásra.

7.1.2. Véges elemes felbontás paramétereinek beállítása

A globális illuminációs elvû prototípusok alapját a sztochasztikus iteráción alapulósugárköteg módszer jelenti. Az iterációs módszerek megkövetelik a színtér véges elemesfelbontását. A felhasználónak biztosítani kell a lehetõséget, hogy a poligonháló (mesh)elõállítására vonatkozó paramétereket dialógus ablakból állíthassa.

A felhasználónak tudnia kell állítani a tesszelációs módszert és az ahhoz tartozóparamétereket. Például ha a felhasználó azt a módszer választja, hogy egy háromszögetúgy vág félbe, hogy a leghosszabb oldal felezõpontját összeköti az oldallal szemközticsúccsal, akkor a kezelõi felületrõl kell tudnia állítani azt az oldalhosszt, amelyet azalgoritmus már nem vág félbe.

7.2. Az integrált globális illuminációs elvû program

Ebben az alfejezetben a 7.1. pont alatt felsorolt követelmények ArchiCAD-be valóintegrációját vizsgáljuk meg.

7.2.1. Bejárás, kamera elhelyezése

A ArchiCAD egy kissé nehézkesen használható navigációs eszközt nyújt a színtérinteraktív bejárására, az építészeti elemek módosítására. Ettõl függetlenül az integráltmegoldásnál a bejárás problémájával nem foglalkozunk, hanem az ArchiCAD és a "3DWindow" lehetõségeire támaszkodunk.

7.2.2. Véges elemes felbontás paramétereinek beállítása

Itt is ugyanaz mondható el, mint a 7.1.2. pontban.

83

Irodalomjegyzék

[1] G. Krammer: Bevezetés a számítógépi grafikába. Jegyzet, ELTE 1999.http://valerie.inf.elte.hu/~krammer/eltettk/grafika/jegyzet/index.html

[2] J. D. Foley, A. van Dam, S. K. Feiner, J. F. Hughes, R. L. Philips:Computer Graphics: Principles and Practice, Second Edition In CAddison-Wesley Pub Co, 1992

[3] C. M. Goral, K.E. Torrance, D. P. Greenberg, B. Battaile:Modelling the interaction of light between diffuse surfacesComputer Graphics (SIGGRAPH '84 Proceedings), 213-222. oldal, 1984.

[4] GLX, GLU and Direct Rendering Infrastructure (DRI)http://www.opengl.org/developers/documentation/glx.html

[5] A. Watt: 3D Computer Graphics (3rd Edition)Addison-Wesley Pub Co., 2000

[6] L. Szirmay-Kalos: Számítógépes grafikaComputerBooks, 1999.

[7] V. Havran: Heuristic Ray Shooting AlgorithmsPhD Thesis, Fac. of Electrical Engineering, Czeh TU, Prague, 2001.

[8] E. Catmull: Computer display of curved surfaces.Proc. IEEE Conf. on Computer Graphics, Pattern Recognition and DataStructures, 1975

[9] T. Theoharis, G. Papapioannou, E-A. Karabassi:The Magic of The Z-Buffer: A Survey.Winter School of Computer Graphics '01, 379-386. oldal, 2001.

[10] B. T. Phong: Illumination for computer generated images.Communications of the ACM, 18: 311-317. oldal, 1975.

[11] L. Neumann, A. Neumann, L. Szirmay-Kalos:Compact metallic reflectance modelsComputer Graphics Forum (Eurographics '99), 18(3): 161-172. oldal, 1999.

[12] H. Gouraud: Illumination for computer generated pictures.Communications of the ACM, 18 (60): 311-317. oldal, 1971.

[13] R. Cook: ShadetreesComputer Graphics (SIGGRAPH '84), 223-231. oldal, 1984.

84

[14] L. Williams: Casting curved shadows on curved surfaces.Computer Graphics, 12 (3): 270-274. oldal, 1978.

[15] W. T. Reeves, D. H. Salesin, R. L. Cook:Rendering antialiased shadows with depth mapsComputer Graphics (SIGGRAPH '87), 283-91. oldal, 1987.

[16] M. Segal, C. Korobkin, R. van Widenfelt, J. Foran, P. E. Haeberli:Fast shadows and lighting effects using texture mappingComputer Graphics (SIGGRAPH '92), 249-252. oldal, 1992

[17] N. Greene, M. Kass, G. Miller: Hierarchical Z-Buffer visibilityComputer Graphics (SIGGRAPH '93), 231-238. oldal, 1993.

[18] T. Whitted: An Improved Illumination Model for Shaded DisplayCommunications of the ACM, 23: 343-349. oldal, 1980.

[19] R. Cook, T. Porter, L. Carpenter: Distributed Ray TracingComputer Graphics (SIGGRAPH '84), 137-145. oldal, 1984.

[20] J. T. Kajiya: The Rendering EquationComputer Graphics (SIGGRAPH '86), 143-150. oldal, 1986.

[21] ArchiCAD hivatalos honlapjahttp://www.graphisoft.com/products/architecture_and_design/

[22] 3D Studio MAX hivatalos honlapjahttp://www2.discreet.com/products/d_products.html?prod=3dsmax

[23] mental ray hivatalos honlapjahttp://www.mentalimages.com/p101.html

[24] Maya hivatalos honlapjahttp://www.aliaswavefront.com/en/WhatWeDo/maya/index.shtml

[25] Lightflow Rendering Tools hivatalos honlapjahttp://www.lightflowtech.com

[26] AutoCAD hivatalos honlapjahttp://www3.autodesk.com/adsk/section/0,,284288-123112,00.html

[27] Radiance hivatalos honlapjahttp://radsite.lbl.gov/radiance/HOME.html

85

[28] Desktop Radiance hivatalos honlapjahttp://radsite.lbl.gov/deskrad/dradHOME.html

[29] trueSpace hivatalos honlapjahttp://www.caligari.com/products/truespace/ts5/

[30] Lightscape hivatalos honlapjahttp://www.lightscape.com/

[31] Artlantis hivatalos honlapjahttp://www.artlantis.com/

[32] RenderPark hivatalos honlapjahttp://www.cs.kuleuven.ac.be/cwis/research/graphics/RENDERPARK/

[33] MGF formátum hivatalos honlapjahttp://radsite.lbl.gov/mgf/

[34] VRML formátum hivatalos honlapjahttp://www.vrml.org/technicalinfo/specifications/specifications.htm

[35] 3DS formátum specifikációja3D Studio Release 3 File Toolkit, Reference ManualAutodesk Inc., 1994.