A 3D-s grafikus kártyák működéséhez szükséges szoftverfeltételek

Grafikus programcsomagok

1. GLIDE

A 3dfx saját egyedi API-ja, amely direkt Voodoo chipek maximális kihasználtságára készült, ezért az összes funkciót kezeli és ismeri. Ez a jól dokumentált felület mindenki számára könnyen és ingyen elérhető és egyszerűen programozható. A Voodoo maximális támogatása és az egyszerű kezelhetősége sokáig az OpenGL fölé emelte, de 2 nagy hátránya van. Az első és legfontosabb, hogy csak és kizárólag 3dfx termékekhez készült, ezért nem írható át semmilyen más grafikus chipsetre, a másik, hogy kizárólag DOS, Windows 95/98 és NT operációs rendszerek alatt működik.

Ebből adódóan az OpenGL-el szemben a GLIDE nem rendelkezik platformfüggetlenséggel és a korlátlan hordozhatósággal.

2. OpenGL

A Silicon Graphics által jegyzett de facto szabvány, elődjének az Irish GL tekinthető. Mivel számos előnnyel bírt a korai 3D-s API-kal összehasonlítva, illetve egyedülálló módon platformfüggetlen, kezdetben jelentős népszerűségnek örvendett. A DirectX kezdeti verzióihoz képest sokkal fejlettebb effektuslistával rendelkezett, a Microsoft API-jának újabb és újabb fejlesztése következtében (különösen a 8.0) azonban ez az előny immár a múlté. Manapság inkább a 2D-3D tervezőprogramok használják, a 3D-s multimédiás programok kevésbé. A játékszoftverek pedig egyáltalán nem használják.    

Az API fejlődését tekintve korántsem beszélhetünk a DirectX-hez hasonló evolúcióról (pontosabban a fejlesztés során –érthető módon- elsősorban nem a multimédiás tartalom megjelenítésére koncentráltak a fejlesztők). 1992-ben jelent meg az 1.0-ás verzió, amit hamarosan követett az 1.1-es. A következő verzióra azonban 6 évet kellett várni. 1998 tavaszán jelent meg az 1.2-es változat. Itt ismét egy hosszabb szünet (informatikai léptékben) következett, majd 2001 augusztusában jelent meg az 1.3-as, 2002 nyarán 1.4-es verzió.

2003 júliusában debütált az 1.5-ös, amelyben végre támogatott a programozható shader architektúra.

Látható, hogy a DirectX-hez képest ritkábban került sor a fejlesztésére, illetve a verziószámokból is érzékelhető, hogy ezek a fejlesztések is kisebb volumenűek voltak. 

Körülbelül 250 bázisrutint kínál fel az alkalmazásfejlesztők számára. A programozók a rutinok egy részét 2 illetve 3D-s geometriai objektumok vagy raszterprimitívek definiálására, valamint a primitívek képének a hardver frame buffer-rének átadására használhatók.

Az OpenGL szabvány tartalmazza a texture mapping, alpha blending (átlátszóság), légköri effektek (köd) renderelő funkciókat.

                                       14.ábra Viewing pipeline az OpenGL-ben

Az ábrán látható, amint az OpenGL által megkapott utasítások egy viewing pipeline futószalagon haladnak végig. A parancsok végrehajtásra kerülnek, vagy az ábrán látható display list nevű tárolóba tárolódnak (átmeneti tároló), ahonnan később kiolvasva végrehajtódnak. A grafikus információk egysége a vertex, amit a rendszerrel csúcsponti adatok formájában közölhetünk. A görbe- és felületmodellező ezekből az adatokból OpenGL primitíveket generál, amiket vetítéssel leképezi a látótérbe. Ebben a munkafázisban történik a fényhatásokhoz szükséges számítások elvégzése is.

A raszterizálás fázisában történik a 2D-s koordináták (egész koordináták) meghatározása. Bitmap és pixelmezők közé kiszámolja a rendszer a textúrákat is. A raszterizálás után jön létre a képtöredék (fragment), amely alapján z-buffer eljárással történik a végső láthatóság kiszámítása.

