Gépészet | CAD / CAM » Fotorealisztikus képszintézis CAD rendszerekben

IKTA-KÉPI 00101/2000 projekt Szerzõdés számok: OMFB-00179/2001, OMFB-00190/2001 Fotorealisztikus képszintézis CAD rendszerekben FELHASZNÁLÓI ÉS INTERFÉSZ KÖVETELMÉNYEK 1.1 verzió: 20010519 ÍRTA: Csonka Ferenc Antal György dr. Sparing László Kelemen Csaba Kovács László Polyák Tamás Palotás Csaba ELLENÕRIZTE: dr. Szirmay-Kalos László dr. Horváth Tamás Tartalomjegyzék 1. Bevezetõ 1 2. Képszintézis igények építészeti CAD rendszerekben5 2.1 Mûveleti megjelenítés5 2.2 Prezentációs megjelenítés 6 2.3 Világítás- és színtervezés7 2.4 Fizikai alapú anyagjellemzõk9 2.5 Fizikai alapú fényforrások9 2.6 Cache-lés 10 3. Az ArchiCAD inkrementális képszintézise13 3.1 Az ArchiCAD jelenlegi jellemzõi13 3.11 Transzformációk13 3.12 Tárgydekompozíció és elhelyezés a virtuális világban13 3.121 Felhasználói oldal14 3.122 Reprezentáció14 3.13 Elhelyezés a kamera koordináta-rendszerben14 3.14 Térbeli vágás14 3.15 Láthatósági

és takarási problémák megoldása 15 3.151 Pásztalapú megoldás 15 3.152 Mélységi puffer alapú megoldás16 3.16 Árnyalás 17 3.161 Fényforrások17 3.162 Anyagjellemzõk 17 3.163 Megvilágítási modell18 3.164 Textúrakezelés18 3.17 Effektek 19 3.171 Árnyék19 3.172 Köd19 3.18 Színleképezés20 3.19 Elõzetes képeken alapuló szintézis 20 3.191 QuickTime VR20 3.192 Fotogrammetriai képességek21 3.110 Igények22 3.2 A tudományos élet kapcsolódó eredményei22 3.21 Árnyékvetés23 3.211 Sugárkövetett árnyékok23 3.212 Mélységi puffer alapú árnyékvetés 23 3.213 Árnyéktérkép24 3.22 A mélységi puffer gyorsítása25 I 3.23 Sugárkövetés gyorsítása mélységi pufferrel25 3.3 Hardveresen gyorsított háromdimenziós megjelenítés 25 3.31 A mai videókártyák képességei26 3.32 A statikus megvilágítási modell gyorsítása26 3.33 A dinamikus megvilágítási modell gyorsítása 27 3.34 Hardveres transzformáció és megvilágítás27 3.35

Mélységi puffer gyorsítási módszerek 27 3.351 Az ATI HyperZ módszere28 3.352 A tile-based deferred rendering28 4. További grafikus rendszerek bemutatása31 4.1 Integrált, modellezõ alrendszerrel rendelkezõ programok31 4.11 3D Studio MAX32 4.111 Anyag- és fényforrásjellemzõk 32 4.112 Kezelt fájl formátumok 32 4.113 Plugin renderer interfész34 4.114 mental ray34 4.12 Maya 36 4.121 Anyag- és fényforrásjellemzõk 37 4.122 Kezelt fájl formátumok 40 4.123 Rendering plugin41 4.124 Lightflow Rendering Tools 41 4.13 Desktop Radiance43 4.131 Radiance43 4.132 AutoCAD 44 4.133 Kezelt fájl formátumok 44 4.144 Desktop Radiance45 4.135 Könyvtári elemek 46 4.14 trueSpace 48 4.15 ArchitechPC 49 4.151 A kezdetek49 4.152 Az új képszintézis alrendszer 50 4.153 A második verzió 51 4.154 A harmadik verzió52 4.155 A negyedik verzió 53 4.156 Jövõbeli tervek, prototípusok 54 4.2 Csak képszintézis alrendszerrel rendelkezõ programok56 4.21 Lightscape 57 4.211 Könyvtári

elemek 57 4.212 Kezelt fájl formátumok 58 4.213 Globális illuminációs megoldása 59 4.22 Artlantis60 4.221 Egyszerû felhasználói felület 61 4.222 Anyag- és fényforrásjellemzõk 62 II 4.223 Kezelt fájl formátumok 64 4.224 Globális illuminációs megoldása 64 4.23 RenderPark66 4.231 Beépített algoritmusok 67 4.232 A RenderPark további jellemzõi67 4.233 Ú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õi71 5.2 Az ArchiCAD hiányosságai72 5.3 Más grafikus rendszerek jellemzõibõl leszûrt tapasztalatok72 5.4 A jelenlegi rendszer javítására, gyorsítására vonatkozó javaslatok 72 5.41 Rövid távú javaslatok73 5.42 Hosszú távú javaslatok73 6. A globális illuminációs elvû program és az ArchiCAD összekapcsolása75 6.1 Offline kommunikáció 75 6.11 I/O add-on alapú megvalósítás75 6.12 Fájl formátumok76 6.121 SCE formátum76 6.122

MGF formátum76 6.123 VRML formátum77 6.124 3DS formátum77 6.125 XML78 6.2 Online kommunikáció80 6.21 Rendering add-on80 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û program81 7.11 Bejárás, kamera elhelyezése81 7.12 Véges elemes felbontás paramétereinek beállítása 82 7.2 Az integrált, globális illuminációs elvû program82 7.21 Bejárás, kamera elhelyezése82 7.22 Véges elemes felbontás paramétereinek beállítása 82 Irodalomjegyzék.83 III 1. Bevezetõ A számítógépi grafika és ezen belül a képszintézis alapvetõ célkitûzése, hogy a számítógépben tárolt virtuális modellt lefényképezze és a felhasználóban a valóság szemlélésének illúzióját keltse. Az alábbi ábrán balra a virtuális modell, jobbra pedig a modellrõ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 a monitor pixeleinek megfelelõ térszögbõl milyen spektrális eloszlás és spektrumonként mekkora fényintenzitás érkezne a megfigyelõ szemébe. Azonosítani kell tehát a pixelben látható felületi pontokat és azok szem irányú sugársûrûségét (radiancia). A sugá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 csak nagyon speciális eljárásokkal és a fizikai modell durva egyszerûsítésének árán kaphatunk elfogadható sebességgel képeket. Ezek az egyszerûsítések az integrál operátoron belüli ismeretlen 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ást veszik figyelembe, a más felületekrõl visszavert indirekt megvilágítást nem. Mivel ekkor a pont színe a fényforrásokon kívül csak a lokális anyagjellemzõktõl és geometriától függ, a módszerek közös neve lokális illuminációs modellek. A durva elhanyagolások miatt a lokális illuminációs módszerekkel létrehozott képek, legyenek azok bármilyen szé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 az alkalmazá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 1 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 ezen

módszereket globális illuminációs modellként ismeri a szakirodalom. Az 12 ábrán két loká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ális illuminációs elvû képszintézis program elkészítése. A CAD rendszerek és a globális illuminációs program közötti kapcsolat megvalósítására két alternatívát dolgozunk ki. Az egyik alternatíva az offline megoldás, amely azt jelenti, hogy a két alkalmazás egy 2 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 az eredeti feladat leszûkítését, mert mindvégig olyan megoldásokra törekszünk, amelyeket más CAD rendszereknél is alkalmazni lehet. Éppen ezért e dokumentum egyik fõ célja azon megoldások összegyûjtése, rendszerezése, amelyek használatával más CAD rendszerekhez is készíthetõ globális illuminációs alkalmazás, illetve a projekt keretében elké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 online megoldásairól. Természetesen, ezeknél a rendszereknél a felhasználói felületi jellemzõket is megvizsgáljuk, hisz ezek figyelembevételével készíthetünk csak tényleg általánosan használható globális illuminációs elvû alkalmazást. A dokumentum másik célterülete a CAD rendszer

jelenlegi képszintézis alrendszerének feltárása. Megvizsgáljuk, hogy a jelenleg alkalmazott módszerek, algoritmusok és elvek milyen mértékben alkalmazzák a tudományos eredményeket, mennyire vannak lemaradva napjaink tudományos élvonalától. Az elemzés egyrészt a Graphisoftnak rálátást ad CAD rendszere naprakészségérõl, amely jó alap lehet más CAD rendszerekkel való ö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. A feltá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ások felhasználásával az elkészítendõ alkalmazás felhasználói és interfész követelményeit adjuk meg. 3 4 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ézis algoritmusokat lehet kommerciális alkalmazásokban, különös tekintettel építészeti CAD rendszerekben használni. Ezért ebben a fejezetben azokat a problémákat kívánjuk bemutatni, amelyeket a globális illuminációs képszintézis felvet. Ezen problémák megfogalmazásához áttekintjük, hogy a mai építészeti CAD rendszerekben mely feladatokra milyen képszintézis igények merülnek fel. A fejezet végén bemutatunk egy olyan módszert, amely azt mutatja, hogy milyen tipikus problémák merülhetnek fel szimulá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õbe az interaktív mûveletek, míg a másodikba a prezentációs célú alkalmazások tartoznak. A harmadik kategóriába azok a feladatok tartoznak, amelyek - egyelõre még - nem elterjedtek, 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 igen mû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 a felismerésre épül, hogy ha a kétdimenziós alaprajzi tervezés még nem is sokkal hatékonyabb, mint a hagyományos rajzasztali megoldás, a bevitt geometriai adatokból mé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 a kezdetekkor is igény merült fel a vonaltakart képekre, sõt, a kitöltöttekre is. Utóbbiakat színezett vagy árnyalt képeknek is hívhatjuk. Ezek hagyományosan a számítógépes korszak elõtt is - szükség szerint - a tervi dokumentáció részét képezték. A CAD alkalmazások kezdetén az árnyalt képek elõállítása még nem tartozott az

interaktív szolgá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 is szerepelhetnek a tervezési folyamat mûveleteiben, a grafikus szerkesztésekben. A teljesítményrobbanás ellenére mégis azt gondoljuk, hogy ezen a területen igazán nagy problé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ása a tervezõ rendszerbe, amely igen munkaigényes. Vagyis a mûveleti megjelenítés kategóriájában fõleg programszerkezeti problémákkal találkozunk. Az objektum technológia használatával elérhetjük, hogy ezek az eszközök újrafelhasználhatóak és viszonylag 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 5 alkalmazásának - a számítástechnikában rangot jelentõ - több mint egy évtizedes múltja van, 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 geometria határozza meg az elvárásokat, ezért az igazán bevált megoldások a legegyszerûbb, nem valószerû megjelenítési módszerek. Noha az OpenGL igen nagy teljesítményével már kifinomultabb képi hatásokat is produkálhatunk, a tervezés nagy része mégis a szerkezetre 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 a háromdimenziós képeken nemcsak szemlélõdniük, hanem tervezniük, szerkeszteniük is kell. Az OpenGL

szerencsés példáját mutatja annak, hogy a két, eredetileg távoli megjelenítés mód, vagyis a 2D és 3D mennyire közös nevezõre hozható azzal az elfogadható pazarlással, amely a grafikus gyorsító rendszerben végbemegy, amikor a ké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 feladatok esetén a geometria egyszerû bemutatása ma már nem elegendõek. Szükség van a valóságos látványt közelítõ, de azért kellemesen nagystílû fényhatásokra, amelyeknek vé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, ha prospektusaiban 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 a mö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 a felhasználó elõre megkapja épületének külsõ-belsõ látványát, sétálgathat benne, körül repkedheti 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 a háromdimenziós számítógépi grafika legjövedelmezõbb felhasználása éppen az "olyan mintha" hatás, amelynek "varázslásához" az egzakt szimulációs gondolkodás számára meglepõen "gátlástalan" megoldásokhoz is folyamodnak. Rengeteg "fizikailag" pontatlan

vagy egyenesen értelmezhetetlen attribútummal látják el a geometriai modellt és a ké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 a visszavert fény megháromszorozódik a beérkezõhöz képest. Ehhez persze szükséges az is, hogy kellõ jártasággal rendelkezzünk egy meglehetõsen bonyolult párbeszédablak paraméterezésének kezelésében. Egy építésznek szerencsésebb volna, ha kapna valami 6 egyszerûbbet (az integráltság elõnyével kiegészítve), amely képes arra, hogy a tervezésben használt elemekhez eleve megfelelõ attribútumok kapcsolódjanak és ezek utá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 egy animációra napokat várni, egy tökéletes nagyfelbontású képre órákat. Ráadásul a

"hadd dolgozzon 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õ legkevesebb munkát igényelje és biztosítva legyen ezek "könyvtárazása". Fontos, hogy ezekkel az attribútumokkal az "újrafelhasználható" építészeti és berendezési modellelemek megfelelõen felruházhatók legyenek. Ekkor zökkenõmentesen biztosítható, hogy a terv mó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ú algoritmust használunk, de az OpenGL-lel csak igen sok bonyodalom árán tudunk az alapszolgá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ûen

elérhetünk. Ezért e területen a sugárkövetés (ray-tracing) módszere komoly tényezõnek szá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ív sugárkövetése az ideális tükrözõdés irányában továbbkövette a szembõl kibocsátott fé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 mikrotulajdonsá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 a modell nem mozog, általában mozgó alkatrészei, elmozduló

fényforrásai sincsenek, csak a nézõpont vándorol. Emiatt a radiozitás (radiosity) ([3]) eljárás felhasználása, amely szintén klasszikus a maga nemében, csábító lehetõség. Bár egyszerûsége miatt csak a fényt szóró diffúz esetre szól, ez a kompromisszum azzal az elõnnyel jár, hogy az OpenGL 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ász céljaival, már mérnökit és tudományost jelent - a fény és a tagolt tér kölcsönhatásának modellezését tekintve. 7 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 rengeteg módszert dolgoztak ki, de igazándiból egyik sem oldja meg az eredeti problémát, csak approximált megoldásokat képesek

nyújtani. Felmerülhet a kérdés, hogy ennek mi köze a vilá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 valamilyen séma szerint saccolja meg fûtõtestek teljesítményét és helyét. Ezek után még erõteljesebben felmerül a kérdés: a világítástervezéshez miért nem elegendõek a bevált mó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 - valami lé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át valóságot generálni. Ezt virtuálisnak is szokták nevezni Ez az alapvetõ tulajdonság erõsödik a tervezõ rendszerekben, illetve az

