A címben szereplő Magas Szintű Árnyaló Nyelv kifejezés a HLSL (Hight Level Shader Language) angol rövidítés révén lehet ismerős. Mivel manapság az utóeffektezés (post-processing) szinte kihagyhatatlan része egy demónak/intrónak, így érdemes a legkönnyebben használható módjáról néhány szót ejteni. Ennek segítségével könnyedén lehet elmosni a teljes képernyőt, vagy emboss módban megjeleníteni, esetleg elnyújtani, vagy hullámoztatni, hogy csak a legegyszerűbb példákat hozzam fel.
Aki járatos a a shaderek világában, annak nem fogok sok újdonsággal szolgálni, így legfeljebb lektorálási, kiegészítési, korrigálási céllal olvassa a cikket. Viszont aki most ismerkedik a D3D-s, OpenGL-es programozással és a shaderekkel – mint én, akinek évente 2×2 napja marad erre, meg 1-2 hete magára a demóra :) -, annak talán segít gyorsan látványos eredményhez jutnia az alábbi példa alapján, és kedvet kapni mélyebbre merülni ebbe a jövőbe – jelenbe, múltba ;) – mutató világban. Szóval ez a cikk a kezdőknek szól, emiatt helyenként elég szájbarágós leszek, pont azért, mert annak idején, amikor először ezzel foglalkoztam, nekem is jól jött volna egy ilyen agyonmagyarázós útmutató. :) Mivel jómagam DirectX-et használok, így ezen keresztül fogom a technikát is bemutatni.
Tényleg csak a legegyszerűbb, leggyorsabb eredményt hozó példát szeretném megmutatni, így a Shader Modell 2.0-től használható technikát vettem elő, amivel csak pár sor egy post-process-t létrehozni, és a programból meghívni sem sokkal több.
Mivel High Level nyelvről van szó, nem igényel mélyebb ismereteket a GPU programozásban, hiszen egy C-szerű szintaxisban lehet megfogalmazni, hogy mi történjen az adott textúra X, Y pozícióban, azaz, hogy milyen színű pixelt hozzon létre a shader vágeredményként. Tehát egy olyan callback függvényt írhatunk meg, ahol megkapjuk a renderelés alatt álló textúrát, és az éppen árnyalásra kerülő pixel koordinátáit, amikből számos beépített HLSL függvénnyel kiszámolhatjuk – nekünk tetsző módon – az adott pont színét. Ezen felül még definiálhatunk külső paramétereket (konstansokat), amiket a shader meghívása előtt a demónkban beállíthatunk, azaz akár zenére időzítve, vagy más effektekhez igazítva megváltoztathatunk, ami ilyen módon kihat a post-processünkre.
De haladjunk sorban. Ahhoz, hogy post-porcesst hajtsunk végre a demónk egy lerenderelt frame-jén, egyszerű módszer az, hogy egy RenderTarget textúrára történjen a „nyers” scene előállítása, majd ezt egy képernyő méretű poligon quad-ra feszítve kitegyük mondjuk DrawPrimitive-el, ami előtt beállítjuk a post-process pixel shaderünket, ilyen módon a már kész frame-ből a poligon quad kirakása közben megeffektezett végeredményt kreálva.
Mi az a polygon quad? Két háromszögből álló négyzet (lap), ami azért quad, mivel 4 pontból (vertexből) áll, amit optimálisan TriangleStrip-ben adunk meg.
Valahogy így lesz a textúránkból post-processingelt képernyőkép:
RenderTarget textúra Végeredmény a képernyőn
+ emboss pixel shader =
RenderTargethez, ha kérdéses, kiindulásnak:
LPIDirect3DTexture9 pRenderTargetTex; // ez lesz rendertarget textúra
LPDirect3DSurface9 pRenderTargetSurf;
LPDirect3DSurface9 pLastRenderTargetSurf; // ide mentjük el az eredeti render targetet
// rendertarget textúra létrehozása
m_pDevice->CreateTexture (m_ScreenWidth, m_ScreenHeight, 1,
D3DUSAGE_RENDERTARGET, SurfaceDesc->Format,
D3DPOOL_DEFAULT, pRenderTargetTex, null);
// Az eredeti RenderTarget elmentése
if not FAILED(m_pDevice.GetRenderTarget(0, pLastRenderTargetSurf))
// D3D Device rendertarget beállítása a létrehozott textúrára
if not FAILED(pRenderTargetTex->GetSurfaceLevel(0, pRenderTargetSurf))
m_pDevice->SetRenderTarget(0, pRenderTargetSurf);
// Az eredeti RenderTarget visszaállítása,
// amit akkor kell meghívnunk, mielőtt kitennénk a polygon quad-al
// a képernyőre az elkészült framet
m_pDevice->SetRenderTarget(0, pLastRenderTargetSurf);
Maga a post-processhez használt shader kód egy egyszerű text fájl, ami így néz ki egy szimpla szellemkép effekt esetén:
//======================================================================
// Ghost pixel shader
// Written by Bery, 2. october 2006
//======================================================================
float fGhostLevel; // konstans paraméterünk, amit a demó forrásban állíthatunk be
sampler tex0 : register( s0 ); // a textúra, ami be lett állítva a Direct3DDevice9::SetTexture( 0, … ) révén
// ez pedig a függvény maga, ami megkapja az aktuális textúra koordinátát, és a színnel tér vissza
float4 GhostShader( float2 Tex : TEXCOORD0 ) : COLOR0
{
float4 Color; // ez csak egy átmeneti, lokális változó a szín számolására
float4 Color2; // és még egy, hogy könnyebben számoljunk
Color = tex2D(tex0, Tex.xy); // kivesszük a textúra adott pixelének eredeti színét
Tex.y = Tex.y + (0.01 * fGhostLevel); // y irányban arrébb nézünk a paraméternek megfelelő mértékben
Tex.x = Tex.x + (0.01 * fGhostLevel); // x irányban is arrébb tesszük a koordinátát
Color2 = tex2D(tex0, Tex.xy); // az arrébb tolt koordinátáról is kivesszük a színt
Color2 = Color2 / 2;
Color = Color / 2;
Color += Color2; // a két színből képzünk átlagolva egy újat
return Color; // a kiszámolt színt visszaadjuk
}
Ki kicsoda ebben a példában?
fGhostLevel – ez az a külső paraméter, ami általunk állítható konstansként szerepel a post processünkben. Ez minél nagyobb érték, annál jobban szétcsúszik a szellemképünk. 0 esetén nincs szellemkép, csak dolgozik egy fölöslegeset a GPU, a pixelenkénti átlagolással.
Text0 – az éppen használt textúra, ami a megadott regiszterben van. Ahogy látszik a példában a register(s0) a 0. textúrát adja vissza, míg a register (s1) az 1. textúrát adná, és így tovább. Ezek pedig megegyeznek a ID3DDevice:: SetTexture (0) -nál (1-nél, 2-nél, stb.) megadott textúrával.
Tex (TEXCOORD0) – a paraméterben megkapjuk a renderelés alatt álló textúra koordinátáit, amit felhasználhatunk külön-külön is (Tex.x, Tex.y), vagy együtt hivatkozva is (Tex.xy). Fontos, hogy a textúra koordináták 0.0 és 1.0 közötti értéket vesznek fel, mindkét irányban, függetlenül a textúra méretétől. Ez egyrészt jó, mivel nem kell tudnunk a függvényünkben, hogy a textúra mekkora, másrészt rossz, mert tényleg nem is tudjuk :) (Kivéve, ha egy konstansban átadjuk magunknak.) Bár persze egy okosan megírt shader függvényben ezt nem is kell tudni. Amit viszont tudunk, hogy 0.5 az pont a textúra közepe, 0.0 a bal széle x-koordináta esetén, illetve a teteje y-koordináta esetén, illetve 1.0 az x-koordinátánál a jobb szél, illetve y-koordináta esetén a textúra alja.
Tex2D – ő már egy HLSL függvény, ami visszaadja a paraméterben levő textúra, másik paraméterben megadott koordinátáján levő texeljét, azaz a koordinátán levő színt.
Color – mivel ő float4, így sejthetjük, hogy legalább 4 tagból áll, amire például így hivatkozhatunk: Color.r – a red összetevője a színnek, a Color.g a green, a Color.b pedig a blue. Ezek értéke is 0.0 és 1.0 közé eshet. De, ha egyszerre állítanánk két összetevőt, akkor használhatjuk a Color.rb, vagy Color.gb formulát is Negyedik összetevő a Color.a – alpha. A Color = 1 pedig mind a négy összetevő értékét egyszerre állítja, a példa szerint éppen 1-re.
A többi már C-ből és egyéb nyelvekből igazán ismerős lehet :)
De nézzük, mit eredményez a fenti shader effektünk.
Mondjuk így néz ki az eredeti képernyőnk:
És így, amikor szellemképet állít elő belőle a post-process:
Persze ez úgy látványos, ha a szellemesség ;) mértéke változik, mert akkor látszik igazán, hogy miről is van szó. Mint ahogy ezt elsütöttük a Function 2006-on kiadott Fiction c. demónkban.
Hogy jobban érthető legyen, hogy milyen kis egyszerű kódrészletekkel tudjuk manipulálni a megjelenő frameket, érdemes megnézni ezen a linken levő példákat, amik talán még hatásosabban szemléltetik a módszer egyszerűségét.
Na jó-jó, ilyen egy post-process shader, de hogy kerül ez a text fájl bele a programba?
Így kell inicializálnunk pixel shaderünket:
Ezt valamikor a demó elején ejthetjük meg egyszer.
// Direct3D Device – ezt ugye amúgy is létrehozzuk, mert mindenhez kell
LPDIRECT3DDEVICE9 m_pDevice;
// ez lesz a pixel shader, amit beállíthatunk renderelés előtt
LPDIRECT3DPIXELSHADER9 m_pPixelShader;
// ez pedig a külső paraméterekre való hivatkozáshoz
LPD3DXCONSTANTTABLE m_pGhostPSConsts;
// ide kerül a lefordított shader
LPD3DXBUFFER pCode = NULL;
// csak egy globális változó, amiből átadjuk a paramétert
FLOAT m_GhostLevel = 0;
// lefordítjuk a shader-t fájlból – ki hinné a névből? :)
D3DXCompileShaderFromFile (“GhostShader.txt”, // a text fájl neve
NULL,
NULL,
“GhostShader”, // a shader általunk adott neve
“ps_2_0”, // 2.0-ás shader modellt használunk
0,
&pCode, // ide fordul a shader
NULL,
&m_pGhostPSConsts); // a külső paraméterek (konstansok) táblázata
// a lefordított kódból létrehozzuk a shadert
m_pDevice->CreatePixelShader((DWORD*)pCode->GetBufferPointer(),&m_pPixelShader);
// ez nem kell már, szépen elengedjük
pCode->Release();
Aztán beállítjuk a paraméterünket:
Ezt menet közben bármikor, amikor éppen változtatni akarjuk. Nyilván egy render ciklusban egyszer.
if ( m_pBlurPSConsts && (handle = m_pBlurPSConsts->GetConstantByName(NULL,”fGostLevel”)))
{
m_pBlurPSConsts->SetFloat (m_pDevice, ‘fGhostLevel’, m_GhostLevel);
}
És bekapcsoljuk a pixel shaderünket:
Praktikusan a DrawPrimitiv előtt kell valamikor a pixel shadert beállítani, szintén egy render ciklusban egyszer.
m_pDevice->SetPixelShader(m_pPixelShader);
Ezután jön a fent már megbeszélt DrawPrimitive, ami a már lerenderelt sceneünket teszi ki egy polygon quadra feszítve, a quad rendereléséhez felhasználva a beállított shaderünket, ami az eredeti frame minden pixelére végrehajtja azt, ilyen módon előállítva a post-process effektet.
Ha a következő rendereléshez nem szeretnénk a shaderünket használni már – ami ugyebár a „nyers” scene renderelése esetén például igaz -, akkor nagyon egyszerűen kikapcsolhatjuk:
m_pDevice->SetPixelShader(null);
Természetesen illik a demó végén felszabadítanunk a shaderünk objektumait is:
m_pGhostPSConsts->Release();
m_pPixelShader->Release();
A shaderünket nem csak fájlból tölthetjük be, hanem a memóriából is, erre is van egy DirectX hívás. A paraméterek az első kettő kivételével már ismerősek lesznek a fájlból való betöltésből:
D3DXCompileShader (&PointerToShaderText, // a shader text-re mutató pointer
ShaderTextSize, // a shader text mérete bájtokban
null,
null,
‘GhostShader’,
‘ps_2_0’,
0,
&pCode,
null,
&m_pGhostPSConsts);
Mindezen funkciók hívása visszaad egy Result-ot, amit természetesen mindig le kell kérdezni és a felmerülő hibákat kezelni! :) Én az egyszerűség miatt ezt elspóroltam. A demó elején azt is érdemes lekérdezni, hogy az adott hardver támogatja-e azt a shader modell-t (esetünkben a 2.0-ást), amit használni kívánunk, különben csúnya elszállások történhetnek.
Összefoglalva metakódban a demót:
DEMO
Init3DEngine; // a 3D enginünk inicializálása és minden egyéb init (pl. zene)
InitPilxelShader; // a pixel shader betöltése a fentiek alapján
InitRenderTarget; // a render target textúránk létrehozása
InitScreenPolyQuad; // a poligon quadunk létrehozása
// a demó fő ciklusa
while RenderLoop
GetRenderTarget (OriginalRenderTarget); // az eredeti render target lekérdezése
SetRenderTarget (RenderTargetTexture); // render target a textúránkra
RenderScene; // a demó egy framejének előállítása
SetRenderTarget (OriginalRenderTarget); // render target visszaállítása
SetPixelShader (MyPixelShader); // pixel shaderünk beállítása
DrawScreenPolyQuad; // a lerenderelt frame kirakása (DrawPrimitive) pixel shader-el
SetPixelShader (null); // a pixel shader kikapcsolása
Present3DScreen; // a képernyő megjelenítése a monitoron
end while
// a használt objektumok felszabadítása a demó végén
DoneRenderTarget;
DonePixelShader;
DonePolyQuad;
Done3DEngine;
END DEMO
A fenti példa a DirectX-es megoldást szemléltette. Kis Google használat után könnyedén nyomára lehet akadni az OpenGL-es változatnak is a GLSL kulcsszóra keresve.
Ezen felül csak egy hajszállal bonyolultabban lehetőségünk van arra is, hogy pixel shadert és vertex shadert egyszerre használjunk. Ez már valamivel összetettebb effektek létrehozására is alkalmas. Ezeket a szakmai zsargonban is effekteknek hívják – legalábbis DirectX berkekben – és a szabványos fájlkiterjesztésük *.fx.
Ha pedig hajlandóak vagyunk mélyebben is foglalkozni a shaderekkel – de még mindig “csak” HLSL szinten -, akkor könnyedén előállíthatunk BumpMap effektet, vagy éppen egy kellemes kis Water effektet normal map használatával. Ha van rá érdeklődés, akkor egy következő cikkben leírom ennek a technikáját is, példákkal, forráskóddal szemléltetve.
Akinek pedig ennyivel csak az étvágyát hoztam meg, de jól nem lakott, annak a következő linkeket ajánlom böngészni.
Szemléletes példák még itt: http://www.facewound.com/tutorials/shader1/
HLSL függvények leírása: http://msdn2.microsoft.com/en-us/library/bb509611(VS.85).aspx
Bővebben a HLSL-ről: http://en.wikipedia.org/wiki/High_Level_Shader_Language
MSDN HLSL: http://msdn2.microsoft.com/en-us/library/bb509561(VS.85).aspx
kafa
Haskellben is lehet ilyet? :)
lelombozó ez a meghivok 57 DX függvényt és kész a demó történet…
Oswald: Valamit nagyon nem jól látsz… Kénytelen vagy meghívni 57 DX függvényt, hogy ki tudj rajzolni egy képernyőnyi polygont, egy 5 utasításos pixel shaderrel. ;)
Már mitől lenne kész a demó? Neked kell megírni, hogy mit csináljon a post processing, azt nem tolja a DX alád. Csak éppen míg régen “kézzel” címezted végig a képernyő buffer-t egy blur effektért, most erre van egy pixel shader-ed, de a blurt ugyanúgy neked kell megírnod, csak a végrehajtása van egy kicsit megtámogatva hardverileg.
Na meg azt is neked kell kitalálni, hogy mi is történjen, és milyen színekkel, és milyen textúrákkal, és milyen objecteken, és ezeket is neked kell létrehoznod, vagy letöltened a netről ;)
Oswald: következő partyn szívesen megnézném a demódat. 57 DX hívás begépelése nem tarthat tovább negyed óránál, így nem is kell sok időt rászánnod.
(Vagy csak engem zavar, hogy egyes régi arcok élből lefikáznak mindent, ami 3D gyorsítót használ, mondván, hogy abban nincs kihívás? Ráadásul valamiért ezek az emberek sosem jönnek ki egy jó hwaccel demóval, hogy legalább látsszon, hogy nem a levegőbe beszélnek.)
számomra a demozás arról szól hogy olyat hozzunk ki a hardverből ami elismerésre méltó. mi maradt ebből ? semmi. sizelimit. kb mintha c64en a basic rom kiiró meg floatingpoint rutinjaival csinálnák filledvektort. tudom. kompatibilitás ésatöbbii. a demoscene kultúrálisan elavult. már nem nagy szám pár villogó izé a képernyőn mint régen.
jimmi : c64-re ? :)))
jimmi, van benne kihívás, de teljesen másmilyen. a Linux APIját is kihívás megtanulni ugyanúgy mint a DX-ét. és teljesen más dolog a hardwaret bangelni. tudom ez ma már képtelenség. de régi arc vagyok és nem tetszik ez a mai világ. ha úgy tetszik egy begyöpösödött vénember :)
Nincs ez máshogy a hardver gyorsítás idejében sem. Érdemes összehasonlítani, hogy mekkora code a Bery által is mutatott hw gyorsítós offset effect, és mekkora lenne mindez dos alatt assemblyben megírva. Egy mai HW acceles verzió c-ben írva is sokkal több hozzáértést és befektetett munkát jelent, használva a dx vagy opengl apit (api nélkül ugye nem is tudod), mint amennyi 10-12 éve volt dos alatt! Ez persze nem igaz mindenre, de a Bery cikkére maximálisan.
Aha. Hát akkor a zene is kulturálisan (rövid “u”-val) elavult. Ma már bárki bemegy egy hangszerboltba, vehet hangszereket. Azok voltak a régi, szép idők, amikor még egy menyéttel átszúrt dinnyén játszották Afrikában a törzsi tamtamot. Azóta a zene… áh. Nincs benne semmi elismerésre méltó. Csak megpengeted a gitárt, és szól. Lelombozó.
Murphy, egyszer láttam a visual c++ demó forrását egy ablak megnyitására,6 modul, 1000 sor kód, valahogy technikailag mégse taglózott le hogy ez a sok sok kód és tudás és megtörhetetlen akarat megnyitott a képernyőn egy ablakot a címsorban “hello world” felirattal alatta pedig egy “ok” gombbal :)
MessageBox(0, “hello world”, 0, MB_OK); // :)))))))))))
Jimmi, hát ez nagyon rotfl, ott a pont :)
abcug, az a példa a message loop és a többi ablaknyitáshoz tartozó feladat bemutatására volt hivatott :) az msgbox teljesen más tészta :)
Nagyon elbeszélünk egymás mellett… A világ, a rendszerek komplexebbek lettek, sokkal. Az az 57 DX függvény arra jó, hogy az ember minél kevesebb fölösleges sallanggal foglalkozzon, összességében ne legyen sokkal több dolga, mint régen volt egyszerűbb rendszereken, esetleg könyebb dolga legyen. A demóírás nem lett egyszerűbb, főleg mivel az elvárások folyamatosan növekednek. Mivel könnyíti meg az ember dolgát a 3d gyorsítás? Ad egy flexibilis pontos és gyors polygon rajzolót, aminek a transzformációját mi írjuk, a pixel műveleteket mi írjuk, cserébe egy nagyon komplex hw van a háttérben. Az API és a driver arra szolgál, hogy a hw-t ne regiszter szinten kelljen programozni, ne neked kelljen szinkronizálni az adatokat a CPU és a GPU között, ne neked kelljen a hw számára ideális módon kezelned a memóriát… Egy brutális nagy rendszer ami jórész olyan problémák megoldására szolgál, amik a HW felépítéséből adódnak.
nem beszélünk el, értem én hogy ma már nincs HW bangelés és nem is lehet ésatöbbi, de ettől akkor is olyan lesz az egész mintha gumimatracon evezve teljesíteném a 100m gyorsot. biztonságos és könnyebb és kompatibilis megálhatok közben pihenni is, de nem az igazi, és nem valami gyors.
Szerintem egy Debris-t nem könnyebb manapság megírni, mint DOS alá lett volna – hogy ha feltételezzük, hogy az akkori hardver elbírt volna ennyi poligont -, és egy folyadék- vagy egyéb szimuláció sem könnyebb manapság, mint régen volt. De ha azt nézzük, a GPU programozás az ma, mint régen a rendszerközeli ASM volt. Azt meg nem bánom, hogy nem kell szétifelnem a demot, hogy fusson legalább a 3 legelterjedtebb grafikus chip-en. És még így is vannak bugok vagy ATI-n, vagy NVidián, jobbára a coderek hibájából, mert az API annyira összetett, hogy tényleg időben mérhető tapasztalat kell, mire minden gépen stabil kódot tudsz előállítani. De addigra jön egy újabb dolog, amire nem számítottál ;)
Na meg ettől még kell egy jó ötlet, és kell egy jó kóder, és méginkább egy jó designer/grafikus, különben nem 3-4 demót emlegetnénk mély áhitattal évente, hanem 300-400-at, ha ez mára tényleg ennyire egyszerű lenne, és mindenki számára kisujjból rázható.
Na jó, egy kicsit könnyebb Debrist írni, mert instances, meg ilyenek, ami tényleg lehet segítség DX oldalról. De én azt sem tudom, hogy mi az, így az én particle system-emben biztos nem lenne ilyen :)
nem olvastam meg végig a hozzászólásokat, de az elavult/nem elavult, illetve kinek mi a demo kérdéskörre álljon itt metafóraként egy video. Remélem értitek mit akarok ezzel mondani:
http://www.dailymotion.com/video/x3wrzo_fabrication-dune-lampe-triode_tech
Hogyne lenne, gyakorlatilag minden konzolon van rá lehetőség. Ha erre vágysz kezd el mondjuk PS2-őt programozni… Hatalmas élmény lesz mire megjelenik az első gouraudolt háromszöged. :) És ezzel még akkor nagyon durván fényévekre vagy attól, hogy legyen egy 3d világ megjelenítőd, fényekkel, klippelt poligonokkal, csupán olyan dolgokkal amit egy 2000-es hardvertől elvárnak az emberek.
A PS2 agyrém. Mikor szenvedsz heteket, kézzel írod a párhuzamos végrehajtásra kioptimalizált VU codeot, és rájössz, hogy miképp kellene máshogy kiosztani a VU memóriát, hogy gyorsabb legyél, megcsinálod, azután meg megnézed Performance Analizátorral, és megmutatja, hogy mekkora várakozások vannak a textúra feltöltések miatt, és kezdhetsz agyalni, hogy miképp old meg, hogy időben ott legyen minden textúra… A mai hardverek persze ennél flexibilisebbek, és az api és főleg a driver arra szolgál, hogy a hihetetlen mennyiségű szívástól megkíméljen, ha ez nem lenne nem sok hobbi 3d program készülne.
Elég jó példa, hogy a Vista videokártya driverek mennyi ideje készülnek, és nagyjából most tartanak ott, hogy a directx 9 sebességét hozzák, holott a driver modell úgy van kitalálva, hogy jóval gyorsabb lehessen. Csak épp nem egyszerű ezt összehozni a hardverrel. Egy NVIDIA vagy ATI driver csapatban pedig dolgozhat vagy 20 ember mindegyikuk kivulrol belulrol ismeri a hardvert, és már 1.5 éve biztos folyik a munka…
A PS2 példám kapcsán nem igazán sikerült szemléltetnem, hogy mekkora meló, mennyi mindenre kell figyelni, ha valakit érdekel megpróbálom majd összeszedni, nagyon durva…
“Szamitogeppel minden gyorsabb, csak tovabb tart.” :)
Murphy, erről írhatnál egy cikket, engem komolyan érdekelne :)
De szerintem ez így igaz, ahogy Gargaj írta. De úgy méginkább, hogy ha van internet, akkor minden tovább tart :)
Oswald: huu, hát annyira nem értek hozzá, én direktbe low level módon PS2-re nem progtamoztam (szerencsére :D ), de elég jól láttam a dolgokat. Majd átgondolom, hogy tudnék-e cikket írni róla, de két éve volt már az is, meg végülis igen haszontalan információ… :)
oswaldnak egy 8.1-es (asszem) d3d sdk + egy tasm5-kellene imho :)
igaz ott is a kod nagyresze push,push,push,push,push,push,call ;) nade a hangulata ! :)
Amugy meg lehet hogy a C64 csak 1mhzes, de ha ott megirsz valamit, az csak a hardveren meg rajtad mulik hogy hogy fut, nem pedig azert fagy ki a demo mert sikerul belefutni valami ezoterikus bugba a driverben… Szal ehhez kepest regen meg konnyebb is volt.
A masik, hogy manapsag azt mondani, hogy mennyire konnyu vektort fillezni PC-n, az kicsit olyan, mintha azon reklamalnank hogy mennyire konnyu kiirni szines betuket kiirni a kepernyon C64en.
abcug, lol :D
Murphy, nem konkrétan a ps2 hanem az egész mókáról egy kis áttekintés, hogy a hülye c64es is értse hogy mi dolgozik a háttérben :) pl a 3d leképezést clippinget, láthatóságot is megcsinála a DX ? (gondolom:)
Gargaj, szerintem egyértelmű hogy régen könnyebb volt :) leginkább egyszerűbb :) talán a dos-os pcket lehetett a legjobb kódolni, volt benne erő, és közvetlen a HWt nyúzta az ember :)
A Sony szeret ilyen hardvert gyártani. Én PSP-re írtam engine-t, ott is gyakorlatilag bármennyi időt el lehetne tölteni azzal, hogy még jobban optimalizáld, és egy újabb mikroszekundumot spórolj meg a hardveren itt és ott… Csak akkor éppen sose fog elkészülni a termék maga. :)
Mondjuk ez az a hozzáállás, ami miatt PS2-re is kijöhettek olyan grafikával megáldott játékok, mint pl. a Black.
hat. szerintem dos alatt is volt legalabb annyi problema, mint manapsag. az sem igaz, hogy barmilyen code barmelyik vga-n ugyanugy futott (nem veletlen lett feltalalva az univbe sem, utana meg kuszabb lett minden :). foleg a sima mcga-tol eltero modokat hasznalo demokkal… de legalabb volt flatreal, amitol ugye sokan falra masztak : osszessegeben ugy gondolom, hogy a mai win32+d3d sokkal emberbaratibb felulet akar szerzodes nyilvantarto grafikonjainak keszitesere is :)))
Jimmi: a PSP ilyen szempontból már nagyon emberbarát, végülis egy butább gef1 szerű az egész, csak jobban belelátni a működésbe. Nincsenek VU-k, van T&L, a library is jóval érthetőbb és többet ad, egyedül a clipping ami kicsit vicces :)
Oswald: jó, egy ilyen cikk (sorozat) beleférhet
murphy: forditsd le neki a d3d sdk-bol, ott benne van minden :)
A következő dolgokat csinálja meg neked a DX9 szintű hardver (nagy vonalakban):
– frustum clipping (Sutherland-Hodgman homogén vágás, nem bonyolult annak, aki érti. :) Kb. osztás meg szorzás)
– homogén transzformáció (egy darab osztás)
– viewportba és depth range-be transzformálás (egy szorzás meg egy összeadás)
– rasterizer setup (subpixel korrekten, szintén szorzásosztás)
– perspektíva-korrekt vagy axonometrikus attribútum interpoláció (szorzásosztás)
– textúra sampling (bilinear / trilinear / anizo filter, egyik sem különösebben bonyolult matek)
– depth/stencil test
– blending
A vetítést a vertex shader csinálja, amit te írsz meg. A pixel színét pedig a pixel shader határozza meg, amit szintén te írsz. Bár a listához még apróságokat hozzá lehetne írni, azért jól látható mindenesetre, hogy egyáltalán nem csinál bonyolult varázslatokat a GPU. Csak úgy van megtervezve, hogy ezeket sokkal gyorsabban meg tudja csinálni, mint a CPU. A másik nagy előnye pedig abban van, hogy ennek a matekját rendesen átgondolták, és nem állt meg ott a fejlesztés, hogy “valami hasonló már megjelenik, compóra jó lesz”. :)
Jól összeszedted Jimmi. Egy dolgot fűznék a kommenthez még, hogy ugyan egy raszterizálót CPU-n megcsinálni nem bonyolult, de, hogy közel annyit tudjon mint a GPU azért már nem egyszerű, és főleg az optimalizációjával végtelen ideig el lehet szenvedni. ;)
Azt azért ne hagyjuk ki, hogy ha nem írsz sem vertex, sem pixel shadert, akkor is tud:
– flat shadet
– goraud shadet
– phong shadet
– texture mapping-ot
– multiple texture mappingot (számolt environment mappal)
és mindezekhez 1-n (kártya és DX verzió függő számú) fényforrást kezelni (árnyék nélkül)
Szóval azért nem buta az a DirectX, de nem is baj, hogy nem kell ilyenekkel tökölni, mert például UF szinten mindig az ment, hogy: “kellene egy normális engine-t írni végre, mert amit most használunk az szar” – ezért nem volt sok UF demo a múlt században :)
Így is maradt bőven mit beletenni a saját engine-be, bár ezeken felül is van támogatás a DirectX-ben (Mesh-ek, és buzerálásaik, CreateSphere, ilyesmik).
És kb. a DirectX 7.0-ig mondtuk el a dolgokat, onnan további finomságok kerültek be, amiket még én sem szedtem fel tudás szinten, pedig írtam már 4 db demót :)
szóval megetettem a dxet egy worlddel aztán már “csak” a kamcsit kell mozgatni :) 10nél már a kari animokat is támogatja gondolom :)
Igazából nem tud. :)
A mai hardverek mindent shaderből futtatnak, maximum ez nem látszik, mert a driver elrejti előled. De pl. DX10-ben még ilyen sincs, kidobták a fix pipeline-t a kukába, ott tényleg neked kell megírni a shadert is.
Oswald: a DX10 igazából egy bizonyos értelmben még kevesebb dolgot tud, mint a DX9. Legalábbis kidobtak egy csomó dolgot, amit eddig a driver intézett el helyetted, pedig te is megtehetted volna (pl. a fenti shaderes példa). Animációt viszont nem tud magától egyik sem, neked kell gondoskodni róla. Igazából úgy a legegyszerűbb elképzelni, hogy a hardver tud helyetted poligont rajzolni, minden mást ugyanúgy neked kell csinálni, mint régen. (Ezért a mondatomért meg majd befizetem a pongyolasági adót.)
Oswald: hát távolról sem… Van a D3D és van a D3DX. Az előbbi az api a másik pedig helper függvények és osztályok gyűjteménye. Utóbbi ugyan sokmindent tud, de inkább teszt célokra alkalmas, komolyabbra nem. Egy két függvény kivételével (textúra töltés, shader fordítás) inkább a konverziós fázisban szokás használni.
Majd inkább tényleg egy cikkben bővebben…
Jáj Bery \o/ \o/ \o/ :) szeretünk téged :) \o/ |o/ ( eszeveszett rock’n’roll)
Mi baj, Aha? Te is erről írtál cikket? ;)
na hasonló cikket még
Ha lesz legalább annyi hozzászólás, mint a Haskell első részéhez, akkor lesz folytatás ;) Már nem kell sok hozzá! ;)
Érdekes és jó cikk lett Bery gratulalok! :) (mindig is el akartam kezdeni foglalkozni ezzel, de valahogy sosem tudtam merre induljak. Most megint megjött a kedvem kár, hogy pont most van vizsgaidőszak )
egy dolgot meg hozzafuznek a cikkhez: ha ramappolsz egy polyt a kepernyore akkor van ugye az az ominozus felpixel offset – celszeru nem elfelejteni.
ja es “post-processing” kotojellel :)
Gargaj, ezzel mekkora szopások lehettek sokaknak :D:D:D
hajjaj… plane amikor kiderul hogy a 0.5 az nem PONTOSAN 0.5 hanem inkabb 0.49 :)
a kód kicsit nehezen emészthető… igaz nem tudok c-ül, de nem kellett volna elmagyarázni nagyjából a függvényeket? :) nekem több mint egy évig (2) tartott mire a GDI-t egy picit mertem hivogatni visual basicből, igaz zéró windows / modern programozási ismeretekről indultam, na meg egyre nehezebben veszem rá magam az új dolgokra, nincs szörnyűbb érzés mint amikor az ember vakon tapogatózva kódol egy új környezetben és órákig szop reménytelenül valami triviális dologgal. nehéz dolga van ma egy újonc kódernek szvsz, bár esetleg elkezdheti a dolgot valami kezdőknek való környezetben.
Oswald: mely’ függvényeket magyarázzam el? Gondoltam, legalább C-ül tud az, aki belekezd ilyesmibe :) Bár én pl. soha nem írtam egy “Hello world”-öt sem C-ben, ezt is a Delphi forrásomból honosítottam, mert az évek alatt ennyire megtanultam C-ül a sok example forrás olvasása közben :) Így is féltem, hogy túl részletes vagyok, de hát sosem írhat mindenkinek jó cikket az ember ilyen témában :)
Gargaj: a büdös életben nem hallottam még erről a 0,5 pixeles mapping eltérésről. Elolvastam, de továbbra sem igazán értem, hogy miért kell ez. Mindenesetre köszi, megint egy kicsivel többet tudok! Szóval azért mozgott egy kicsit a kép, amikor ki-be kapcsolgattam tesztből a pixel shadert? :)
az az eltolas a texture filterezes miatt van vagy ilyesmi.
roviden leirva: a texturanak a balfelso sarka (es nem a pixel kozepe) a 0,0, a kepernyonek viszont a balfelso pixel kozepe.
c-ül nem tudok, csak trollkodok :)
CreateTexture (m_ScreenWidth, m_ScreenHeight, 1,
D3DUSAGE_RENDERTARGET, SurfaceDesc->Format,
D3DPOOL_DEFAULT, pRenderTargetTex, null);
pl ezt, mi az hogy 1 meg null meg d3dpool (na erre van tippem, memória?) stb :) vagy a cikk azoknak szól akik cül is tudnak és pár alap dx függvényül is? én kérek elnézést.
azert ezzel vitatkoznek. :)
professzionalis programozas eseten egyetertek (!!!), de azert erdekes lenne latni, hogy mennyi demo indulna el, ha nem kapna d3d9_xx.dll-t vagy ki lenne szedve a statikus library es itt nem “Egy ket fuggveny”-rol van szo, mert azt sima apival is meg lehet csinalni pici plusz munkaval (de minek ugye ha van d3dx !?:)
Pedig igen, egyszeru az elet: LoadMeshHierarchy, AnimationController + CreateEffekt aztan kimasolod az sdk-bol a megfelelo *.fx-filet es kb. 5 perc alatt kesz a demod :)
A mai atlag szinvonalat siman uberelheted es a kutya nem mondja meg (mert nem veszed eszre), hogy mivel csinaltad… Ha ertesz picit a shaderekhez, akkor meg ugy agyon post-(!!!)processeled, hogy azt se tudja majd senki, hogy az mesh, vagy folyos trutyi :)
Bery: Örülök a cikknek és még, még, még, még… :)
Gargaj: ezt a részét én is értettem, de mi ez a baromság, hogy a képernyő sarka a pixel közepe? Egyáltalán, hogy pixel közepe? Mert igen, az életben az egy pont, ami elméletileg nem négyzet, hanem kör, de valójában egy pixel, az egy kis négyzet, nem? Jó, ezek szerint nem, pedig de :)
Oswald: azért nem írtam le a D3DX függvény paramétereit részletesen, mert ennek utána lehet nézni a DirectX SDK-ban, és igazából többet nem nagyon tudok én se írni róla. A lényeges paramétereket meg úgy neveztem el, hogy ránézésre adják magukat (pl.: m_ScreenWidth, pRenderTargetTex). Itt inkább azt a részét próbáltam megfogni, ami nem adódik egyértelműen az SDK-ból (maga a post-processing folyamat és megvalósítása), de óhatatlanul előfordul, hogy amit az ember tud, az mások számára is evidenciának tekinti.
De a következő cikkben akkor majd igyekszem még nagyobb részletességgel kitérni a dolgokra, hogy ne legyenek ilyen ködbe vesző paraméterek :)
Bery: már megdőlt a haskell cikk rekordja ;)
De nem is Haskell tartja a rekordot.
Nem úgy értve. Csak, az volt a folytatás feltétele, hogy több hozzászólás legyen, mint a haskell cikknél…
Hajajj, akkor most írnom kell folytatást? :)
Gondolkodtam egy DirectX az alapoktól dolgon is, de az SDK példái (meg a fellelhető tutorialok)teljesen jók, ha meg bemásolom, az nem egy nagy cikkírás :)
Egy elolvasód biztos lenne ;) ( igen igaz… én nem szeretni angolt olvasni )
haskell cikk meg akkor lesz ha visszavesszuk a vezetest :)))
A mai atlag szinvonalat siman uberelheted
hajra :)
egyebkent ha az atlag konnyen uberelheto akkor miert az az atlag? ;)
de mi ez a baromság, hogy a képernyő sarka a pixel közepe?
huh. na varjal.
szal.
a kepernyo pixelekbol all, es minden pixel diszkret ertek szal nem tudsz ket pixel koze irni vagy ket pixel kozul interpolaltan olvasni. ezert a (0;0) koordinata a bal felso pixel, az (1;0) a tole jobbra levo, s igy tovabb. ha a (0;0)-ra irsz az mindig a bal felso pixel lesz, (0.5;0)-ra pedig nem tudsz fizikailag irni.
a textura is pixelekbol all, viszont az interpolaciok miatt nem diszkret adat hanem gyakorlatilag egy fuggveny n parameterrel ahol n a dimenziok szama. (jelen esetben 2.) mivel siman mondhatom azt hogy a (0.1;0.1) helyrol akarok olvasni, ezert bele kell kalkulalni azt a lehetoseget is, hogy az olvasas a pixelek KOZE esik es ekkor jon be a filtering (nearest point ha szerettuk a DOOMot, bilinear ha nem, stb.) namost, mivel a fuggvenyunk parameterei a ]0;1] intervallumba esnek, ezaltal nem tudjuk pixelpontosan megmondani hogy melyik pixel hol van, mert azt ugye a hardver kezeli, csak annyit tudunk, hogy a 0 a textura bal szele (effektiv a szele, nem a legszelso pixelsor!), az 1 pedig a jobb szele.
namarmost. nekunk ugye az kene hogy ami a texturan a balfelso pixel, az a kepernyon is annyi legyen.
tudjuk hogy a texturank balszele 0, jobbszele 1, es hogy X db pixel szeles. akkor ugye ha eltoljuk 1/X-el a texturakoordinatakat, akkor a pixelek is pont 1el csusznak arrebb. ha viszont 0.5/X-el toljuk el, akkor a 0-s koordinata az pontosan a textura elso pixeloszlopara fog esni, ami _elvileg_ pixelpontos.
ha ez kicsit kodos lenne, akkor probald (zanzasitva) ugy felfogni, hogy:
– a videomemoria / kepernyo egy TOMB aminek egeszerteku indexei vannak
– a textura egy FUGGVENY aminek lebegopontos bemenete van, es a 0 ertek a textura bal szelet jeloli ami a balszelso es jobbszelso pixel-oszlopok 50-50% kevereke.
remelem nem bonyolitottam tul :)
Fú Bery, ez jó cikk volt. Kedvet is kaptam a dologhoz, már csak írni kellene egy engine-t, mert ami van az szar…. :)
Gargaj: köszi, így tisztább a dolog!
FooLman: szarunk a szar enginre, lényeg a release ;)
Bala: már úgy kiéheztetted Haskell-re a népet, hogy simán 100 komment lesz utána, hogy “Köszi!”, “Na végre!”, “Jajj, már úgy vártam!” ;)
Gargaj | jan.10. 18:27 hozzászólása simán jó lenne cikknek ( de mé, de méééé nem irol cikket! ) Gargaj… cikket akarunk, cikket akarunk!!! \o/.
Azert, mert egy materialis dolog elmeleti kiterjesztese mindaddig nem emeli az atlagot amig az meg nem valosul. :) Masfelol miert is? Hisz amig ezt az erzest biztositja a szituacio, addig nyilvan nem erdemes egy onnmagat gerjeszto folyamattal minden jokedvnek elejebe menni… :) Ez ugyanolyan irrealis szituacio, mint pl. a szolasszabadsag. Tudni, hogy barmit mondhatok, meg nem jelenti, hogy mondanom is kellene vagy nem ? :) Most akkor kezdek osszezavarodni ?! ;P
abcug: egyébként te d3dx-el meg is csináltad a saját enginedet a fenti featureokkal?
Én 1-2 kisebb projectben használtam komolyabban is a d3dx-et, de nem állítanám, hogy különösebben jó tapasztalataim lennének vele.
murphy: d3d (d3dx-e)-t munka miatt hasznalom elsosorban, mert imho kenyelmesebb, mint a gdi (vagy gdi+) es mert moka ilyesmit csinalni. Ha mar melo, legyen szorakoztato. :) 2005-vegen (az stfu-s) korszakom utan ujrairtam mindent igy lett egy ‘abacus.dll’ ami nem igazan demo engine, inkabb amolyan 3d toolkeszlet. Ha van idom (ez gond) es talalok valami erdekes leirast, akkor megcsinalom a dll-hez, oromkodok, hogy ilyet is tudok es ennyi.
Anim controllerrel pl. eleg sokat jatszottam, volt egy-ket olyan demo szeru (nem annak keszult) scene is (animalt objektek, skinning, shadowmap, … ilyesmi) es itt a cegnel pl. Radeon 9250-en is nagyon szepen ment (~100’000 koruli faces -> 40-50 fps). (Ez ugyan nem egetrengeto, de nincs is optimalva semmi es a vas amin futott sem tul eros.)
Légyszi a cikk címének első karakterét cseréljétek rövid u-ra… Egyébként meg Bery, tökjó hogy írtál ilyet :)
aha: azer mer ennyi, ott a cikk, kesz. masreszt honnan tudjam h kit mi erdekel? :D
Hmm, ha valaki Grafikus Nyelv Arnyalo Nyelvet (GLSL) hasznal esetleg, azt tortenik itten, hogy a GetUniformLocation, GetAttribLocation tipusu fuggvenyek random oszcillalva adjak vissza a helyes erteket illetve (-1)-et. Az ido telesevel raadasul romlik a helyzet… Na ilyet latott-e valaki mar, mert nekem eleg vadnak tunik? (google sem segitett…)
hat aki olyat hasznal azzal Szar Tortenik :)
hat ez nagyon kedves es konstruktiv megjegyzes volt :)
egyebkent a trivialis hekk-megoldas *latszolag* mukodik, de azt tovabbra sem tudom hogy az eleg hosszu szoftverlancolat melyik elemeben Tortenik A Szar….
blala: mondjuk oszd meg velünk a shaderkódot és a GetAkármi függvényeid paramétereit, és akkor többet tudunk mondani. :)
Nem a shader-koddal van a baj, hanem a rendszerrel. A GetAkarmi az arra valo hogy parametereket lehessen atadni a “foprogrambol” a shadernek (kb megmondja hogy hova kell irni).
Es azert sem osztom meg a shaderkodot mert ronda es bugos es ertelmetlen :)
blala: szerintem tudjuk, mire való a GetAkármi :)
Csak gondoltam, hátha rájövünk, miért ad vissza hülyeséget. Persze nem erőszak a disznótor, csak így kicsit olyan ez a kérdésed, mint hogy “Sanyikám, lefagyott az internet! Mit csináljak?”
Ja, hat ha tudod az mas, nekem nem ez jott le az elozo hsz-bol, azert irtam. De akkor meg miert kerted a shaderkodot? :)
Na errol van szo: Egyszer leforditod az egyetlen shaderdet ami lehet barmi, akar tok trivialis, mondjuk egyetlen uniform parameter van, pl egy szin es mindig azt a szint adja vissza; meghivod a GetUniformLocation-t kepkockankent fix parameterrel, hogy mindig megvaltoztasd ezt a szint (es buta vagy mert nem az elejen egyszer hivod meg es eltarolod, hanem mindig megkerded ujra). Na ez nem jo, az elso par kepkockaban meg megmondja, utana elkezdi nem megmondani, aztan megint megmondja, aztan megint nem…
Tehat a kerdes inkabb olyan, hogy “Sanyikam, egeszen furcsa modon fagyott le az internet, az Index sarkaban elkezdett egy ketharmadig tele vodkasuveg villogni, ilyet lattal-e mar he?”
Igazából az én első kérdésem az lenne, hogy miért kéred le a uniformlocationt minden frame-ben. Mert ugye azt el lehet tárolni, és úgy gyorsabb is.
Persze ez nem magyarázat a jelenségre, de a villogó vodkásüvegnek köze lehet hozzá…
Azert kertem le mert egyszerubb volt ugy es lusta voltam, es nem kritikus a sebessegveszteseg (nem tobbezer hivasrol van szo framenkent, csak nehanyrol). Haskell-ben ugye hivatalosan nincsenek valtozok ahol el lehet tarolni dolgokat :). Amugy atirtam mar hogy csak az elejen kerem le, es igy *latszolag* mukodik, de ez nem valtoztat a kerdesen hogy miert nem mukodott elso korben.
Viszont, ami nagyon furcsa, hogy a GetAttribLocation egeszen hasonloan viselkedik, de amikor framenkent kertem le, volt olyan tesztprogram hogy mar az legelso frameben is (-1)-et adott vissza, meg mindig. A GetUniform pedig a konzisztensen az elso 13 frameben adott vissza jot, utana rosszat. Masik tesztprogramnal meg random oszcillal… Szoval nem ertem.
A hiba lehet elvileg a Haskell-OpenGL bindingben, vagy az OpenGL driverben (lusta voltam irni egy C tesztprogramot a masodik kizarasara, foleg hogy nemtom hogy kell ablakot nyitni :) Az hogy tok random a jelenseg, arra utal hogy valami race condition jellegu bug lehet valahol; de pl az hogy multithreaded vagy singlethreaded runtime-al forditok, az semmin sem valtoztat.
Igazabol azert irtam be ide mert hatha latott mar valaki ilyet, vagy ez egy jol ismert bug valami driverben, vagy nemtom.
(ja, viszont megneztem a haskell-opengl binding forrasat, es az csak siman meghivja a megfelelo opengl rutint, szoval valaminek nagyon el kell romolnia ahhoz hogy ott tortenjen a hiba)
Race condition könnyen lehet, OpenGL nem szeret multithreadben futni, legalábbis a legtöbb driver allergiás rá. Nem tudom, hogy a Haskell hogyan szervezi az automatikus szálait (már ha van benne ilyen egyáltalán), de pl. arra tudok gondolni, hogy két szál is bindol egy shadert, hogy abból attribot kérjen le, és ez jól összeakad. De leginkább fogalmam sincs.
nem lehet, hogy a haskell szimplan irigykedik a shaderedre, mert neki nincsenek valtozoi ? :)
hosszutavon ez amugysem tesz jot sem a haskell, sem az ogl megitelesenek, szoval jot tenne az ugynek, ha eloallnal valami frappans megoldassal, pl. typo vagy ilyesmi :)))
vagy egy kiadott demo is nagyban lenditene a helyteten :P
Jimmi: singlethread-es runtime-al is ugyanez az eredmeny, latszolag. A Haskell-ben lightweight thread-ek vannak, az OS itt nem jatszik (kiveve hogy a driver maga az nyilvan masik thread/process/whatever); es az sincs automatikusan legjobb tudomasom szerint, legfeljebb ha expliciten kerem. Szoval a default a single single. En se tudom mi tortenik, kulonben nem kerdeznem :)
abcug: http://wordpress.scene.hu/?p=347 :)
Nah bar ez senkit nem erdekel gondolom rajtam kivul, de azert ideirom, hogy megtalaltam a hibat, es a Haskell-OpenGL bindingben volt. Nem rakott nullakat a csavo a stringek vegere, aztan ha veletlenul nulla volt ott a memoriaban akkor mukodott, egyebkent meg nem…