Utolsó lépésként a kép kirajzolása történik a monitor képernyőjére. Ez már nem az OpenGL feladata, hanem ezt a folyamatot már az alkalmazott ablakozó rendszer hajtja végre. A Windows kezeli a képernyő ablakait, természetesen az ezzel kapcsolatos információkat az OpenGL is ismeri és felhasználja.

Az OpenGL előnye, hogy szinte az összes fontosabb platformra implementálták (OS/2, IBM RS/600, Windows, stb.).

A Microsoft komoly erőfeszítéséket tett a saját 3D-s API-ja támogatottságának növelésére, emiatt az OpenGL kétségkívül előnyös tulajdonságai (platformfüggetlen, stb.) ellenére, illetve a relatív későn kiadott verzióváltások következtében (már a DirectX 8.0 képességei is meghaladják az OpenGL 1.4 verziójának képességeit. Az 1.5-ös verzió pedig csak jó fél évvel a DirectX 9 megjelenése után érkezett) egyre kevésbé támogatott a 3D-s alkalmazások fejlesztői körében. A szórakoztató multimédiás alkalmazások API-ja a DirectX, míg a különböző tervezőprogramok (CAD) első számú API-ja továbbra is az OpenGL.

A SiliconGraphics és a Microsoft összefogott egy közös projektre, aminek a neve Fahrenheit. Ebben a 2 cég ötvözni akarta a 2 szabvány (OpenGL, DirectX) előnyit. A DirectX jó hardvertámogatottságát, jó animációs lehetőségeit az OpenGL platformfüggetlenségével. A Microsoft Direct 3D API (Low Level) funkcionálisan nagyon hasonlít az OpenGL-re. Az együttműködéssel a számítógépes grafika és képfeldolgozás területét célozták meg (CAD,CAM, számítógépes játékok, stb.). 

3. DirectX

A DirectX a Microsoft házi szabványa, amely lehetővé teszi a hardver erőforrásokhoz történő közvetlen és gyors hozzáférést. A DirectX COM alapú (egy szoftvermodell, ami az objektumok egymás közötti kommunikációjának és bináris színtű újrafelhasználásával nyújt egy szabványos protokollt) objektumok csoportjait tartalmazza, ami a játékok és multimédia-alkalmazások fejlesztői számára egy egységes (szabványosított) interfész felületet nyújt Windows platformon (Windows 95-től). A DirectX alkotórészei:

∙DirectDraw

A videohardverhez biztosít közvetlen hozzáférést. A képek adatait a videó memória vagy a rendszermemória tartalmazhatja. Ezen alkotóelemen keresztül férhetők hozzá a hardver lapcsere képességei. A videopufferek, clipperek, videofedőszegmensek és paletták azoknak a grafikus funkcionalitásokat reprezentálják, amelyeket a DirectDraw egységbe zár.

∙DirectSound

Közvetlen hozzáférést biztosít a zenei hardvereszközökhöz. Egy elsődleges hangpuffert bocsát a fejlesztő számára, lehetővé téve a keverést. Valamint egy másodlagos puffert a zenei adatok tárolásához. Támogatja a 3D-s hangpuffereket is. Ez lehetővé teszi, hogy a pufferket felügyeljük az alapján, hogy milyen helyet foglalnak el a 3 dimenziós virtuális világban.

∙Direct3D

A háromdimenziós testek kezelésével foglalkozik. Használatához minden esetben szükség van a DirectDraw-ra.

∙DirectInput

Közvetlen hozzáférést biztosít a különféle, számítógéphez csatlakoztatott beviteli eszközhöz. Ilyen beviteli hardveregység lehet: egér, billentyűzet, joystick, stb.

∙DirectPlay

A TCP/IP, IPX soros és modemen keresztüli kommunikációs kapcsolatot biztosít, és a hálózathoz biztosít közvetlen kapcsolatot.

∙DirectSetup

Professzionális telepítőprogramot lehet létrehozni a DirectSetup segítségével.

∙DirectMusic

Közvetlen hozzáférést biztosít a számítógép zenei képességeihez.

A Windows 95 operációs rendszerrel együtt vezette a Microsoft. Kezdetben a „konkurens” szabványok megelőzték (GLIDE, OpenGL), azonban napjaink egyértelműen uralkodó grafikus programcsomagja. A Microsoft folyamatosan fejlesztette, és a verzióváltások nemcsak marketingfogások voltak. Én a DirectX 8-at és a diplomamunkám írásakor érvényben levő DirectX 9-et fogom röviden bemutatni.