az igény, hogy a virtuális valóság minél jobban hasonlítson a valódira. Ezért egyre mûveletigényesebb és kifinomultabb algoritmusok jelennek meg. Másképpen fogalmazva, arra kell törekednünk, hogy a tervezõ ne egy elvonatkoztatáson dolgozzon, hanem a számítástechnikát, mint megvaló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ól várhatjuk. Ehhez "csak" megfelelõ algoritmust kell találnunk Ezen felül fizikailag meghatározott karakterû fényforrások, fénnyel kölcsönhatásba lépõ felületek és közegek pontos, kimért adatsorát kell biztosítanunk. Az algoritmus feladata az, hogy ebbõl az adathalmazból elõállítsa azt a képet, amelyet a virtuális kamerában kapnánk. Sajnos, ez a feladat tisztán elméletileg nem is algoritmizálható. Ez némi magyarázatot ad arra, miért van ezen a területen ennyi

megoldás kisebb-nagyobb hibákkal és egyáltalán, miért olyan nem 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 az volna, hogy ezeket már maguk a gyártók elektronikus formában, sõt a program nyilvános adatszerkezeté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ül helyesen 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és alapjá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, amelyeket egy kis pontatlanság is eltorzíthat, meghamisíthat. 8 2.4 Fizikai alapú anyagjellemzõk Már a prezentációs szinten megfogalmaztuk, hogy szükség lenne a mai anyagmodellekhez viszonyítva az anyagjellemzõk egyszerûbb leírására. Ahhoz, hogy ez a megadási módszer elterjedtté váljon könyvtárak kialakítására van szükség. A kö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 ilyen kö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, hisz egyrészt ez a világítás- és színtervezésnél alapkövetelmény. Másrészt, a gyártók fizikailag korrekt attribútumokkal termékkatalógusaikat könnyen

létrehozhatják, nem kell hó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 ez lehetõ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ós vilá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ározott karakterû fényforrások használatára. Természetesen, ez nem jelenti azt, hogy az elsõ két kategóriába sorolt feladatoknál fizikai alapú fényforrások nem alkalmazhatóak.

Azonban ezeken 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 is példaként felhoztunk. Ezeket azzal egészítenénk ki, hogy a fizikailag meghatározott karakterû fényforrások publikálására, könyvtárakba szervezésére a lámpagyártók oldaláról már régóta igen komoly igény mutatkozik. Mielõtt összefoglalnánk azokat a jellemzõ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 platina dermedési hõmérsékletén (2042,5K) és 101325 Pa nyomáson. Megjegyezzük, hogy ez kb. egy viaszgyertya fényerõsségét jelenti 9 A

fényáram SI mértékegysége a lumen (jele: lm). 1 lumen fényáram azt jelenti, hogy adott 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õ alatt 1 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 nem foglalkozunk) 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 és egyenletes 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õl beszélünk. 2.6 Cachelés A szimulációs eljárások az építészeti CAD rendszerekben kisebbségben vannak a szerkesztõ funkciókkal és más interaktív szolgáltatásokkal szemben, amelyek már az elõzõ évtizedben is - csekély számításigényük miatt - szemvillanásnyi futási idõt igényeltek. Viszont az igényes számítógépes grafika a körülményes módszerekrõl sem mondhat le, amelyek a fejlesztõ és a gép számára is egyaránt próbára tevõk. Ezekben és a kapcsolódó szolgáltatásokban jócskán szerepelnek olyan részfeladatok, amelyeknek eredményét hagyományosan fájlokba mentették, vagy adatbázisokba tették. Ez az eljárás bá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 a

törzsadatokkal. Ezáltal az adatszerkezet áttekinthetõsége csökken, az adatállomány mérete nõ. 2. A programozónak ügyelnie kell a származtatott adatok konzisztenciájára Ezzel a programozói interfészeken is kell foglakozni, plusz a feladat bonyolódást és így hibát is jelenthet. 3. Ha a részeredmény több adattól is függ, akkor ennek már nincs nyilvánvaló helye, így a programozó egyedi megoldásokba kényszerül, amely megint bonyolódáshoz vezet, és hibaforrás lehet. 10 4. A részeredmények akkor is tárolva vannak, ha azok eddig még egyszer sem, vagy már ré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. E kép elkészítése 1-2 másodperc tipikusan, amely nem sok,

de már ezt is gyötrelmes volna tallózáskor mindig kivárni. Tehát tegyük el a kis képeket az anyagmodellt leíró rekordok mellé! 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ítve esetleg kevesebb. 2. Leíró rekord változásakor automatikusan változnia kell a szemléltetõ képnek is, vagy jelezni kell érvénytelenségét. Ez egy nem magától értetõdõ mechanizmus, jó volna elkerü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 a há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 egy megjelenítõ algoritmus nem másikakból állított volna elõ, tárolásukra csupán az idõ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 szerint sampleImage = render (materialRekord, screen.gamma, solid); // a szemléltetõ kép megjelenítése dialog.draw (sampleImage); Ha képet megõriznénk, akkor megfelelõ helyet is találnunk kell neki, és gondoskodnunk kell annak aktualitásáról is. Nyilván ez egy bonyolultabb eljárás volna, és találkoznánk az említett hátrányokkal. A C++ illetve Java objektum-orientált technológiáját használva olyan univerzális csomagoló õ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 mely információkat hagyja meg és melyeket törli le. Itt feltételezzük, hogy már rendelkezünk egy ún. streamelõ infrastruktúrával, amely a C++ nyelvnek nem

része, a Javanak viszont igen. 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 11 "streamelése" a mentéshez és beolvasáshoz szükséges, A paramétereké viszont azt a tetszõlegesen hosszú bit sorozatot szolgáltatja, amelybõl alkalmas függvénnyel 64 bitnyi mintát állítunk elõ. Ez a minta azonosítóként szolgál Elméletileg lehetséges, hogy így különbözõ paraméterezések a fenti eszközzel képzett azonosítója megegyezik és emiatt csúnya hiba történhet - bár ez nem valószínû. Egy gyors becslés szerint úgy 10-100 milliárd évente lehetséges ilyen és a több éves gyakorlatból azt tûnik ki e probléma inká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 sorsra jutnak. A "cache karbantartó" jelenlegi változata a régen használtakat törli, de érdekes elméleti kérdés vajon milyen elv volna itt az optimális. 12 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ót tekintjük. Utóbbi területtel az ArchiCAD esetében nem kívánunk foglalkozni, csak a modellezés és a képszintézis alrendszerekben alkalmazott algoritmusokat, elveket vizsgáljuk meg. Mivel az ArchiCAD inkrementális képszintézist alkalmaz, így a modellezé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éseit tárgyaljuk. Az ArchiCAD képszintézis alrendszerének alapjait a ’90-es évek elején rakták le, így fontos azokat a módszereket, elveket áttekinteni, amelyek azóta a tudományos világban születtek. Másrészt mára az alsókategóriás háromdimenziós gyorsítókártyák és a grafikus processzorral rendelkezõ videókártyák olyan technikai szintet értek el, hogy alkalmasak az ArchiCAD-ben számos, ma még szoftverbõl megoldott feladat elvégzésére. Ráadásul ezek a kártyák ma már szinte minden PC-ben és Macintoshban megtalá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ódszerek implementá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áltunk olyan szintig hatolni, amíg az így elkészült

összefoglaló nem tartalmaz belsõ, kifelé nem publikus 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ézis alrendszere a növekményes (inkrementális) képszintézis módszerét valósítja meg. Ezt háromdimenziós szerelõszalagnak ([1]) is hívják. A következõ alfejezetekben a szerelõszalag lépéseit külön-külön mutatjuk be. 3.11 Transzformációk A háromdimenziós szerelõszalag számos lépéséhez szükséges affin és nem-affin transzformációk végrehajtása, amelyeket az egységes kezelhetõség kedvéért homogén koordinátás (4x4-es) alakban szokták megadni. Ez azért is fontos, mert a mai hardverek is a homogén koordinátás alakot támogatják. Az ArchiCAD jelenleg 3x4-es mátrixokkal dolgozik memóriafoglalási szempontok miatt. Jelenleg is vizsgáljuk, hogy érdemes lenne-e átállni a 4x4-es megadásra. 3.12 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 is megtehetõ. A felhasználói oldal alatt azt értjük, hogy az ArchiCAD-ben milyen modellezési lehetõségek állnak a felhasználó rendelkezésére. A reprezentációs oldal alatt 13 pedig azt értjük, hogy az ArchiCAD ezeket a modellezési primitíveket hogyan reprezentálja. 3.121 Felhasználói oldal Mivel a felhasználó két és három dimenzióban is modellezhet, sõt, GDL-ben (Geometry Description Language) is, amely egy BASIC-hez hasonló szkriptnyelv, ezért az ArchiCAD-ben a geometriai jellemzõk definiálásának számos módja létezik. Ezeket nem célunk bemutatni, hisz ezekbõl a háromdimenziós megjelenítésért felelõs modul, a 3D Engine a háromdimenziós épületmodell elkészítésekor úgy is poligonokat hoz létre, a képszintézis alrendszer pedig ezekkel a poligonokkal dolgozik. 3.122 Reprezentáció Az ArchiCAD háromdimenziós

megjelenítését végzõ modul általános poligonokkal dolgozik, azaz lehetnek konvexek, konkávok, de akár lyukasak is. Mivel számos képszintézis algoritmus csak háromszögekkel dolgozik, vagy azokkal tudja hatékonyan megoldani a képelõállítást, ezért szükséges a poligonok háromszögekre bontása. Az ArchiCAD számos háromszögekre bontó módszert alkalmaz: a füllevágást, a Delanuay háromszögelést ([2]), egy „sweep” algoritmust, amely mûködik rektilineáris alakzatokra is és egy egyszerû módszert. Ez utóbbi módszer annyit tesz, hogy minden csúcspontot megpróbál összekötni a szomszédjain kívüli összes csúccsal. Ha azonban egy összekötés keresztezne egy elõzõt vagy a poligon vonalát, akkor azt az összekötést eldobja. Ezzel a mó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.13 Elhelyezés a kamera koordináta-rendszerben Az ArchiCAD a hagyományosnak mondható kamera modellt alkalmazza. Az ablak kö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éretei külön-külön megadhatók. Perspektív vetítés esetén a szempozíciót, párhuzamos vetítés esetén pedig egy vetítési irányt kell megadni. A tárgytér látható objektumai egy végtelen gúlában helyezkednek el. Ezt a teret korlátozhatjuk vágósíkok definiálásával 3.14 Térbeli vágás Ez a terület igen komoly és bonyolult saját algoritmusokat alkalmaz. Ezekrõl jelen keretek között nem kívánunk szólni.

Az algoritmusok alapja azonban a Sutherland-féle térbeli vágó algoritmus ([2]), amelyet az ArchiCAD számos esetre általánosított. 14 3.15 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épez le ha ezek részlegesen, vagy teljesen takarják egymást. A háromdimenziós grafikában a kép adott pixelén azon felületi pont színét használják, amely a legközelebb van a kamerához. A láthatósági, takarási problémákat megoldó algoritmusokat 1974-ben Sutherland osztályozta ([5]). A módszereket aszerint csoportosította, hogy alapvetõen a tárgy- vagy a ké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ául terü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 a poligonokat, 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 az ArchiCAD – 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étes irányitottságú normálvektorral dolgozik. Egy másik egyszerû módszert, a poligonos takarást is tartalmazza az ArchiCAD, amelyet a 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 sem implementáltak. Ezekkel részletesebben a "Globális illuminációs számítási

módszerek specifikációja" címû dokumentum foglalkozik. A takarási problémák megoldására számos további megoldást javasoltak, de a gyakorlatban csak két megközelítés maradt fenn: a pásztalapúak (scan line based) és a mélységi puffer alapúak (z buffer based). Az ArchiCAD mindkét megközelítést alkalmazza képszintézis alrendszerében. 3.151 Pásztalapú megoldás Az elmúlt évtizedek során számos pásztaalapú algoritmust publikáltak. Ezek mind ké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ézis algoritmusa, az "ArchiCAD Rendering Engine" is ezt alkalmazza. Történelmi okok miatt ezt 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ésre alkalmazott aktív éllistás módszerhez ([2]). Az algoritmus lényege az, hogy

minden pásztára megkeresi azon szakaszokat, amelyeket árnyalt színnel kell megjeleníteni. 15 Természetesen a módszer olyan szakaszokat keres, amelyek egy felülethez tartoznak, így egyszerre 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. Viszont az algoritmus komoly hátránya, hogy az inkrementális árnyalási számításokat megnehezíti. A másik problémája a komplexitása, amely miatt hardverben nem is valósították meg. Bizonyított tény, hogy igen nagyszámú poligon esetén, amely az ArchiCAD-nél igencsak jellemzõ, a mélységi puffer alapú módszerek hatékonyabbak. 3.152 Mélységi puffer alapú megoldás A mélységi puffer módszert 1975-ben Catmull publikálta ([8]). A módszer - a sutherlandi osztályozás szerint - képtérben dolgozó algoritmus, amely nem használ koherenciát. A mélységi puffer

algoritmus egy akkora puffert hoz létre, amelynek dimenziói megegyeznek 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. Minden pixel esetén kiszámítjuk a felületi pont Z koordinátáját és összehasonlítjuk a mélységi pufferben lévõ értékkel. Ha a mélységi pufferben lévõ érték nagyobb (azaz az eddig feldolgozott poligonok ott távolabb vannak, mint az aktuális poligon), akkor az éppen feldolgozás alatt lévõ elemet kell kirajzolni. A szín puffer megfelelõ pixelét ekkor mó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 puffer minden é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ár legtöbbször, így az ArchiCAD-ben is poligonháló (polygon mesh) alapú képszintézisnél alkalmazzák, bármilyen reprezentációval együtt használható. Például CSG (Constructive Solid Geometry) objektumokra is használható ([9]), amelyeket az ArchiCAD egy késõbbi verziójában remélhetõleg támogatni fog. Ezért is érdemes lenne a mélységi puffer használatára nagyobb hangsúlyt fektetni. Mégis a módszer talán legnagyobb elõnye az egyszerûségében rejlik. Ezért majdnem minden mai gyorsítókártyán és grafikus processzorral rendelkezõ videokártyán implementálták. A módszer legfõbb hátránya, hogy nem gazdaságos, hisz minden pixelnél számos poligon pontjának árnyalt színét kiszámítja - fölöslegesen. Ez a probléma az ArchiCAD-es implementációnál, a rendering add-on-ként létezõ "Z Buffer

Rendering Engine"-ben nem létezik, ugyanis az add-on kétmenetes mélységi puffert alkalmaz: az elsõ menetben a látható poligonokat határozza meg, a második menetben pedig csak ezekhez számolja ki a színértékeket. Az évtizedek során - fontossága miatt - a módszer gyorsítására számos ötletet javasoltak, amelyeket a 3.22 és a 335 alfejezetekben tárgyaljuk. 16 3.16 Árnyalás Az inkrementális képszintézis e lépésekor minden pixelben ismert már, hogy ott melyik felületi pont látszik. A ponthoz tartozó színérzet meghatározása az ArchiCAD-ben lokális illuminációs modellel (lásd 1. fejezet) történik 3.161 Fényforrások Az árnyalás szempontjából fontosak a fényforrás megadási lehetõségei. Az ArchiCAD számos fényforrás típust ismer. Pontszerû és szpot fényforrások is megadhatók, de kezel párhuzamos fényt (például Napot) is. A felületekhez rendelhetõ ugyan emisszió, az ArchiCAD nem kezeli ezeket a felületeket területi

fényforrásként. A fényforrások tulajdonságai nem fizikai alapúak (lásd 2.5 alfejezetet), amelyre pedig egyre nagyobb igény mutatkozik nemcsak a képszintézis, hanem például a lámpagyártók oldaláról is. A Nap pozíciójának számítása fizikai alapokon nyugszik. Az ArchiCAD-ban fé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ét gyárban is lehet látni valamennyit. Számos képszintézis alrendszerrel rendelkezõ program ezt 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õl tá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ág szerinti lecsengést. 3.162 Anyagjellemzõk Az ArchiCAD-ben a testek geometriai tulajdonságait és a testhez kapcsolódó egyéb tulajdonságokat külön választották. Utóbbi jellemzõket attribútumoknak hívjuk A ké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 geometriai tulajdonságok és az anyagjellemzõk szétválasztásával elérték azt, hogy nem kell minden felülethez külön megadni minden anyagi jellemzõt (például szín, textúra stb.), hanem elegendõ egy globális anyaglista egy elemére hivatkozni. Ez egyrészt kevesebb memóriát igényel, másrészt egy anyagi jellemzõ módosítását nem kell külön-külön minden szükséges felületen elvégezni. Az ArchiCAD-ben az anyagjellemzõk ma még nem fizikai alapúak (lásd 2.4 alfejezetet) Ez számos hiányosságot fog maga után vonni a globális illuminá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ól a diffúz és a spekuláris albedonak feleltethetõk meg, de mivel a két tényezõ összege 17 nyugodtan lehet több mint 100 %, az ArchiCAD fizikailag nem plauzibilis. Esetünkben ez azt 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 nem tudja megjeleníteni. Komoly hiányosságnak tekinthetõ a tükrözõdõ felületek hiánya is 3.163 Megvilágítási modell Az ArchiCAD egy felületi pont színének meghatározásához a következõ lokális illuminációs modellt alkalmazza: a pont emissziójához hozzáadja a direkt megvilá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 a bejövõ radianciákat szorozzák a beesési szögek koszinuszaival, valamint a beesési és visszaverõdési szögek által meghatározott BRDF (bidirectional reflection distribution function) függvényértékekkel, majd ezeket összeadják. Mivel az ArchiCAD kezeli a diffúz és a spekuláris visszaverõdéseket, ezekhez eltérõ BRDF függvényeket kell használnia. A diffúz visszaverõdésre konstans BRDF-t alkalmaz, míg a spekulárisra a Phong modellt ([10]). Ez utóbbi BRDF modellrõl ismert tény, hogy nem elégíti ki a Helmholtz-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 a Phong modellben szerepel a bejövõ szög koszinusza. Tehát az ArchiCAD a spekuláris hatások megjelenítésére fizikailag nem plauzibilis BRDF modellt alkalmaz. Az évek során a Phong

modell számos módosítását javasolták, amelyek már fizikailag plauzibilissá teszik a BRDF-t. Ezek közül jelenleg a maximum Phong modell ([11]) tûnik a legjobbnak. A Phong modell különbözõ módosításaival részletesebben a "Globális illuminá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: a Phong-féle színinterpolációt ([12]). Alternatív lehetõség az OpenGL rendering add-on esetében a kevésbé szép, de hardverrel könnyen számítható Gouraud árnyalás. 3.164 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 CAD rendszerhez hasonlóan az ArchiCAD is képes a textúra koordinátákat megadni. Az ArchiCAD 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 a

spekuláris (specular mapping) tényezõk alfa csatornából való állítására. Ezeken kívül az ArchiCAD egy klasszikus alfa csatornás módszert, a bucka leképezést (bump mapping) is ismer ([6]), amely az alfa csatorna alapján módosítja a felületi normálist. Mivel a normálvektor a megvilágítási modellben fontos szerepet játszik, így a bucka leképezéssel azt a hatást kelthetjük, mintha a textúrázott felület göröngyös lenne. A bucka leképezés gyors, de mivel a geometrián nem változtat, így könnyen észrevehetõ a "csalás": a felület körvonala nem változik meg. Ezt a hatást csak displacement mappinggel ([13]) lehet elérni. 18 3.17 Effektek Az ArchiCAD képszintézis alrendszerét az építészek igényeinek megfelelõen valósították meg. 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. Viszont

számos felhasználói igényelné a valószerû, fizikailag pontos képek elõállítását is. Ezen felhasználók igényeit az ArchiCAD különbözõ effektek alkalmazásával próbálja ki kielégíteni. Ma az ArchiCAD a lokális illuminációs modell kiegészítéseként az árnyék és a köd effekteket ismeri. 3.171 Á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, hogy csak a fényforrásokból látható poligonok vetnek árnyékot. Tehát minden fényforrásra meghatározzuk a látható poligonokat, majd meghatározzuk a fényforrásokból kiinduló a poligonok körvonalán átmenõ „virtuálisan tömör” testeket, az ún. árnyéktesteket Például egy négyszög esetén így egy csonkagúlát kapunk. Ezeket az árnyéktesteket az ArchiCAD beveszi a többi geometria közé, de a kép elõállításakor csak az árnyékok

meghatározására használja õket. A képszintézis során minden pixelnél megszámoljuk, hogy hány árnyéktestbe léptünk be illetve ki, amíg a legközelebbinek vélt felületi ponthoz érkezünk. Belépéskor eggyel növeljük a számlálót, kilépéskor pedig eggyel csökkentjük. Ha egy adott pixelhez legközelebbinek vélt felületi pont esetén a számlálóban pozitív értéket kapunk, akkor az azt 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éktest belsejében sem, azaz nincs árnyékban. Az algoritmus nagy színterek esetén igen lassú lehet, amely az ArchiCAD-ben tapasztalható is. Másrészt mivel pontosan számolja az árnyékok helyét, ezért CAD rendszerekben - alternatívaként - érdemes használni. A módszerrel nem éles árnyékokat (soft shadows) is lehet készíteni. Azonban az ArchiCAD az emittáló poligonokat nem kezeli területi

fényforrásként, azaz csak pontszerû 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.172 Köd Mivel az ArchiCAD nem rendelkezik sugárkövetés alapú képszintézissel, így a köd hatá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 egy fehér fal pirosas köd esetén pirosas falként fog megjelenni, de a fal környezetének színe nem fog megváltozni. Ez a megoldás nem ad valószerû hatást 19 3.18 Színleképezés Bár a képszintézis során kiszámoljuk, hogy a monitor pixeleinek megfelelõ térszögbõl milyen 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ámolt intenzitás értékekbõl a monitor adatainak megfelelõ

mennyiségek kiszámítása. Ezt a folyamatot 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 is alkalmazhatna. 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 is foglalkozik. 3.19 Elõzetes képeken alapuló szintézis Miután a 80-as években elérhetõvé váltak a grafikus munkaállomások, amelyekben a mélység puffer hardveresen volt implementálva, a képszintézis kutatások teljes egészében a valószerû, fotorealisztikus képelõállítás irányába tolódtak. A 90-es

évek elején tisztán látszódott, hogy a képszintézis kutatások számos problémát még jópár évig, évtizedig nem 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 a szintetizált kép valószerûségét nagyban nõvelõ fák, levelek, felhõk, fû stb. környezeti elemek használata, hiszen ezek óriási mennyiségû poligont jelentenek. Ráadásul a mai igényeknek megfelelõ, egyre bonyolultabb színterek igen nagyszámú poligont használnak, amelyek csökkentése bár a képelõállítás sebességét növelik, a végeredmény valószerûségét jelentõsen rontják. Az egyik legígéretesebb irányvonalnak az elõzetes képekre alapuló szintézis (image based rendering) mutatkozott, amelynek bizonyos területei be is váltották a hozzá fûzött reményeket. Ezek közül kettõt az ArchiCAD-be is beépítettek 3.191 QuickTime VR A Graphisoft a

kutatások kezdeti sikereit látva, az egyik legfontosabb partnerének, az Applenek 94-ben kihozott QuickTime VR eljárását az ArchiCAD-be beépítette. A módszer lényege, hogy a színterekben panoráma kamerák helyezhetõk el és 360 fokos körképeket készíthetõk. Ezeket a körképeket elmentve, bármikor újrafelhasználhatóak adott pozíciókon valósidejû körbenézésekre. A módszer fõ hátránya a pozícióhoz rö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 20 míg az elkészült panoráma teljes horizontális forgást tesz lehetõvé, vertikális irányban korlá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 az

ArchiCAD volt az elsõ és hosszú ideig egyetlen CAD rendszer, amelyben VR panoráma kamerákat lehetett elhelyezni, ez óriási elõnyt jelentett a konkurens CAD rendszerekkel szemben. 3.192 Fotogrammetriai képességek Gyakran a modellezett objektumot nem csupán önmagában szeretnénk látni, hanem valamilyen környezetben. Ez a környezet – háttér – lehet fiktív, amelynek célja a modell szebb környezetben történõ bemutatása, vagy maga a valóság, ahová a modellt be szeretné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éb táj) tervezzük az új objektumot, és végeredményképp azt szeretnénk látni, hogy hogyan illeszkedik oda. A számítógépi grafika már 1979-tõl kínál megoldásokat erre a problémára. Ezen mó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 évek sorá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 a legmegfelelõbb kiválasztása, illetve kialakítása jelenti. Adott módszerrel együtt jön az alkalmazandó algoritmus, amelyhez használható felhasználói felületet kell tervezni. Az algoritmus végsõ célja a nézõpont, a dõlési- és elfordulási szög, valamint a látószög megállapítása. Tehát reprodukálni kell a fényképezést úgy, ahogy a háttérnek berakott képet rögzítették. Ezeknek, és még egyéb méret adatoknak a birtokában valósulhat meg a hiteles montázs elkészítése, amelyben megegyeznek az arányok, a szögek stb. Ennek a feladatnak 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épes montázskészítésre. Az alkalmazott algoritmus érdekessége, hogy csak 4 referencia pontot igényel, amelyekkel a képen szereplõ objektum és a modell megfelelõ pontjait rendeljük egymáshoz. A 31 ábrán ezt a funkciót mutatjuk be 21 3.1 ábra: az eredeti kép (balra) és a kombinált kép (jobbra) 3.110 Igények Ebben a részben tételesen szeretnék bemutatni azokat a képszintézis funkciókat, amelyek jelenleg 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 nem tükörszerûen viselkednek. Láthatósági szûrések (visibility culling): egy szobában csak a szobában és a szobából látható poligonokkal kell foglalkozni, a kamerából induló térszögben szereplõ ö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ékok megjelené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át a nem-fizikai jellemzõk konvertálásával oldjuk meg, de a GDL (Geometry Description 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ézis elké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, így hasznosnak érezzük azokat a módszereket, elveket áttekinteni, amelyek azóta a tudományos világban születtek. Ebben az alfejezetben megpróbáltunk

olyan módszerekre kitérni, amelyek nem közvetlenül a globális illuminációs képszintézissel állnak kapcsolatban, hisz az ilyen megoldásokkal a "Globális illuminációs számítási módszerek 22 specifikációja" címû dokumentum részletesen foglalkozik. A sugár és poligon metszéspontszámító módszereket is abban a dokumentumban tárgyaljuk. 3.21 Á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 évek második felében jelentek meg azok a módszerek, amelyeket a legtöbb mai grafikus rendszer 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.211 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. A legegyszerûbb és egyben legpontosabb megoldást a sugárkövetés (ray-tracing) adja. A nézõpont minden pixelen keresztül indítunk egy sugarat és meghatározzuk, hogy melyik felületi pontot metszik el elsõként. Ezekbõl a pontokból minden fényforrás felé indítunk 1-1 sugarat. Ezeket hívják árnyéksugaraknak (shadow rays) Természetesen, figyelembe kell venni, hogy milyen típusú fényforrással (területi, szpot, pontszerû) kötjük össze a pontot. Ha legalább 1 fényforrás esetén a sugár elsõként nem a fényforrást metszi, akkor a 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 nem sugárkövetéssel határozzuk meg, hanem más hardverrel támogatott

takarási problémamegoldó algoritmussal (például mélységi pufferrel). Errõl a témakörrõl részletesebben a 3.35 pontban írunk 3.212 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 Egy elõfeldolgozási lépésben minden fényforrásból nézve kiszámolja a mélységi puffer tartalmát, de a színértékeket nem. Ezzel megkapjuk a fényforrásokból nézve legközelebbi poligonok távolságértékeit. Ezután minden fényforrásnál megjegyezzük azt a transzformációt, amellyel a színtér elemeit a fényforrások "képernyõjére" vetítjük. Ugyanezt a lépést a kamera szemszögébõl is 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 23 megkaphatjuk azt az (x, y) koordinátát, amelybõl a pont látszódhatna, ha a fényforrásból szeretné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, akkor ez 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 kicsi epszilon sugarú környezetben van, akkor a felületi pont mind a kamerából, mind az éppen vizsgá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 hardveres mélységi pufferrel

rendelkeznek. Viszont a hardveres mélységi puffer megvalósítások rö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árisan becsült út pontatlan. Ez a perspektív torzítás jelensége Ezért elõfordulhat, hogy a módszer "téved" és olyan pontokat is az árnyékban levõkhöz rendel, amelyek nincsenek árnyékban, illetve fordítva. 3.213 Árnyéktérkép Az elõzõ megoldást könnyen átalakíthatjuk textúrázási feladattá ([15], [16]). A fényforrásoknál létrehozott mélységi pufferek tartalmát tekintsük egy kétdimenziós textú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ás alakban. 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/q textú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 a kamerá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épeken az á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 gyors textú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. 24 3.22 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 a szí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 nem veszik 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-, BSPfa) szolgálnak. A színteret egy egyszerû nyolcasfával (octree) szabdaljuk fel A nyolcasfa egy csomópontja akkor és csak akkor nem látható, ha a benne lévõ összes poligon 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 sem lá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 a nyolcasfában és ott újra elvégezzük a fenti tesztelést. 3.23 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 sugarat indítunk és keressük az elsõ metszési pontokat. Ehhez minden pixel esetén rengeteg sugá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 pixelen begyûjtött információk elvesznek a következõ pixelnél való sugárindításkor. Az inkrementális képszintézis viszont