A DirectX 8-as 3D-s API gyökeresen felújított architektúrára épül az őt megelőző 7-es verzióhoz képest. Alapeleme a programozhatóság, ami addig nem volt lehetséges, ugyanis a hardver ragaszkodott a tervező által megálmodott végrehajtási módszerhez. A DirectX 8 néhány területen igen komoly előrelépést jelentett. Talán a leglátványosabb a Direct 3D továbbfejlesztése volt. Az új név DirectX Graphics, ami a Direct 3D és a Direct Draw (2D) összevonását jelentette.   

 A 8-as verzió 3D-s pipeline-ja szintén több részre osztható: A geometriai szakasz első új része a tesszeláció, a HOS (High Order Surface, magasabbrendű felület). HOS felület például a NURBS-felületek, vagy a Bezier patch-ek. Ezeket a rendereléshez poligonokra kell felbontani, azaz tesszelálni. Nagy előnyük, hogy sokkal kevesebb adattal írhatók le, mint az eredményül kapott geometriai alakzat.

A következő szakasz a T&L műveletek elvégzése, ami a vertex shader feladata. A T&L műveletek után különféle, egyéb számítások (clipping, backface culling) következnek.

Majd következik a multisample rendering, ami a T-bufferhez hasonló, de annál tágabb lehetőségekkel rendelkező feature-ről van szó. A DirectX 8 effektjeinek ez a része jobbára a 3dfx öröksége. A képet vagy annak bizonyos részeit a kártya többször számítja ki, amik mindig valamiben különböznek. Például a multisample motion blur eljárás esetén a kártya a gyorsan mozgó tárgyakat különböző, egymást követő pozícióikban rendereli le, majd ezeket kombinálva hozza létre az elmosódott hatást. Ezeket az effektek azonban meglehetősen számításigényesek, hiszen egy kész képkockához a hardver sokkal több feladatot kénytelen elvégezni.

A DirectX 8 esetében a programozók dolga valamivel könnyebb lett. Sokkal kiforrottabb, könnyebben használható rendszert kaptak, ugyanakkor a megoldandó feladatok egyre bonyolultabbak, így inkább csak szinten tartani lehet a fejlesztési időt, de csökkenteni aligha. Viszont a hardver gyors és meglehetősen szabad programozhatósága minden korábbinál látványosabb és egyedibb effektusok megvalósítását tette lehetővé.

A DirectX 9.0 verziója tette lehetővé először az API történetében, hogy az addig fixen a grafikus chipbe huzalozott funkciókba a fejlesztők, programozók beavatkozzanak, a folyamatokat saját kényük-kedvük szerint alakítsák.  A DirectX9 esetében a programozók a korábbiaknál lényegesen hatékonyabb eszközöket kapnak a kezükbe, amikkel bonyolult, részletes és valósághű effektusokat képesek programozni. A DirectX 9.0 legfontosabb tulajdonságai a következők:

• Vertex Shader 2.0 és Pixel Shader 2.0
• 128 bites, lebegőpontos színábrázolás
• nagy pontosságú frame puffer mód
•  rendering target
• displacement mapping és folyamatos tesszeláció

                                              15. ábra: DirectX 8 és a DirectX 9 összehasonlítása

A pixel shader és a vertex shader fogalmát a DirectX 8.0 vezette be. A háromdimenziós világ legkisebb építőegységei a primitívek. A vertex (vertex is primitív) egy olyan pont a térben, amely nemcsak x,y,z koordinátákkal rendelkezik, hanem saját normálvektorral, textúrakoordinátával, szín- és fényességadattal valamint egyéb más adattal ( például köd)  is. 1.0-ás verziójuknál a vertex shader programok csak rövid utasítássorozatok voltak, nem álltak rendelkezésre vezérlő utasítások, ciklusok, elágazások vagy szubrutinok   A DirectX 9-ben megjelent vertex shader 2.0 új utasítások mellett, már ciklusok és szubrutinok felhasználása is lehetővé válik a programozó számára. A programozó munkája ezáltal nemcsak egyszerűsödik, hanem látványos és bonyolult effektek valós idejű létrehozása válik lehetővé.