kihasználja ezeket. A színtér poligonjait sorszámaikkal indexelt, konstans színekkel jelenítjük meg. A kép elkészültekor a szín pufferben azon poligonok 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ézis vé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 az inkrementális képszintézis lépéseit hardveresen lehet gyorsítani, így ezzel a megoldással a 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 grafikus processzorral rendelkezõ videokártyák

olyan technikai szintet értek el, hogy alkalmasak az ArchiCAD-ben számos, ma még szoftverbõl megoldott feladat elvégzésére. Ráadásul 25 ezek a kártyák ma már szinte minden PC-ben és Macintoshban megtalálhatóak, így mindenképpen érdemes bemutatni lehetõségeiket. 3.31 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ól megegyezõk, csak a sebességükben különböznek. Manapság már az összes kártya támogat legalább két API-t (Application Programing Interface), amelyek közül az OpenGL-t és a Microsoft Direct3D-t kiemelt fontosságú interfészekként kezelik. A két programozá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, amely egy é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ány alkalmazási területet szeretnénk bemutatni. Azt is szeretnénk hangsúlyozni, hogy a hardverek hihetetlen tempójú fejlõdése miatt bár az ArchiCAD számos funkciója ma még hardveresen nem gyorsítható, de 1-2 éven belül várható. Ilyen lehetõségként említenénk meg a displacement mapping ([13]) hardveres gyorsítását, amelynek elsõ prototípusán jelenleg is

dolgoznak a Matrox fejlesztõi. 3.32 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ármely poligonhoz hozzárendelhetünk. A fénytérkép egy elõre kiszámított textúra, amely az adott 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ött definiált textúrák és a fénytérképek. A textúrák ilyenkor egymás erõsíthetik és gyengíthetik is, hisz multitextúrázással lehetõség van a textúrák tetszõleges súlyozással történõ kombinációjára. Utóbbiak számítási ideje és élethûsége függ az alkalmazott 26 algoritmustól, a fénytérképek felbontásától. Ezek a paraméterek könnyen személyre szabhatóak, viszont a képszintézis mindig optimális ideig

tart. Ezek alapján hasznosnak tartjuk ArchiCAD-ben való implementálásukat. 3.33 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öbb tárgy is vet árnyékot, sötétebb árnyalatot kapjunk. A stencil puffer egy lehetséges alkalmazása lehet a plafonnál levõ ventillátorlapátok árnyékának padlón való megjelenítése. 3.34 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árom transzformációs mátrix (az objektum, a nézeti és a projekciós mátrixok) és a színtér poligonjai alapján képesek a képszintézis végrehajtására. Az objektum mátrix a világ koordináta-rendszerben való elhelyezést szolgálja. A

videokártyák a nézeti mátrixból elkészítik a hat vágósíkot (közelsík, távolsík, jobb, bal, fent és lent), majd végrehajtják a né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 Ez azt jelenti, hogy minden poligonhoz hozzárendelhetõ egy speciális textúra, amely - a fénytérképhez hasonlóan - elõre kiszámított értékeket tartalmaz. Ezek az értékek azonban nem 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õinek megfelelõen lesznek megvilágítva. Különösen jól használhatóak érdes felületek emulálására, de a módszert tekinthetjük a Phong interpoláció hardveres támogatásának is. 3.35 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ól maguk a megoldások talán nem annyira érdekesek, de mégis hasznosnak érezzük õket itt leí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 jelenet Gouraud-árnyalt kiszámítása után sorra veszik minden egyes háromszög minden egyes pontját, majd a megfelelõ textúrákban hozzájuk rendelt színekkel színezik ki õket. Ha a motor végzett a szín kiszámításával, a pont Z-, azaz mélységi koordinátája alapján Z tesztet végez, amelynek segítségével megállapítható, hogy az elkészült képen a kiszámított pixel látható lesz-e, vagy egy másik pont eltakarja. Ha a frissen kiszínezett pont látható, akkor bekerül a szín pufferbe. Ha a pont takarásban

van, a motor egyszerûen 27 eldobja és veszi az aktuális háromszög következõ pontját, amelyre újra elvégzi a bekezdé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 munka ká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. Ez pedig azt jelenti, hogy a szükséges adatmozgás többszöröse zajlik a videochip és a grafikus 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 a

memóriasávszélességel. 3.351 Az ATI HyperZ módszere Az ATI által a Radeon chipben bemutatott HyperZ eljárás számos apró trükkel próbál javí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észetesen nagysá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égi puffert 8- és 64-pixeles blokkokra bontják, amelyeket az eredeti méretük felére vagy akár negyedére is össze lehet tömöríteni. Ha szükség van valamelyik blokk tartalmára, akkor a kitömörítés a chipben található belsõ mélységi pufferbe történik. A mélységi puffer mûveletekhez szükséges sávszélesség csökkentésén kívül ez az eljárás a puffer

helyigényét is csökkenti. Tehát a grafikus memóriában, ahol a külsõ, tömörített mélységi puffer 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. Minden egyes 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 a mélységi puffer törlésére, amelyet eddig úgy oldottak meg, hogy egyszerûen feltöltötték a maximá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 blokkokat egymá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 a tö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 megy végbe, mint a hagyományos törlés, másrészt,

takarékosan bánik a sokat emlegetett memóriasávszélességgel is. 3.352 A tile-based deferred rendering A KYRO cég PowerVR videochipje a tile-based deferred rendering eljáráson alapul. A kép kiszámításának menete a Gouraud-árnyalásig ugyanúgy zajlik, mint azt a hagyományos eljárás során ismertettük. Ám ezután a chip a képet apró pixelblokkokra, 28 azaz mozaikokra (tile) osztja fel, és meghatározza, hogy mely háromszögek vannak az adott mozaikban részben vagy egészben. Majd ezeket a háromszögeket mélység szerint egymás mögé állítja (depth sorting). Ha ezzel végzett, végigfut a mozaik pontjain és megvizsgálja, hogy mely képpont melyik háromszöghöz tartozik, és az adott képpontot a há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 overdraw jelenséget, azaz nincsenek feleslegesen kiszámított, majd eldobott pixelek. A másik elõnye, hogy ha a mozaikot

akkorára választjuk, hogy a mélységi puffer elférjen a videochipbe épített aprócska gyorsítómemóriában (cache), nem szükséges a chip és a grafikus memória közötti lassú adatbuszt olyan gyakran igénybe venni. Ez tovább csö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 a magmé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. 29 30 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 tapasztalatok megfelelõ kiinduló alapot nyújthatnak Ebben a fejezetben

olyan grafikus rendszereket tekintü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ötti kommuniká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 online kommunikáció megvalósításához adhatnak ötleteket. A második részben pedig azokat a programokat 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ási lehetõségeket biztosít, különös tekintettel a fizikai alapúakra. Az így összegyûjtött informá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, amelyek egyetlen programban biztosítanak modellezési, képszintézis és igen gyakran animációs lehetõ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ért az 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 (3D Studio MAX, Maya), egy ipari formatervezõ programot (trueSpace) és két CAD rendszert (AutoCAD, Architech.PC) vizsgáltunk meg Ezek közül alapesetben csak a trueSpace 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. Az alá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ális illuminációs alrendszerük közötti online kommunikációs megoldásukat, de részletesen kitérünk a programok funkcionalitására is. Bár ebben az alfejezetben csak integrált megoldásokkal foglalkozunk, ahol offline kommunikációra nincs szükség, hasznosnak tartjuk összegyûjteni a programok által kezelt fájl formátumokat. Ez hasznos alap lehet az ArchiCAD fejlesztése, illetve a projekt során készülõ program számára is. Természetesen, csak a képszintézis szempontjából érdekes formátumokat írjuk le. 31 4.11 3D Studio MAX A professzionális háromdimenziós modellezõ, animációs és képszintetizáló programok közül a 3D Studio MAX-ból ([22]) adják el a legtöbbet. A MAX felhasználóinak egységes, objektum-orientált platformot biztosít, amellyel vizuális effekteket, karakter animációt és következõ generációs játékokat készíthetnek. A programot 1996-ban mutatták be. Azóta 65 különbözõ díjat nyert és több mint

140000 felhasználóval rendelkezik. 4.111 Anyag- és fényforrásjellemzõk A 3D Studio MAX nem fizikai alapú anyag- és fényforrásjellemzõket használ. A 41 ábrán balra egy Phong-szerû anyag jellemzõit láthatjuk. Felhívnánk a figyelmet a multitextúrázási lehetõségre. Ez azt jelenti, hogy egy anyaghoz több textúrát is hozzá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 az Object Shadows szekcióban állíthatjuk be az On checkbox kipipálásával. Ez alatt pedig az is meghatározható, hogy milyen módszerrel számolja ki az árnyékot. A 3D Studio MAX két árnyékvetõ módszert ajánl: az árnyéktérképek (shadow maps) és a sugárkövetett árnyékok (raytraced shadows) használatát. Megjegyezzük, hogy a 3D Studio MAX nyitott

architektúrájú alkalmazás, ezért lehet hozzá fizikai alapú anyagokat és fényforrásokat is fejleszteni. 4.112 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/O plugin-ok megvalósításával. A 3D Studio alapesetben a következõ formátumokat képes beolvasni, azaz importálni: • • • • MAX: ez a 3D Studio MAX saját formátuma, amelynek a pontos felépítése nem publikus. 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ájljait kezelni, valójában ezt a formátumot kezeli. 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 rendszer nem képes kezelni. 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ére fejlesztettek ki. 32 • 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 ipari szabvá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 33 A 3D Studio MAX alapcsomagjában az alábbi formátumokat képes kiírni, azaz exportá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 tudja kezelni. MAX 3DS DXF / DWG VRML 4.113 Plugin renderer interfész A 3D Studio MAX nyitott architektúrájú alkalmazás, amely azt jelenti, hogy a program magja fölé különbözõ célú, feladatú programokat lehet

fejleszteni, amelyek a MAX-ba integrá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õ Renderer interfész osztályt kell megvalósítani. A gyerekosztályban szereplõ virtuális metódusokat a 3D Studio MAX hívja: a metódusokon keresztül inicializáltatja a plugint, felrakatja a plugin saját paramétereit tartalmazó dialógus ablakot, képet készíttet, végül befejezteti a munkát. A plugin renderer saját adatstruktúrákkal dolgozik, amelyek nem jelennek meg a 3D Studio MAX globális adatszerkezetei között. Ez a megoldás

óriási mennyiségû adat duplikálásához vezethet. Például a színtér teljes geometriája mind a 3D Studio MAX globális adatszerkezeteiben, mind a plugin saját adatszerkezeteiben is meglesz. Ahogy látni fogjuk, az ArchiCAD is ezt a megoldást ajánlja. A módszer a lehetséges memóriagondok és a duplikátumok ellenére külsõ fejlesztõk számára hasznosabb, mint a rendszerbe való teljes integráció, hisz az újabb MAX verziók megjelenésekor csak a plugin renderer interfész ért minimális módosításokat kell a pluginban végigvezetni, így a plugin komolyabb újraírás / újragondolás nélkül ugyanúgy fog mûködni. 4.114 mental ray A 3D Studio MAX készítõje, a Discreet a német Mental Images céggel közösen a MAXba integrálta - plugin rendererként - az egyik legismertebb professzionális képszintézis programot, a mental ray-t ([23]). A mental ray képes a fény viselkedésének fizikailag korrekt szimulációjára. A mental ray globális

illuminációs algoritmusa az elõre- és a hátrahaladó sugárkövetõ módszereket 34 kombinálja azért, hogy az összes lehetséges fényutat megkapja. Ezért nemcsak diffúz visszaverõ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és hatásaként jönnek létre. Például lencsék, üvegek képesek összegyûjteni a fényt és egy diffúz felületen apró, igen fényes foltként megjeleníteni. Az ilyen foltokat idegen szóval kausztikus 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égiscsak determinisztikusak, ugyanis ezzel azt akarták elérni, hogy ha adott kameraállásból egy szí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 az algoritmusok 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ál elõfordulhat. Azonban a mental ray nemcsak sugárkövetést használ képszintézisre, hanem egy gyors pásztaalapú módszert is. A program automatikusan választja ki, hogy mikor kell sugárkövetést alkalmaznia a fénytörések, árnyékok stb. számolására A mental ray egyik fontos 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. 35 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 a hálózatban elosztott erõforrásokat (processzorok, memória stb.) felhasználni Sõt, egy mental 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ódon tö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 ne kelljen 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õsen lecsökkentették. 4.12 Maya Az Alias|Wavefront a világ egyik vezetõ szoftvergyártója. Két- és háromdimenziós technoló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ós

felhaszná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 karakter animációs és vizuális effekteket készítõ programcsomag - kifejezetten professzionális animátorok részére. A Graphisoft szempontjából fontos megemlítenünk, hogy a Maya egyike azon kevés programnak, amelyek elérhetõek Macintosh platformra is. A Maya alapfilozó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 csomag rendelkezik. 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 egy poligon alapú gömb paramétereit (sugár, tesszellációs szint stb.) a paraméterek 36 csomópont tartalmazza,

a gömb tényleges megjelenését pedig egy alakzat csomópont. A két csomópont úgy van összekötve, hogy az alakzat inputja a paraméterek. Tehát, ha a felhasználó a paraméterek csomópontban valamit változtat, akkor az hatással van az alakzat csomópontra is. Ezzel a megközelítéssel igen bonyolult feladatok is egyszerûen megoldhatóak. Az Alias|Wavefront egy sor újítással még könnyebbé és sokkal érthetõbbé teszi a Maya kezelõi felületét. Ez különösen az új felhasználók számára teszi még szimpatikusabbá a Mayá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 Photorealistic Rendering) technológiát, amellyel a megjeleníteni kívánt kép egy részét kijelölhetjük és interaktívan módosíthatjuk. Ezzel a módszer például egy szpot lámpa pontos elhelyezését, végsõ képen jelentkezõ hatását valós idõben állíthatjuk be. A 44 ábrán egy

ûrhajón dolgozunk és a fényviszonyok pontos beállítására az IPR-t használjuk. A zöld té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.121 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 45 ábrán látható, hogy egy Phongszerû anyagot hoztunk létre, amelyhez egy Pine nevû textúrát rendeltünk hozzá. Az ábráról a két csomópont közötti kapcsolat is leolvasható. 37 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, amely mutatja, hogy egyszerû feladat esetén is milyen "bonyolult" gráf

épülhet fel. Az ábrán látható, hogy a Pine textúrához tartozik egy elhelyezési csomópont (place2dTexture1), a phong1 anyaghoz pedig egy árnyalási csoport csomópont (phong1SG). Az ábrán jól megfigyelhetõ, hogy a textúra és az elhelyezését szabályozó csomópont között számos kapcsolat (például U és V irányok szerint skálázis faktorok, eltolási tényezõk stb.) áll fenn. 4.6 ábra: a HyperShade-ben anyaghoz (phong1) hozzárendelt textúra (Pine) összes kapcsoló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ényleges paramétereket is lehet állítani. Ezeket a fenti ikonokra bökve érhetjük el A 47 ábrán a Phong anyag tulajdonságait láthatjuk, amelyen látszik, hogy a Maya Phong shadere sem fizikai alapú

anyagjellemzõket tartalmaz. 38 A 4.8 ábrán egy szpot lámpa tulajdonságait mutatjuk be Az ábráról leolvasható, hogy a Maya alapcsomagjában sincsenek fizikai alapú fényforrások. Itt is megjegyezzük, hogy minden fényforrásnál külön-külön lehet állítani, hogy vessen-e árnyékot vagy sem, illetve az á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 lehet hozzá fizikai alapú anyagokat és fényforrásokat is fejleszteni. 4.7 ábra: Phongszerû anyagjellemzõk a Mayában 39 4.8 ábra: egy szpot lámpa jellemzõi a Mayában 4.122 Kezelt fájl formátumok A Maya - nyitott architektúrájának köszönhetõen – számos formátumot képes kezelni. Az alapcsomag 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ére fejlesztettek 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. 40 4.123 Rendering plugin A Maya - a 3D Studio MAX-hoz hasonlóan - nyitott architektúrájú program. A Mayában is minden funkcióterületet más és más típusú plugin fed le, amelyek C++ nyelven készülnek. A projekt szempontjából a rendering plugin-okat érdemes részletesebben megvizsgálni. A Maya csomópont alapú filozófiája a plugin-oknál is érvényesül. A Mayában a pluginok

adatszerkezetei beépülhetnek a függési gráfba, de a konzol parancsok közé is. Ezzel az adatdupliká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õl bonyolult rendszerek építhetõk. Már egy egyszerûbb plugin számára is számos csomópontot kell implementálni, ezért nehéz elõre felkészülni, illetve tesztelni a csomó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 lehet szabályozni. Ehhez meg kell valósítani egy MRenderCallback osztályból származtatott gyermekosztályt. A Maya a visszahívó függvényeket a következõ esetekben hívja meg: a képszintézis kezdetén, az árnyékvetés számításánál és az utómunkák során. A megvalósított gyermekosztályhoz egy csomópontot kell hozzárendelni, amelyhez a fü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ánosan alkalmazható képszintézis algoritmust megvalósítani. Ezért a Mayához jóval kevesebb képszintézis plugin létezik, mint például a 3D Studio MAX-hoz. Ez a szám kifejezetten a globális illuminációs elvû algoritmusoknál minimális. Ezek közül mi a Lightflow Rendering Tools nevû plugint választottuk. 4.124 Lightflow Rendering Tools A Lightflow Rendering Toolst - a mental ray-hez hasonlóan - önálló alkalmazásnak fejlesztették ([25]), amelyet utólag integráltak a Mayával. A programot Jacopo Pantaleoni közel 5 évig fejlesztette, amelyet az ELF (Embedded LightFlow) projekt keretében integrált a Mayával. Ez azt jelentette, hogy a Lightflow Rendering Toolst a Mayában rendering 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 éri el, hogy konzisztens interfészt és a legjobb sebesség / minõség arányt biztosítja. Ez a koncepció olyan hatásosnak bizonyult, hogy mára rengeteg egyedülálló vagy csak igen drága programcsomagokban létezõ funkciót is meg tudtak valósítani. 41 4.9 ábra: Lightflowval megjelenített Cornell doboz A Lightflow Rendering Tools egy hatékony proxy megoldásnak köszönhetõen képes automatikusan kezelni az elosztott képszintézist. Támogatja mind a párhuzamos, mind a többszálú rendszereket, így a képszintézis és az animáció készítés folyamatát jelentõsen felgyorsítja. 4.10 ábra: Lightflowval megjelenített szobabelsõ 42 A globális illuminációs elvû képszintézise egy kombinált algoritmusra épül, amely az elosztott sugárkövetés (distributed ray-tracing), a

radiozitás (radiosity), egy caustics megjelenítõ és volumetric rendering módszerek elõnyeit ötvözi. A hibrid módszer igen valószerû képeket eredményez, amelyeket különbözõ textúrázási megoldásokkal (subpixel 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.13 Desktop Radiance Greg Ward Larson a Lawrence Berkeley National Laboratory alkalmazásában 1985 és 1997 között fejlesztette ki a Radiance nevû világítástervezõ és képszintézis programcsomagot. A Radiance hosszú ideig csak Unixokon mûködött, majd az ADELINE projekt keretében Microsoft DOS-ra is implementálták. Az utóbbi években a Microsoft Windows operációs rendszereinek nagyfokú elterjedtsége miatt jelentõs igény mutatkozott a Radiance csomag Windows alatti elérhetõségére. Ezt az igényt próbálja meg kielégíteni a Desktop Radiance, amely a Windows alatt futó AutoCAD

rendszerrel integrálta a Radiance programcsomagot. 4.131 Radiance A Radiance ([27]) célja az volt, hogy a világítástervezõknek és az építészeknek olyan eszközt adjon a kezébe, amely egy térrész megvilágítási szintjeit, megjelenését még a megé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 Radiance RAD fájl formátumára. Ezek közül a legfontosabbak az MGF (mgf2rad) és a WaveFront OBJ (obj2rad) formátumokról konvertáló programok. A csomag legfontosabb eleme a szimulá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épek kapható. A sugárkövetés nyolcasfát alkalmaz

térpartíciónáló algoritmusként A számítás három fõ részre osztható: a direkt megvilágításra, valamint a diffúz és a spekuláris indirekt 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életesen spekuláris felületekrõl továbbverõdve - érkezõ fénymennyiséget jelenti. A nagy fé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ális fényforrások módszerével oldja meg. Ez azt jelenti, hogy az ilyen felületeket úgy kezeli mintha á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ési vagy áteresztési) irányba való továbbindításával kezeli. Nem tökéletesen spekuláris fénytovábbítás esetén pedig Monte Carlo mintavételezést alkalmaz a

visszaverõdési / áteresztési irányra. 43 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 indirekt komponens a felületeken lassan változik. Megjegyezzük, hogy ez az alapfeltételezés a radiozitá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ót elraktározza a késõbbi interpolációk javítására. Ezt a technikát irradiancia cachelésnek hívják. A Radiance képes az elõzõekben leírt alap szimuláción felül másodlagos fényforrásokat is kezelni. Ez azt jelenti, hogy a képszintéziskor figyelembe veszi a Napsugárzást, az ablakokon beszûrõdõ, illetve minden más módon "bejutó" fényt. Ezt a szimuláció elõtt egy elõfeldolgozási lépésben teszi meg, amellyel a végsõ képszintézis hatékonyságát és pontosságát növeli.

4.132 AutoCAD Az AutoCAD ([26]) a világ legelterjedtebben használt CAD rendszere. A személyre illetve 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.133 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át DXF / DWG fájljait képes beolvasni, azaz importálni. Kimentésnél - a DXF / DWG-n felül - lehetõséget ad 3DS fájlok mentésére. 44 4.12 ábra: Desktop Radiance-szal megjelenített épületbelsõ 4.144 Desktop Radiance A Desktop Radiance ([28]) egy olyan modul, amely beépül az AutoCAD-be. A Desktop Radiance ö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ület tervrajzát, amelyhez - a modellezési fázisban - hozzárendeli a Radiance számára szükséges elemeket (fényforrásokat, anyagokat, bútorokat, kamerákat stb.) Ezekbõl az elemekbõ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 a szimuláció következik, amely a színtérben szereplõ fény mennyiségét határozza meg. A szimuláció során kiszámolt értékekbõl ún. szkenáriók jönnek létre, amelyek az interaktív képszintézis alrendszerrel (rview) megtekinthetõk. Az itt beállított paraméterek alapján a képszintézis alrendszer képeket készít, amelyeket utólag elemezni és manipulálni lehet. 45 A fényviszonyok meghatározására a Simulation Manager szolgál. Miután az

AutoCAD rajzban elhelyeztük és beállítottuk a Radiance számára szükséges elemeket, indítható a szimuláció. A számítások során a Radiance nemcsak a mellékelt elemek tulajdonságait veszi 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 winimage programmal) végeztethetõ. A Radiance egyik elõnye a valós világ nagy dinamikai tartományának kezelése az RGBE képformátumban. A képek vagy skalár adatokat, vagy luminancia / illuminancia értékeket tartalmaznak. Ezt azért fontos kiemelni, mert a skalár képek nem alkalmasak analízisre, hisz ezekbõl hiányoznak a valós világ nagy dinamikai tartományának értékei. 4.135 Könyvtári elemek A projekt során nem tekintjük feladatunknak anyag, fényforrás stb. könyvtárak létrehozását és azok ArchiCAD modellekben

történõ elhelyezését. Ennek ellenére fontosnak tartjuk kiemelni, hogy a Desktop Radiance könyvtári elemei milyen jellemzõkkel bírnak, hisz ez a tudás a késõbbiekben az ArchiCAD fejlesztésénél is hasznosítható. A 413 ábrán az anyag-, a 414 ábrán pedig a fényforrásjellemzõk megadására szolgáló dialógus ablak látható. 4.13 ábra: fizikai alapú anyagjellemzõk megadása a Desktop Radiance-ban 46 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) 47 4.14 trueSpace A Caligari vállalat 1994-ben mutatta be a trueSpace-t ([29]), amely azóta már több verzió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 hibrid radiozitás (radiosity), a légkör megjelenítése, a pontos ütközés meghatározás, NURBS-ok használata, a csontváz-deformáció stb. A trueSpace a nyitott architektúrájú alkalmazások körébe tartozik, amely a program gyors, egyszerû továbbfejlesztését teszi lehetõvé. Ahogy már

láttuk a 3D Studio MAX és a Maya esetében is, ez azt jelenti, hogy plugin-okat írhatunk, amelyek a futtatás során a programhoz dinamikusan szerkesztõdnek. Egy plugin inicializálás után képes egy dialógus ablakot felrakni, a programból bármilyen paramétert átadhatunk neki, amelyeket a beépített függvényeken keresztül visszaadhatunk a trueSpace-nek. A plugin-okat bármilyen fordító segítségével megírhatjuk, de jelenleg az elsõdlegesen a Microsoft Visual 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 a globális illuminációs módszer csak a diffúz módon sugárzó felületeket és fényforrásokat képes kezelni, a felhasználó utólagosan sugárkövetéssel (ray-tracing) a spekuláris energiaátvitelt is szimulálhatja. A teljes képszintézis folyamat kezelése felhasználóbarát 48 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). A felületi és égbolt fényforrások a radiozitás hatékonyabb használatát segítik elõ. A térfogati fényforrások a fényforrás szórásának modellezését támogatják olyan helyzetekben, amikor a fény az atmoszférán halad keresztül. 4.15 ArchitechPC Ebben az alfejezetben az Architech.PC nevû CAD rendszert mutatjuk be, amely fizikai alapú 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ének fejlõdési stádiumaival. Az egyes lépéseknél felhalmozódott tapasztalatok nagyon hasznosak lehetnek az ArchiCAD képszintézis alrendszerének újratervezésekor. 4.151 A kezdetek A tervezõ program fejlesztése a 90-es évek elején kezdõdött, amelynek

már õse is közel tíz éves múltat tudhatott maga mögött. Akkor már mûködött egy árnyalt és vonaltakart megjelenítési mód is, amelyekkel szemben az új tulajdonosok erõs fenntartásoknak és elé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ír felületen tizedmilliméteres pontossággal képes vonalat rajzolni, így a raszteres eljárás alkalmatlan. Természetesen a korai változat is eredményként a takart vonalszakaszok sorát adta. E téren akkor még az AutoCAD is meglehetõsen lassú volt Egyszerûen elfogadott, á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. 49 Ekkortájt az Architech.PC egyik fõ feladataként tûzte ki ennek az eljárásnak a lecserélését jóval gyorsabb és pontosabb megoldásra. Utóbbira azért is szükség volt,

mert az ö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, és más kisebb ötleteknek köszönhetõen lényegesen gyorsult és precízzé vált. A korábbi eljárás egy már bonyolultnak számító épület látványán 50 órát dolgozott és ezután 15-30 perces 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 ehhez sikerült alkalmas és gyors árnyékvetõ eljárást kidolgozni. Ez abban az idõben nem volt igazán elterjedt. A kiállításokon általában egy alapsíkra, padlóra vetített napfény árnyaka volt a képeken, amely meglehetõsen hiányos és elégtelen eljárás. A módszer legfõbb baja, hogy az így átadott adatokban kell feltüntetni mi a "padló", amely erõsen sérti azt a