Amennyire sikeres volt a vertex shader első verziójának a fogadtatása, olyan sok kritika érte a pixel shader-t. Általános vélemény volt, hogy a pixel shader 1.0 csak amolyan „félmegoldás”. Legfőbb hibájának az egyszerre kezelhető textúrák alacsony száma (4) és a programok maximális hosszát tartották (128).  A 2.0-ás verzióban az egyszerre kezelhető textúrák számát megnégyszerezték (16), és 128 utasítás feldolgozása helyett 160 utasítás feldolgozása válik elérhetővé. A vertex shader 2.0-ához hasonlóan a pixel shader 2.0 is biztosítja a programozó számára az elágazások, ciklusok és szubrutinok használatát. A pixel shader 2.0 új utasításokkal bővült, mint például a gyökvonás. Vertex Shaderhez hasonlóan a Pixel Shader is képes több menetben dolgozni, azaz egy pixelt egymás után akár több program is formálhat, alakíthat. Így gyakorlatilag végtelen számú utasítás hajtható végre a pixeleken.

A DirectX 9 lehetőséget ad akár 64 bites, akár 128 bites lebegőpontos számok ábrázolására, ami a színkezelésben játszik fontos szerepet. 128 bites számábrázolás esetén a x = m*2^e képlettel történik. Ahol x az adott színkomponens értéke, m egy 23 biten ábrázolt mantissza, e pedig egy 8 biten (7 bit+1 bit előjel) ábrázolt kitevő. Így 2^-128 és 2¹²⁷ között gyakorlatilag tetszőleges számot lehet leírni. Törtek ábrázolására is lehetőség nyílik, ami szükségtelenné teszi a kerekítést, így színinformáció elvesztése sem történik. Előnyei mellett azonban van egy komoly hátránya a 128 bites ábrázolásnak. A felhasznált memória-sávszélesség drámaian, négyszeresére növekedik. A DX9 lehetővé teszi egy 32 bites nagy pontosságú frame puffer mód használatát, amelynek segítségével négyszer több fényességértéket lehet ábrázolni, így sokkal természetesebbnek tűnő látvány hozható létre. Míg a pixel shader 1.0-ás és 1.1-es  változata egyszerre csak egyetlen egy színértéket tudtak magukból kiadni, a DX9 pixel shaderek ezzel szemben akár négyet. Ezáltal valós időben lehet egy háromdimenziós jeleneten szűrést vagy utómunkát végezni.

A Pixel shader 2.0 nagyon komoly előrelépést jelentett korábbi verzióihoz képest. Sokkal komplexebb, a valóságot minél inkább megközelítő effektusok létrehozását teszi lehetővé.

A DirectX 8-ban vezették be először az úgynevezett N-patch felületeket, amelynek révén az objektumok széleit részletesebbé, gömbölyűbbé, természetesebbé lehetett tenni. Az eljárás lényegében a 3D-s objektumot alkotó háromszögeket az oldalak továbbosztásával még kisebb háromszögekre bontotta fel, majd ezek rendezésével részletesebben és finomabban ívelt objektumok létrehozása vált lehetővé. A DirectX 9 továbbmegy egy lépéssel. A displacement mapping nevű eljárás révén a háromszögek felbontása, darabolása és mozgatása nem geometriai egyenlet, hanem egy textúra alapján történik. A megoldás lényegében hasonlít a bump mapping-re, aminek segítségével érdes felületek látszatát lehet kelteni azáltal, hogy másképp verik vissza a fényt (maguk a felületek azonban fizikailag nem változtathatják alakjukat).

A DirectX 9 méltán elődjeihez, sok és érdekes újítást, fejlesztést tartalmaz. Még látványosabb effektusok létrehozása válik lehetővé, miközben a programozó munkája egyszerűsödik. A Microsoft kijavította a DirectX 8-as verzióinak hibáit (Pixel shader félmegoldásai), és egy jól kezelhető API-t biztosít a fejlesztők számára, amiből a felhasználók természetesen sokat profitálnak.

Visszalépéshez kattints a képre!