leí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õ és ugyanezekkel a problémákkal bír. Sajnos ezek a megoldások ma újra elõkerültek az OpenGL elterjedésével. 4.152 Az új képszintézis alrendszer Ezzel megkezdõdött egy új képszintézis program fejlesztése, amely a kortársaihoz képest négy lényeges elõnnyel bírt: Az elsõ a pontos árnyékvetés hatékony számítása, amelyet pontszerû fényforrásokra alkalmazott. Ez egy lényeges hatáselem, mert a vetett árnyékok kapcsolatot teremtenek a tárgyak között. Árnyékok nélkül a bútorok csak "lebegnek" a padló felett Noha az Architech.PC fejlesztõi kipróbáltak más e célra elterjedt eljárást is, de ezek árnyékai elmosó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 a finom á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ák az ún. reciprok négyzetes törvényt, amely a fizikában fontos szabály pontszerû sugárzók esetén. Más programokban ezt a viselkedést befolyásolni lehet, és szerencsére ezt a karakterisztikát is ki lehet választani. Az ArchitechPC fejlesztõi ragaszkodtak a fizikai modellhez, hiszen ha nem ezt tennék, a legcsekélyebb mértekben sem tudtak volna a fényforrások teljesítmény-arányát modellezni. Ez homlokzati megvilágításnál, ahol az interreflexió és az égbolt fény elhanyagolható, valamint a fényforrások pontszerûnek tekinthetõ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 az Architech.PC-t ezen a területen is használták Mindezeken felül a képek valószerûek lettek. Különösen az épületbelsõk lámpafényei jelentek meg valószerûen 50 A harmadik fontos újítás egy a valóságban nem igen tapasztalható, fizikailag azonban lehetséges és korrekt reflexiós modell bevezetése volt, amelyet célszerû volt használni a diffú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ékkel dolgozhattunk, nem egy semmitmondó homogén színfoltot kaptunk, amelynek semmi mé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ámolt lá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ûleg ez az oka annak, hogy kötelezõ érvényérõl a konkurens programokban lemondtak. Más szavakkal: emiatt a képen nagy dinamikai különbségek adódnak. Ezt a hatást a fényképészek igen jól ismerik. Ezért a belsõ terek fényképezésekor igyekeznek deríteni, a lámpa, illetve az ehhez közeli falfelület fénytócsáját a képkivágáson kívülre hagyni, mert a fényérzékeny anyag igazából csak kis dinamikát tud leképezni. Az ArchitechPC viszont élhetett a dinamika expanzió és kompresszió lehetõségével, amellyel a fotós csak a nagyított képek elõhívásakor dolgozhat. Az ArchitechPC algoritmusa önmûködõen kalibrá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 pixelekhez tartozó fényértékek elõírt százaléka esik. Ezzel lehetõvé vált, hogy a képek készítésekor viszonylag kevés selejtet kapjunk, és amennyire lehetséges volt, mégis csak a fizikailag modelleztü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õ kamera alkalmazkodá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 kellett felruházni. Ezáltal a mozgás a különbözõ fényviszonyok közt természetes hatással bírt 4.153 A második verzió A program második változata teljes újraírás után született meg, de a sok apró újdonság közül csak egyet emelnénk ki. Az ambiens fényérték megválasztása eleve nem lehet más mint csalás, hiszen az interreflexiós járulékot cseréljük le jóval egyszerûbbre. Vegyük azokat a fényeket, amelyek a képre kerültek, átlagoljuk ki, a színtartalmát egy bizonyos mértékben hagyjuk meg és nevezzük ezt ambiens fénynek, amelyet ezután a felületek albedójával szorzunk. Ez a "pofonegyszerû" elv harmóniát teremt a mesterkélt ambiens fény erõssége, színe és a fizikailag pontos közvetlen megvilágító hatás között. 51 Az Architech.PC célja az interreflexiók hû modellezése is volt Ráadásul az említett esetekben a megjelenítõt már

világítástervezéshez használták, így ez a funkció igen kívánatosnak látszott. Akkor reményt egyedül a radiozitás (radiosity) módszer vagy más néven a véges elem feladat megoldása adott. Ha figyelembe vesszük, hogy egy épületi modell már egészen nagy bonyolultságot is elérhet, másrész az akkor használatos gépek teljesítménye durván század akkora volt, mint a maiaké, akkor ez a funkció talán kicsit fölöslegesnek tûnhet. Azonban az ArchitechPC fejlesztõi azt látták, hogy ha sikerül a számítást egy éjszakányi idõ alá szorítaniuk, akkor sok ügyfelük örülne és használná a szolgáltatást. Az akkor ismert megoldások számítási ideje a használt elemek számának négyzetével volt arányos, amely haladás jelent ahhoz képest, amikor a memória igény is hasonlóan nõtt. Nyilvánvalóan ezek a módszerek alkalmatlanok arra, hogy több százezer felületelem fényértékeit kiszámíthassuk. A szakirodalomban közölt

legbonyolultabb modell 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ük az elemek számával lineárisan növekvõ mûveletigényét, amely elõreláthatólag igen drasztikus 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önnyen kreálhattunk olyan fényviszonyokat, amelyek között a transzilluminációs megoldás is rettenetesen 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 azt mutatták, hogy 420 ezer elemre is kiválóan mûködik. Gyakorlatilag egy nap alatt megvolt a megoldás. Bár a lövõ lépés nem lett kipróbálva, de a becslések szerint ez akár 4-5szörös gyorsulással járt volna Szintén némi gyorsulást jelentett a kvázi véletlen számok

használata. Bár még megoldatlan problémát jelentett a kapott geometria elemekre bontása, amelyben leginkább nyugtalanítónak a síklapokkal közelített görbülõ felületek szögletmentesítése látszott. 4.154 A harmadik verzió Bár itt a siker egyértelmû és lelkesítõ volt, az Architech.PC mégsem ebbe az irányba haladt tovább. A trend azt mutatta, hogy a képek "felöltöztetésére", a textúra és mindenféle anyagok megjelenítésére nagyobb szükség volt. Visszatekintve úgy tûnik sikerült olyan paraméterezést és ennek megfelelõ párbeszédablakot választani, amely viszonylag egyszerû volt, mégis rengeteg hatás beállítható volt rajta, és ezek megfeleltek az alapvetõ fizikai modellezési elvárásoknak is. Az ArchitechPC használt szolgáltatása volt a "transzparencia maszk" képpel való textúrázása. Ezzel tetszõlegesen bonyolult kontú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ínes képeken mutatta be, ahol a meghökkentõ részletezettséggel kidolgozott, felettébb díszes kovácsoltvas kapu legfinomabb cirádája sem hiányzott, míg bent a termek falait stukkó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 puszta látvány, amelynek elõnye mûszakilag nem feltétlenül racionális, a való életben piaci eszközzé válik. 52 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 egy irányhoz képest megadott szög alatt álló Nap adataiból és az égbolt felhõ lefedettségi fokszá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 az Architech.PC fejlesztõi azért vetettek el, mert ezen hátterek nem garantálják, hogy a horizont 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õs táj. Tehát az ArchitechPC reális égboltozata igen jól festett Ráadásul még azzal az elõnnyel is bírt, hogy beépítettek egy opciót, amellyel a csillogó felületek valódi tükrözést kaphattak. Ez úgy történt, hogy ezeken a felületeken az égbolt képe a beállított mértékben tükrözõdött. Ezt külsõ nézetekben volt célszerû használni, mert egy sötét szobáról számolt képen ez igencsak zavaró, érthetetlen lett volna. Ez annak volt köszönhetõ, hogy a tükrözés mögött a takarási

feladatot nem oldották meg, vagyis a tárgyak ekkor még egymáson nem látszódhattak, csak a nagyon távoli környezet. Viszont az üveg-acélpaloták, vagy úszómedencék ábrázolásában ez igen hasznos és látványos volt. Nos ezen a fokon a megjelenítõ annyi újdonságot és bevált megoldást tartalmazott, hogy végül már ezekrõl lemondani nem lehet. Ez a magyarázata annak, hogy a radiozitás módszer háttérbe szorult. Természetes volt a tükrözõdés, a fémes hatás, a textúrák haszná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 a részletezettséget csak háromszögek millióival helyettesíthették volna. Az azonban látszott, hogy a mélységi pufferre alapozott módszer bonyolulttá vált. Néhány nem túl gyakori esetben túlságosan lelassult, így az Architech.PC fejlesztõinek érdeklõse a sugárkövetés (ray-tracing)

eljárás felé fordult. 4.155 A negyedik verzió A megjelenítõ negyedik verziójában, a takarási megoldások teljesen lecserélõdtek a sugárkövetés eszközeire. Ez egyszerûsített, de az is igaz, hogy a kritikus objektum és fé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 és lá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 a képpontokhoz tartozó értékeket bármilyen sorrendben lekérdezhettük - a hatékonyság romlása nélkül. Ezáltal lehetõség nyílt kifinomultabb csipkézettség csökkentõ (antialiasing) módszerek kipróbálására Végül is az ún jittering beépítésével jobb eredményt kaphattunk, mint a korábbi módszerrel kétszer annyi idõ alatt. Másrészt így az Architech.PC a kép generálását folyamatában mutatta: elõször nagy

pixel mérettel és kisfelbontással, majd egyre finomodva. Az eljárás megszakítható volt, amelyet a nézõpont változása idézett elõ. Ezt követõen - az új beállítások szerint - megint számolni kezdett és így e módszer gyors gépen a valósidejû bejárás illúzióját adta. Amikor a 53 mozgás leállt, a számítás folytatódott és a kép véglegesre finomodott. Bár ez utóbbi mégsem vált a termék részévé, mert sajnálatos módon a modulok hatékony integrációja nem volt lehetséges. Mindenesetre a kezdeti aggályokat, amelyeket a sugárkövetésrõl kialakult kép táplált, azaz, hogy lassúnak tartják, e megoldások eloszlatták és rugalmassá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 ennek kihasználása. Bár az eszköz bonyolult, de legalább konzisztens A gyorsító hardverek és OpnGL megvalósításaik viszont állandó problémát jelentettek. Ugyanis a

gyártók az OpenGL szolgáltatásaiból csak néhány alapvetõt végeztettek el a célhardverrel, a többit szofveresen emulálták. Ráadásul a specifikációnak nem megfelelõ, vagyis hibás eredményeket is adtak. Ebben a "káoszban" indult és zajlott az ArchitechPC fejlesztése A fejlesztõk sok olyan cikket töltöttek le az Internetrõl, amelyek a szolgáltatások cseppet sem triviális kiaknázásával képesek voltak domborzati textúrákat, árnyékokat és lámpák fényét, valamint tükrözést is szimulálni. Ezekrõl azonban kiderült, hogy ez az akkor elérhetõ gyorsítók képgenerálását annyira lelassítja a szoftveres emuláció miatt, valamint minden hibát olyannyira kiemel, hogy célszerûnek látszott csak az alapszolgáltatásokat igé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, de a képek az olcsóbb

hardvereken is valós idõben és textúráik teljes pompájában jelentek meg, 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 és bonyolultabb eljárásokra már nem volt igény. Ha mégis volt ilyen igény, akkor az Architech.PC fejlesztõi a felhasználóknak azt ajánlották, hogy használja a lassabb, de amúgy minden tekintetben jobb sugárkövetõ eljárást. 4.156 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, de ezek beépítésére már nem kerülhetett sor, mert a cég csõdbe jutott. Az ArchitechPC fejlesztõ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öbb vá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 417 és 418 á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ív bejárása lehetõvé vált. A feladat megoldására az ArchitechPC fejlesztõi nem az említett mó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 a kódot: a sugárkövetéssel együtt használ egy kritikus modult, amely mérnöki szemmel nézve kedvezõ megoldás egyszerûsége miatt. Itt az ArchitechPC lemondott a csillogó hatásokról, csak diffúz felületekkel dolgozott. 54 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 és szoftvermérnöki elégtelenségbõl fakadt. Ennek az lett a következménye, hogy ezek többnyire külön interfésszel lettek a rendszerhez csatolva, amely így ésszerûtlenül bonyolulttá, szolgáltatásaiban nem igazán kihasználhatóvá vált. A közös interfész megtervezése égetõen fontosnak látszott. A terv az volt, hogy az MVC (Model-ViewController) architektúra alapján mûködjön Ez gondoskodott volna a változások robosztus kezelésérõl. Vagyis ha a modell egy elemén módosítunk, akkor annak nézetei is egy szabatos mechanizmuson keresztül módosultak volna. Az OpenGL ún megjelenítési listáival (display list) kiegészítve az interaktív folyamatok optimális számítási szükséglettel, valamint optimális memória kihasználással mentek volna végbe. Itt egy fontos felismerés volt, hogy az eddig elõállított köztes adatok (például háromszög- és vonallisták)

tárolása szükségtelenné válik. A megjelenítõ feladata az említett megjelení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öztes adatok tárolása, a program ezeket megelõzõ fázisaiban már nem. Ez azért nem igaz, hisz ezek 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 55 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 olyan univerzális eljárások készülnek, amelyeket egy szintén univerzális interfész tesz lehetõvé. Vagyis egy konkrét építészeti elem egy elõírt eljárása önmagát geometriai primití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õs egyszerûsödést és nagyobb hatékonyságot vártak. Egy távolabbi tervben a kétdimenziós megjelenítést cseréltük volna le erre, és egyáltalán minden grafikus mûveletet - beleértve a 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 össze valamilyen modellezõ alkalmazással, hanem önálló programként funkcionálnak. Ilyenkor a modellezõ programban létrehozott színtérmodellt a képszintézis program számára elérhetõvé kell tenni. Az esetek igen nagy százalékában ez azt jelenti, hogy a két program közötti kommunikáció megvalósítására közbülsõ fájlt használnak. 56 Ebben az alfejezetben néhány jellemzõ globális illuminációs elvû képszintézissel rendelkezõ programcsomagot tekintünk át, amelyek nem rendelkeznek modellezõ

alrendszerrel. A kiválasztott programok két csoportba sorolhatók: kommerciális termé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ézis szempontjából érdekes formátumokat írjuk le. Ezt a tudást felhasználva a 6 fejezetben definiáljuk a projekt során elkészülõ önálló program interfész követelményeit. 4.21 Lightscape A Lightscape ([30]) egy fejlett világítástervezõ program, amelyet az évek során számos cég tudott magáénak. Jelenleg az Autodesk vásárolta meg és ajánlja a mental ray mellett professzionális képszintézis alkalmazásként. 4.211 Könyvtári elemek A Lightscape is fizikai alapú anyag- és fényforrásjellemzõket használ, amelyekbõl könyvtárakat hozhatunk létre. A 419 ábrán az anyag-, a 420 ábrán pedig a fé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) 57 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.212 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ányoknak tekinthetünk, így ezzel a döntéssel mégiscsak sikerült a színtérmodellek igen széles körét lefedni. 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 a 2D / 3D CAD rendszerek kötelezõen támogatott formátumai közé került. Ez nagyrészt annak köszönhetõ, hogy az USA-ban csak DXF-ben lehet tervrajzot beadni. 3DS: a 3D Studio DOS-os fájl formátuma, amely általános, háromdimenziós objektumok 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 ipari szabvánnyá vált. További részletek a 6 fejezetben olvashatók 58 4.213 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 az eredményképek nemcsak valószerûek, de egyben a megjelenített színtérbeli fényeloszlás pontos "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át kiszámolja, a képszintézis során a puha árnyékokat (soft shadows) és a felületek közötti szí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éggel mozoghat. 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ás módszere volt. Ez azt jelenti, hogy minden

iterációs lépéskor a legnagyobb energiával rendelkezõ felületet tekintjük fényforrásként; a felület által emittált és visszavert fé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ég van arra is, hogy a felhasználó megállítsa az iterációt és néhány paraméter módosítása utá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én a sugárkövetést használja az árnyékok és az áttetszõ felületek kezelésére. 59 Bár a véges elemes iteráción alapuló módszereknek nagy memóriaigényük van, a progresszív finomításnak és a sugárkövetésnek

köszönhetõen ez az érték nem annyira magas, mint más módszereken alapuló programoknak. A színtérbeli fényviszonyok meghatározásakor - a Desktop Radiance-hoz hasonlóan - a Lightscape is figyelembe veszi a helyszín földrajzi koordinátáit és a szimulálni kívánt idõ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ámolt fényeloszlás értékeket fel lehet használni a színtér fényviszonyának analizálására. A Lightscape-pel a modellben levõ fényeloszlást pszeudo-színezési módszerekkel lehet megjeleníteni, illetve a megvilágítási értékek számszerû kijelzésével. A Lightscape interaktí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 a poligonhálót (mesh)

textúrává képes konvertálni. Az így létrehozott textúrát síkfelületekre ráhúzva olyan hatást kelt mintha nagy komplexitású színteret szintetizáltunk volna. Tehát ezzel a módszerrel a színtér komplexitását jelentõsen csökkenthetjük. Ezeket a textúrákat az elõzetes kép alapú szintézisben (image based rendering) imposztoroknak hívják. 4.22 Artlantis Az Artlantis ([31]) az 1985-ben alapított Abvent leghíresebb és az építészek körében igen elterjedt képszintézis programja. Jelenleg a 40-s verziónál tartanak, amely az eddigi hibrid (pásztaalapú és sugárkövetéses) képszintézisébe bevezette a globális illuminációs elvet 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 60 • globális illuminációs elvû képszintézissel rendelkezõ, modellezõ alrendszerrel nem integrált megoldás 4.221 Egyszerû

felhasználói felület Az eddig bemutatott programok nagyrészt professzionális felhasználóknak készültek, így elég bonyolult kezelõ felülettel rendelkeznek. Az Artlantis egyik nagy pozitívuma a rettentõ 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 kell bonyolult interfészi elemeket megtanulnia. A felhasználónak azon sem kell gondolkodnia,

hogy milyen nézetet válasszon, hisz a perspektív nézetet a preview ablak biztosítja, az axonometrikus (felül, oldal, elöl) vetítéseket pedig az interaktív paraméter beállításra szolgáló ablak. Ez a fajta egyszerûsítés jelentõsen csökkentheti a munkára fordított idõt. Bár hozzá kell tenni, hogy professzionális felhasználókban pont az ilyen egyszerûség okozhat frusztráló hatást is. 61 4.222 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õk beállítására szolgáló dialógus ablakok nem túl zsúfoltak, szinte csak a minimális funkcionalitást biztosítják. Természetesen, egy ennyire a használhatóságra kihegyezett programtól nem várható el, hogy fizikai alapú anyagok és fényforrások használatát támogassa. A 425 ábrán az Aged Copper nevû anyag jellemzõit mutató

dialógus ablakot láthatjuk. Az ábrából jól látszik, hogy az eddig bemutatott programokhoz képest az Artlantis milyen kevés adattal próbálja a professzionális alkalmazások képességeit utánozni. 4.24 ábra: kamera adatok beállítása az Artlantisban 62 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 63 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. A 3.5-ös verzióban végre megjelent a párhuzamos fényforrás (heliodon) lehetõsége, ám a globális illuminációs módszerek számára fontos területi fényforrásokat továbbra sem használja. A 4.26 ábrán egy szpot lámpa tulajdonságainak beállítására szolgáló dialógus ablakot mutatunk 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 nincs lehetõség arra, hogy kiválasszuk melyik árnyékvetõ módszerrel kívánunk dolgozni. A 4.0-s verziótól kezdve az Artlantis nem éles árnyékokat (soft shadows) is meg tud jeleníteni. 4.223 Kezelt fájl formátumok Az Artlantist számos építészeti CAD rendszerhez ajánlják kiegészítõ programként, ezért számos formátumot képes használni. Az Artlantis a következõ fájl formátumokat képes beolvasni, 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 rendszer nem képes kezelni. FACT: átlagos gépeken (PC, Macintosh) elérhetõ, filmek animációs betéteinek

elkészítésére is alkalmas képszintézis programok között az EletricImage fontos pozíciót tölt be. A FACT az ElectricImage saját 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ére fejlesztettek 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 ipari szabvánnyá vált. Érdekes, hogy az Artlantis csak a kissé elavultnak tekinhetõ 10s 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ájljait kezelni, valójában ezt a formátumot kezeli. 4.224 Globális illuminációs megoldása Az Artlantis

marketing és fejlesztõi részlege semmilyen információt nem árul el a globális illuminációs megoldásával kapcsolatban, ezért saját tapasztalatainkra hagyatkozunk. 64 Sugárkövetés paramétereinél a mélység szintje állítható. Ez alapján úgy gondoljuk, hogy nem orosz rulett típusú sugárkövetõ algoritmust használ. A sugárkövetéssel képes kezelni a tükrözõdéseket és áttetszõ objektumokat. Elõbbire jó példa lehet a 427 á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õl sejthetõ, 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 (color bleeding) 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õ a színszivárgás hatása. Ez is mutatja, hogy az Artlantis csak imitálja a globális illuminációs képszintézis módszerek hatását. A 428 á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ó a színszivárgás, ugyanis a színtérben az ambiens fényt igen magasra tettük és ennek hatására a párhuzamos fényeket számoló algoritmus jól kihozza a felületek közötti kölcsönhatásokat. 4.27 ábra: Artlantisszal megjelenített üvegpegazus 65 4.28 ábra: lokális és globális iluminációs modellek hatása az Artlantisban 4.23 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 a lé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éget nyú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ézis szoftverek 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éhez vezetõ ú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 66 A projekt egyszemélyes vezetõje és programozója a leuveni egyetem tanára, Philippe Bekaert, aki a RenderPark fejlesztését doktori disszertációjához kapcsolódóan kezdte

el 1993 õszén. Bekaert 2000-ben fejezte be doktori disszertációját, a RenderPark fejlesztése azonban 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. A projekt azonban nem nyílt forráskódú (nem open-source). A forrásban változtatni csak Bekaert tud. 4.231 Beépített algoritmusok Objektum-térbeli radiancia algoritmusok: • • • • • Galerkin radiosity (mind gyüjtõ, mind lövõ típusú). Felkészítve a hierarchikus tesszellációs finomításra, magasabb rendû approximációra, clustering-re és viewimportance-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ó radiosity algoritmusok. Ezek közül a három legfontosabb: o Pattanaik particle tracing algoritmusa o Keller kvázi-Monte Carlo radiosity

módszere o 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él második menetként) kétirányú sugárkövetés fotontérkép 4.232 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 a poligonok radiosity-vel meghatározott színét menti el színinformációként a vrml file-ba, és így globális illuminációs színterek bejárása lehetõvé válik egy tetszõleges VRML böngészõ program használatával. a RenderPark X-Windows/Motif alapra épül, ezért ilyen stílusú felhasználói interfésszel rendelkezik. 67 - - -

OpenGL-es hardver támogatást is kínál (MesaGL-t könyvtárat használja), ezért a programon belül nagyon egyszerû (CosmoPlayer szerû kezelõi felülettel) és gyors a 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 a szoftver parancssoros felparaméterezésére is. Ezzel akár egy távoli géprõl batchfuttatásokat is indíthatunk a programnak meg lehet adni egy külsõ programból jövõ canvas-t is, hogy a ké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 72 C/C++ compiler) SUN/Solaris (GNU gcc/SUNs cc + GNU make) Linux (GNU gcc or egcs and GNU make) Megjegyzendõ, hogy sem Macintosh, sem Windows

platformon nem futtatható. Mivel technológiai partner erre a két platformra fejleszt terméket, a mi projektünk számára ezek a platformok nagyon fontosak. 4.30 ábra: RenderParkkal megjelenített Cornell doboz 68 4.233 Új algoritmus fejlesztése A RenderParkhoz új algoritmust fejleszteni nem túlságosan nehéz. Nagyvonalakban ez a következõket jelenti: kell készíteni egy újabb fájlt (például UjRenderingAlg.cpp) és ebben implementálni kell egy RAYTRACINGMETHOD vagy RADIOSITYMETHOD tí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ának menüjébõl már ki is lehet választani az UjRenderingAlg nevû algoritmust, miután egy színteret betöltöttünk a RenderParkba. A RAYTRACINGMETHOD struktúra feltöltésénél meg kell adni például az új algoritmus nevét, és rengeteg függvényt, amelyeket a RenderPark keretrendszere akkor hív amikor

az UjRenderingAlg-ot inicializálni kell, képet kell szintetizálnia, amikor a felhasználó be szeretné állítani az UjRenderingAlg paramétereit (ilyenkor egy Setup Dialogot 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ájlba menteni. A függvénypointerek beállításával és a függvények megírásával rendering algoritmusunk tökéletesen integrálódik a RenderPark keretrendszerébe: használni tudja a RenderPark belsõ globálisait, térpartícionálással támogatott sugár-háromszög metszéspontszámítási algoritmusait, absztrakt Material osztályait a korrekt fizika alapú anyagmodellek megvalósításához stb. 69 70 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 rendszerek ké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észlege használhat. A marketing részleg a jelenlegi rendszer képességeinek leírására, más rendszerekkel való összehasonlításra használhatja. Az ArchiCAD tervezõi és képszintézis alrendszerének fejlesztõi pedig a jelenlegi képességek továbbfejlesztésénél, új funkció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ással o 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ámpa o 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ég o spekuláris visszaverõ képesség o emittáló képesség o áttetszõség lokális illuminációs megvilágítási modell o diffúz visszaverõdés Lambert BRDF modellel o 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 71 5.2 Az ArchiCAD hiányosságai • • globális illuminációs megvilágítási modell o fizikai alapú anyagok és fényforrások o területi fényforrások o tükrözõdõ felületek o 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 sok extra 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 gyorsan megkaphatjuk 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ív véleményünket szeretnénk ismertetni. A javaslatokat munkaigényük és fontosságuk szerint két szekcióra osztottuk: rövid- és hosszútávúakra. 72 5.41 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 csak emittá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ás o á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.42 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 a következõk: o fizikai alapú anyag és fényforrás könyvtári elemekként kezelése o tükrözõdõ felületek o 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 gyorsan megkaphatjuk 73 74 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 rendszer magja fölé különálló, de a mag szolgáltatásaira támaszkodó programokat, ún. add-onokat lehet 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 csak az ún. háromdimenziós I/O add-on-ok és az ún rendering add-on-ok ismertetésével foglalkozunk, amelyek a globális illuminációs elvû program és az ArchiCAD közötti kommunikáció offline és online módjait végzik. Ebben a fejezetben a két alternatíva ArchiCAD-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 bizonyos formátumú fájlt mentünk, amelyet a különálló alkalmazásként megvalósított globális illuminációs elvû program be tud olvasni. Tehát ez a közbülsõ fájl tartalmazza azokat az adatszerkezeteket, amelyekre mindkét programnak szüksége van. A 611 pontban azt vizsgáljuk meg, hogy hogyan lehet ezt az ArchiCAD add-on rendszerében megvalósítani, a 6.12 pontban pedig a lehetséges fájl formátumokat mutatjuk be 6.11 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 is alkalmazni lehessen, óriási igény merült fel a modellek különbözõ fájl formátumokban való exportálására. Az ArchiCAD lehetõséget nyújt mind a kétdimenziós tervrajz, mind a háromdimenziós modell exportálására. Utóbbi kategória megvalósítására a há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 ponton tudja szolgáltatni 1 : a File menü Save As funkciójánál és az Image menü Create FlyThrough menüpontjánál. Az elõbbi a háromdimenziós modell lefényképezésére és / vagy szerkesztésére szolgáló 3D Window aktuális kamera beállításaival menti el a modellt. A Create Fly-Through funkció pedig a háromdimenziós épületmodell egy bejárását jeleníti meg, illetve menti el. Az épület bejárásához az alaprajzon el kell helyezni néhány perspektív kamerát, amelyekre az ArchiCAD egy görbét illeszt. Ez a spline mutatja a bejárás útvonalát; a kamerák pedig az animáció kulcskockáit (keyframe) jelentik. A projekt hosszú távú céljai között szerepel a kivárható idõben elkészülõ animációk készítése is, ezért olyan I/O add-on-t írunk, amely mind a két helyrõl engedélyezi a belépést. 1 Az ArchiCAD-ban elérhetõ funkciók, menük, menüpontok neveit az angol nyelvû ArchiCAD verzióból vettük. 75

Minden add-on tartalmaz egy ACNF nevû erõforrást (resource), amelyben az add-on jellegzetességeit lehet leírni. Ebben az erõforrásban kell megadni, hogy háromdimenziós I/O add-on-t írunk, amely támogatja az add-on elérését mind a Save As, mind a Create Fly-Through menüpontokból. 6.12 Fájl formátumok Az offline megoldásoknál a legfontosabb kérdés, hogy a két alkalmazás a kommunikációhoz milyen fájl formátumot használjon. Ahogy már a 4 fejezetben kiderült, számos alkalmazás használ saját formátumot, de a többség azért 1-2 elterjedtebb formátumot is támogat. Mivel ez utóbbi lehetõség nélkülözhetetlen ahhoz, hogy olyan globális illuminációs elvû alkalmazást készítsünk, amelyet bármely CAD rendszerhez lehet 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ájl formátumban (VRML, MGF, 3DS stb.) írtak le Ezek

használhatóságáról sem kívánunk lemondani, hisz ezzel elõsegítjük a rendszer széles körben alkalmazhatóságát, illetve más ké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.121 SCE formátum A SCE formátumot néhány évvel ezelõtt a leuveni egyetemen fejlesztették ki, de aztán feledésbe merült - köszönhetõen az elterjedtebb fájl formátumok használatának. Mivel a leuveni 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ó, fizikai alapú képszintézist támogató formátummá nõtte ki magát. A grafika csoport eddigi globá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 jogosan merü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ájl formátumnál, így a SCE-nél is, számos megkötéssel lehet csak konvertálni az empirikus jellemzõket fizikai alapúakra. Ezt a konvertálást az add-on fogja végezni 6.122 MGF formátum A legelterjedtebb, legismertebb globális illuminációs elvû program Greg Ward Radiance nevû 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ött rá, hogy óriási igény lenne egy egyszerû, általánosan alkalmazható, de mégis fizikai alapú 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 76 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ább nö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ében létrejövõ alkalmazásnak mindenképpen ismernie kell az MGF-et. Ez a Graphisoft szá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 tud nyújtani a fizikai alapú képszintézist igénylõ felhasználóinak. Természetesen itt is

az addon fogja az empirikus jellemzõket fizikai alapúra konvertálni és vissza 6.123 VRML formátum A ‘90-es évek közepén az Internet robbanásszerû elterjedésének köszönhetõen hamar igé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 10-s verziója, amely még erõteljesen támaszkodott az OpenInventorra. A 20-s verzió egy teljesen megújult formátumot jelentett: lényegében újradefiniálták a leíró nyelvet. Késõbb 1-2 apróbb módosítással VRML97 néven szabványosították ([34]). A mai VRML böngészõk mindegyike támogatja a VRML2 / VRML97 formátumokat, de csak kevés kompatíbilis az 1.0-s verzióval A Graphisoft épületmodelljeinek Interneten való publikálásához és a szépszámú virtuális valóság kutatás miatt még 1997-ben beépítette a VRML exportálás lehetõségét az ArchiCAD-be. A formátum mind a mai napig óriási népszerûségnek

örvend, ezért a hálón rengeteg VRML modell található. Az ArchiCAD-bõl menthetõ VRML épületmodellek és a hálóról tölthetõ objektumok használatának támogatása elõsegíti a készítendõ globális illuminációs elvû alkalmazás kapcsán kitûzött „általánosan használható” célunkat, ezért a programnak szabványos VRML97 fájlokat is kell olvasnia. A 4. fejezetben bemutatott, kutatási projekt keretében készült RenderPark globális illuminá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ánjuk olvasni, hisz a formátum – sajnos - nem terjedt el. 6.124 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ézis programcsomagok között az élre törés volt. Bár ez nem teljes mértékben sikerült, a program elég népszerûvé vált és számos program kezdte importálni, illetve exportálni az 77 adatokat 3DS ([35]) formátumban. 1995-ben az Autodesk a Kinetix leánycégével alapjaiban ú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 a desktop kategóriájú számítógépek között, ezért elengedhetetlen követelmény lett a MAXszal 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 3D Studioval. A formátum elterjedtsége miatt a Graphisoft ArchiCAD programjába is beépítette az exportálás lehetõségét. Mára az ArchiCAD felhasználóinak széles tábora használja ezt a

formátumot, amelyet jól mutatnak a gyakori továbbfejlesztési ötletek, igények. Ezek közül az egyik legfontosabb a 3DS fájlok importálásának megoldása. A projekt keretében a globális illuminációs elvû programhoz kidolgozott 3DS fájl importáló modult úgy kívánjuk elkészíteni, hogy a késõbbiekben minimális munkával az ArchiCAD-hez is illeszteni lehessen. A 3DS formátum sem fizikai alapú, ezért a VRML-hez hasonló megoldásokat kell alkalmazni, azaz a globális illuminációs elvû programnak kell az empirikus adatokat fizikai alapú jellemzõkké konvertálnia. 6.125 XML Az Extensible Markup Language (XML) a Standard Generalization Markup Language (SGML) egy olyan részhalmaza, amelyet a World Wide Web-en (WWW) (Interneten a HTTP (HyperText Transfer Protocol) prokollon keresztül) történõ továbbításra optimalizáltak. Az SGML-t (ISO8849) körülbelül 30 évvel ezelõtt definiálták szöveges információk markup nyelvvel történõ

reprezentálására. Az XML SGML-bõl csak azokat a részeket vette át, amelyek a Web-alapú felhasználáshoz illeszkednek, ennek köszönhetõen az XML sokkal kisebb és egyszerûbb lett, mint maga az SGML. Az XML egyszerûségét és használhatóságát jellemzi az arány, miszerint: az XML komplexitásában 20%-a, míg funkcionalitásában 80%-a az SGML-nek. Itt kell megjegyeznünk, hogy a HyperText Markup Language (HTML) nyelv is az SGML nyelvbõl származik, ahol más rendezõelv szerint választották ki a részhalmazba bekerülõ elemeket, mint az XML esetében. Az XML nyelv szabványosításán a World Wide Web Consortium (W3C) dolgozik, ez egy szoftvergyártóktól független szervezet, amely 1994-es alapítása óta a Web-hez kötödõ szabványok és ajánlások megalkotásával foglalkozik. Az XML nyelv jelenleg 10s verzióval rendelkezik Az XML alapvetõen egy olyen meta-markup nyelv, amely formátumot definiál struktú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. 78 Az XML nyelv és a HTML nyelv kiegészítik egymást, ugyanis az XML egy egységesített módszert nyújt struktúrált adatok cseréjére és terjesztésére az Interneten (HTTP protokoll) 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 egy reprezentá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 az Interneten fellelhetõ dokumentumok tartalmának precíz deklarációja elõsegíti az információ értelmesebb alapokra helyezett keresését (a HTML alapú keresõmotorok által elõállított találati eredményeknél sokkal

jobb keresési eredmények produkálhatók az információtartalom precíz deklarációja miatt). Másrészt, ha a keresett információ már helyileg 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-eket használ a vezérlõ instrukciók szöveges információfolyamba történõ beszúrására. A két nyelvben használt tag-ek feladata azonban már eltér: a HTML-ben használt tag-ek a dokumentumban 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 legyenek stb.); az XML-ben használt tag-ek pedig az önmaguk által reprezentált információt deklará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 HTML egy rögzített tag-készletet használ, addig az XML-ben miden felhasználó vagy alkalmazásfejlesztõ saját tag-készletet alakíthat ki az adatok minél precízebb leírása végett Az XML hatalmas ütemû terjedésének köszönhetõen már a Graphisoft is használja az XML formátumot. Ezen felül jelenleg nem létezik olyan séma definíció, amely globális illuminációs elvû képszintézis program input adatainak leírásaként szolgálna. Ezen indokokból kifolyólag jogosan merült fel az igény, hogy a projekt keretében definiáljunk ilyen 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ális illuminá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ük el, hogy a lámpagyártók honlapjaikon is árulni kívánják lámpáikat, amelyek adatait ezen XML sémákkal adják meg. Ehhez megfelelõen általános leírást kell megadni Ráadásul az elterjesztéséhez is komoly erõforrásokra lenne szükség. Ezért a projekt keretein belül ezzel a területtel nem foglalkozunk, de a téma fontossága, aktualitása miatt nem kerülhetjük ki annak további kutatását. 79 6.2 Online kommunikáció Esetünkben az online kommunikáció a következõt jelenti: az ArchiCAD Image menüjének PhotoRendering Settings funkciójánál kiválaszthatóvá válik a projekt keretében létrejövõ globális illuminációs elvû képszintézis add-on. Ezután ha az Image menü PhotoRendering Projection funkcióját választjuk, vagy a Create Fly-Through dialó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 ArchiCADdel összeintegrálódik Ahhoz, hogy ez az integráció megtörténhessen, egy ún rendering add-on-t kell készíteni. 6.21 Rendering add-on A többi add-on típushoz hasonlóan a rendering add-on-ok is rendelkeznek egy saját interfé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ális illuminá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. Ezek megoldásáról részletesebben a következõ fejezetben szólunk. 80 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ípust ké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ány követelményt meghatározni. Bár a két prototípus képszintézis alrendszere meg fog egyezni, a kezelõ felületi jellemzõik és logikájuk eltérõek lesznek, ezért a két programmal 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ív bejárására használható funkcióval. A színtér geometriáján felül kamerák beállítására is használható szolgáltatást az önálló globális illuminációs elvû programban alapkövetelménynek tekintjük. 7.11 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ött válthatunk. Természetesen, lesz lehetõség a kameraadatok perzisztenssé tételére, azaz ki lehet menteni, be lehet tölteni õket. Az interaktív megjelenítés felületi elemei között kiemelkedõ fontosságúak a mozgáshoz szükséges funkciók. A 4 fejezetben bemutatott grafikus programok és néhány VRML bö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ás o 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 egyenesbe hozó" 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. 81 • • a mozgás és a kamera pozíciójának meghatározását jelentõsen gyorsítja a térképen való elhelyezés lehetõsége a "menj arra a pontra, ahova mutatok" funkció szintén nagyon hasznos, hisz jelentõ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.12 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 elemes felbontá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özti csúccsal, akkor a kezelõi felületrõl kell tudnia állítani azt az oldalhosszt, amelyet az algoritmus 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.21 Bejárás, kamera elhelyezése A ArchiCAD egy kissé nehézkesen használható navigációs eszközt nyújt a színtér interaktív bejárására, az építészeti elemek módosítására. Ettõl függetlenül az integrált megoldásnál a bejárás problémájával nem foglalkozunk, hanem az ArchiCAD és a "3D Window" lehetõségeire támaszkodunk. 7.22 Véges elemes felbontás paramétereinek beállítása Itt is ugyanaz mondható el, mint a 7.12 pontban 82 Irodalomjegyzék [1] G. Krammer: Bevezetés a számítógépi grafikába Jegyzet, ELTE 1999 http://valerie.infeltehu/~krammer/eltettk/grafika/jegyzet/indexhtml [2] J. D Foley, A van Dam, S K Feiner, J F Hughes, R L Philips: Computer Graphics: Principles and Practice, Second Edition In C Addison-Wesley Pub Co, 1992 [3] C. M Goral, KE Torrance, D P Greenberg, B Battaile: Modelling the interaction of light between diffuse

surfaces Computer Graphics (SIGGRAPH 84 Proceedings), 213-222. oldal, 1984 [4] GLX, GLU and Direct Rendering Infrastructure (DRI) http://www.openglorg/developers/documentation/glxhtml [5] A. Watt: 3D Computer Graphics (3rd Edition) Addison-Wesley Pub Co., 2000 [6] L. Szirmay-Kalos: Számítógépes grafika ComputerBooks, 1999. [7] V. Havran: Heuristic Ray Shooting Algorithms PhD 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 Data Structures, 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 models Computer 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: Shadetrees Computer Graphics (SIGGRAPH 84), 223-231. oldal, 1984 83 [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 maps Computer 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 mapping Computer Graphics (SIGGRAPH 92), 249-252. oldal, 1992 [17] N. Greene, M Kass, G Miller: Hierarchical Z-Buffer visibility Computer Graphics (SIGGRAPH 93), 231-238. oldal, 1993 [18] T. Whitted: An Improved Illumination Model for Shaded Display Communications of the ACM, 23: 343-349. oldal, 1980 [19] R. Cook, T Porter, L Carpenter: Distributed Ray Tracing Computer Graphics (SIGGRAPH 84), 137-145. oldal,

1984 [20] J. T Kajiya: The Rendering Equation Computer Graphics (SIGGRAPH 86), 143-150. oldal, 1986 [21] ArchiCAD hivatalos honlapja http://www.graphisoftcom/products/architecture and design/ [22] 3D Studio MAX hivatalos honlapja http://www2.discreetcom/products/d productshtml?prod=3dsmax [23] mental ray hivatalos honlapja http://www.mentalimagescom/p101html [24] Maya hivatalos honlapja http://www.aliaswavefrontcom/en/WhatWeDo/maya/indexshtml [25] Lightflow Rendering Tools hivatalos honlapja http://www.lightflowtechcom [26] AutoCAD hivatalos honlapja http://www3.autodeskcom/adsk/section/0,,284288-123112,00html [27] Radiance hivatalos honlapja http://radsite.lblgov/radiance/HOMEhtml 84 [28] Desktop Radiance hivatalos honlapja http://radsite.lblgov/deskrad/dradHOMEhtml [29] trueSpace hivatalos honlapja http://www.caligaricom/products/truespace/ts5/ [30] Lightscape hivatalos honlapja http://www.lightscapecom/ [31] Artlantis hivatalos honlapja

http://www.artlantiscom/ [32] RenderPark hivatalos honlapja http://www.cskuleuvenacbe/cwis/research/graphics/RENDERPARK/ [33] MGF formátum hivatalos honlapja http://radsite.lblgov/mgf/ [34] VRML formátum hivatalos honlapja http://www. vrmlorg/technicalinfo/specifications/specificationshtm [35] 3DS formátum specifikációja 3D Studio Release 3 File Toolkit, Reference Manual Autodesk Inc., 1994 85