|
|
|
|
Idézet
kuzanth :
Közben azon gondolkodtam, hogy oké, hogy eltolok egy normál rendert, majd ezt elmentem egy textúrába...de az ezt követő sima render és bloomos render hogy fog megjelenni egymáson  ??? Mert elvileg olyan bloomot már sikerült csinálni, ami csak a modellen belül volt látható...vagy nem? Ez végülis olyan, nem? Mármint objektumon belüli bloom...
Az egész scene-t egy textúrába lerendereled, majd erre a textúrára alkalmazod a bloomot, és mint egy sima téglalapot kirajzolod a képernyőre, nagy vonalakban ezt kéne csinálnod, de ezt már mások is írták előttem...
|
|
|
|
Idézet
kuzanth :
Közben azon gondolkodtam, hogy oké, hogy eltolok egy normál rendert, majd ezt elmentem egy textúrába...de az ezt követő sima render és bloomos render hogy fog megjelenni egymáson ???
Ha már megvan a textúrád, akkor egyszerűen blend-eled a render-t a textúrával és készen is van.
|
|
|
|
Közben azon gondolkodtam, hogy oké, hogy eltolok egy normál rendert, majd ezt elmentem egy textúrába...de az ezt követő sima render és bloomos render hogy fog megjelenni egymáson ??? Mert elvileg olyan bloomot már sikerült csinálni, ami csak a modellen belül volt látható...vagy nem? Ez végülis olyan, nem? Mármint objektumon belüli bloom...
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Menjünk már sorba, plíz  ! Ez a vb létrehozás jó?
Kód: //Az osztály inic-je végén
...
vb = new VertexBuffer(dev, 4 * System.Runtime.InteropServices.Marshal.SizeOf(typeof(D3DPOINTERVERTEX)), Usage.None,
PointVertexFVF, Pool.Default);
D3DPOINTERVERTEX[] d3dpv = (D3DPOINTERVERTEX[])vb.Lock(0, typeof(D3DPOINTERVERTEX), LockFlags.None, 4);
d3dpv[0].color = d3dpv[1].color = d3dpv[2].color = d3dpv[3].color = 0x43F;
d3dpv[0].p = new Vector4(0.0f, 767.0f, 0.0f, 1.0f);
d3dpv[0].tu = 0.0f; d3dpv[0].tv = 1.0f;
d3dpv[1].p = new Vector4(0.0f, 0.0f, 0.0f, 1.0f);
d3dpv[1].tu = 0.0f; d3dpv[1].tv = 0.0f;
d3dpv[2].p = new Vector4(1023.0f, 767.0f, 0.0f, 1.0f);
d3dpv[2].tu = 1.0f; d3dpv[2].tv = 1.0f;
d3dpv[3].p = new Vector4(1023.0f, 0.0f, 0.0f, 1.0f);
d3dpv[3].tu = 1.0f; d3dpv[3].tv = 0.0f;
vb.Unlock();
...
//Mint különálló struktúra
public struct D3DPOINTERVERTEX
{
public Vector4 p;
public int color;
public float tu, tv;
};
const VertexFormats PointVertexFVF = (VertexFormats.PositionW | VertexFormats.Diffuse | VertexFormats.Texture1);
...
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Nézd meg újra, hogy biztosan jó textúrát adsz-e át..
|
|
|
|
"mintha csak azt az 1 textúrát bloomolnád, és nem scene-t"
Igen engem is ez zavar, de sztem már az alapoktól kezdve rossz a kód. Főleg a vertexbufferes részt kéne átnézni, ill a PP rendert (mármint amikor már megvan a RendertargetTexture, és azt kell felhúzni a quad-ra). Sztem ott lesz a bibi.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
You don't have permission to access /video2/images/terms2k5/bloom_scpt.jpg on this server.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Bloomot még nem írtam, de sztem itt shaderrel lesz a bibi( csak tipp ), tehát bloomolt dolgoknak "tündökölnie" kéne( mint itt ), nem?; de nálad nem tündököl, tehát mintha csak azt az 1 textúrát bloomolnád, és nem scene-t, máshogy fogalmazva: mintha nem pp effect lenne, hanem csak a gömb textjére lenne a bloom shader ráeresztve, nem pedig magára a jelenetre(amit egy textúrába lerenderelsz), ha nem így lenne, akkor TPG pls javíts ki
|
|
|
|
|
|
Jelenleg itt tartok. Ez már hasolít a helyes megoldásra? Kezdek kicsit belezavarodni a dologba  ... Itt a kód.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Úgy rémlik egyszer beszéltem vele, és azt mondta, hogy nem foglalkozott ilyennel...Na majd msn-en, ha erre jár!
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
kuzanth :
Próbáltam megérteni az SDK-s C++ PP progit, de vagy én vagyok nagyon hülye, vagy csak direkt bonyolultan írták meg, de én mindig elvesztem a fonalat  ... No meg eleve sztem gáz ez a managed vs. unmanaged programozás (lásd vertexbuffer használat), mert sztem itt lesz a hiba. A baj csak az, hogy lövésem sincs erről a vb használatról. Megnéztem a vb tutorialt is, de ott meg nem ilyen formában használják a dolgokat. Tényleg senki nem csinált még C#-ban PP-t???
"Hogy kellene kinéznie ha rendesen működne?" - Passz. Feltételezem az a blur-ös kép a gömbön a végeredményt sejteti, de ezt nem tudom megmondani, amíg legalább egyszer nem látom a végeredményt rendes körülmények között...
Talán GyMisi tudna segíteni MDX-ben, ő vágja mint a fene de nekem a kép alapján úgy tűnt hogy már csak az effect fájl körül lehetnek galibák (de ez nem biztos csak olyan megérzés  ).
Reality is almost always wrong. - House
|
|
|
|
Próbáltam megérteni az SDK-s C++ PP progit, de vagy én vagyok nagyon hülye, vagy csak direkt bonyolultan írták meg, de én mindig elvesztem a fonalat ... No meg eleve sztem gáz ez a managed vs. unmanaged programozás (lásd vertexbuffer használat), mert sztem itt lesz a hiba. A baj csak az, hogy lövésem sincs erről a vb használatról. Megnéztem a vb tutorialt is, de ott meg nem ilyen formában használják a dolgokat. Tényleg senki nem csinált még C#-ban PP-t???
"Hogy kellene kinéznie ha rendesen működne?" - Passz. Feltételezem az a blur-ös kép a gömbön a végeredményt sejteti, de ezt nem tudom megmondani, amíg legalább egyszer nem látom a végeredményt rendes körülmények között...
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
kuzanth :
Az MDXInfo-n nem találtam használható anyagot (egyébként már jártam ott korábban is). Viszont kijavítottam egy-két dolgot, de még mindig hibás valami. A hibáról itt egy kép, a .cs fileom pedig letölthető innen. Megtennétek, hogy segítetek kijavítani a hibát? Előre is köszi !
Hogy kellene kinéznie ha rendesen működne? Az effect file-ban biztos nincs hiba? A file-t amit linkeltél átfutottam és nem láttam benne hibát (de azt még mindig nem értem miért a renderelés közben hozod létre az RT-t miért nem előtte, a textúrakészítés lassú dolog).
Reality is almost always wrong. - House
|
|
|
|
Idézet
TheProGamer :
Idézet
MaNiAc :
Értem én, csak ez így tetves lassú... egyrészt a másolás, másrészt az AA miatt... Megér ennyit az AA? 
Én magam nem mértem a különbséget sebességben a kettő közt, sőt fel sem tűnt hogy nagyon lassabb lenne. A Gamedev.net-en is azt írják hogy nem különösen lassabb. És eleve az ötletet egy nVidia doksiban olvastam ők meg nem ajánlanák ha lassú lenne (van még néhány megoldás erre a problémára, sztem nem véletlen foglalkoztak pont ezzel). A másik dolog pedig az hogy a StretchRect() amivel a másolást végzem DX9 alatt már HW-s gyorsítással dolgozik. Tehát a másolás részt azért rendes sebességgel el lehet intézni, az AA meg tényleg lassít, arra nincs gyógyír.
Kis kiegészítés: most nézem hogy a Source engine-ben is nem egyszer használják ezt a trükköt (olyan helyeken ahol nem is lenne feltétlen szükséges) úgyhogy tényleg nem lehet baj a sebességével.
Reality is almost always wrong. - House
|
|
|
|
Nos? Senki? Ne hagyjatok magamra!
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Az MDXInfo-n nem találtam használható anyagot (egyébként már jártam ott korábban is). Viszont kijavítottam egy-két dolgot, de még mindig hibás valami. A hibáról itt egy kép, a .cs fileom pedig letölthető innen. Megtennétek, hogy segítetek kijavítani a hibát? Előre is köszi !
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
kuzanth :
Idézet
kuzanth :
Tudnál adni egy teljes forráskódot, ahol mondjuk egy kocka van bloomolva?
Csak emlékeztetőül...
Az mdxinfo-n nézzél körül tuti találsz.
Reality is almost always wrong. - House
|
|
|
|
Idézet
kuzanth :
Tudnál adni egy teljes forráskódot, ahol mondjuk egy kocka van bloomolva?
Csak emlékeztetőül...
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
syam :
mj: a bloomhoz nem ajánlanak fsaa-t.
sőt ha nagyobb a postprocess textured mint a felbontás az automatikus aa-zik
Jah ha nagyobb textúrát küldesz ki a képernyőre mint a felbontás annak is ilyen hatása van, naggyából a supersampling is így működik. ("Supersampling works by simply scaling up the resolution of the frame buffer. For example, if you're working in a 800x600 screen resolution, then (for 4X supersampling) it uses a 1600x1200 buffer internally."-devmaster.net) És a manapság használt multisampling gyorsabb a supersampling-nél.
Az igazi bloomhoz meg tényleg nem ajánlanak AA-t mivel a mostani nV kártyák pl képtelenek lebegőpontos surface/texture-el AA-zni. (Asszem az X1***-es ATI karik már tudnak de magam még sohasem láttam.)
Reality is almost always wrong. - House
|
|
|
|
aham vmi ilyesmire
például így néz ki nálam
512*512 -> 640*480
a 512->640 miatt annyira nem látványos, de így sem nagyon kockás
alias aalberik
|
|
|
|
"nagyobb a postprocess textured..."
Erre gondolsz?
Kód: Texture rendertargettexure = new Texture(dev, dev.DisplayMode.Width, dev.DisplayMode.Height, 1, Usage.RenderTarget, Format.X8R8G8B8,
Pool.Default);
Mert ez ugye pont akkora textúra lesz, mint a felbontás .
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
mj: a bloomhoz nem ajánlanak fsaa-t.
sőt ha nagyobb a postprocess textured mint a felbontás az automatikus aa-zik
alias aalberik
|
|
|
|
Tudnál adni egy teljes forráskódot, ahol monduk egy kocka van bloomolva?
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
MaNiAc :
Értem én, csak ez így tetves lassú... egyrészt a másolás, másrészt az AA miatt... Megér ennyit az AA?
Én magam nem mértem a különbséget sebességben a kettő közt, sőt fel sem tűnt hogy nagyon lassabb lenne. A Gamedev.net-en is azt írják hogy nem különösen lassabb. És eleve az ötletet egy nVidia doksiban olvastam ők meg nem ajánlanák ha lassú lenne (van még néhány megoldás erre a problémra, sztem nem véletlen foglalkoztak pont ezzel). A másik dolog pedig az hogy a StretchRect() amivel a másolást végzem DX9 alatt már HW-s gyorsítással dolgozik. Tehát a másolás részt azért rendes sebességgel el lehet intézni, az AA meg tényleg lassít, arra nincs gyógyír.
Reality is almost always wrong. - House
|
|
|
|
Hát én pl az Oblivion-ban majdnem agyvérzést kaptam, amikor AA nélkül kellett menni. Szóval sztem megéri. Egyébként tényleg k. sokat lassít.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Értem én, csak ez így tetves lassú... egyrészt a másolás, másrészt az AA miatt... Megér ennyit az AA?
|
|
|
|
Idézet
MaNiAc :
Idézet
1. textúrázó shaderes render
2. Textúra létrehozás, hogy bele rendereljünk + getsurfacelevel + stretch, meg ami kell
3. ZBuffer kikapcs
4. A bloom shadernek átpasszintom ezt a textúrát és renderelem a quadot.
5. Egyéb render (text kiírás, stb...)
Na de akkor itt mikor renderelsz a textúrára?
TPG: Az első két lépés egy "kicsit eltér" attól, ahogy én írtam... Ha jól emléxem, a DX már ősidők óta direktbe a textúrára renderel nem?  (Mert ez a módszer, az ős-opengl r2t-re emlékeztet, ahol először a framebufferbe rendereltek, aztán onnan kimásolták a képet, majd törölték a framebuffer-t, etc...)
Igen ez a trükk az egészben. Az alap PP-nél konkrétan a textúrát állítod be Render Target-nek, abba renderelsz, rádobod a quadra a shaderrel és újra rendereled a backbuffer-be. Viszont ennek az a baja hogy nem lehet vele AA-t használni mivel AA-s textúrát nem lehet létrehozni. Itt jön a csavar az egészben. A jelenetet AA-val a backbufferben rendereljük majd a buffer komplett tartalmát átmásoljuk a textúra 0. szintjére és innen ugyanúgy megy az egész mint előtte. Így már megy az AA a PP-vel együtt.
Reality is almost always wrong. - House
|
|
|
|
Na ennyire nem vagyok azert benne az MDX-ben A StretchRectangle() mit csinal pontosan?
|
|
|
|
Kód: int passes = effect2.Begin(0);
for (int ef = 0; ef < passes; ef++)
{
effect2.SetValue("ModelWorld", mat * view * proj);
effect2.SetValue("meshtexture", meshTexture);
effect2.BeginPass(ef);
o.mesh.DrawSubset(0);
effect2.EndPass();
}
effect2.End();
hiba = "drawsubset";
hiba = "1.endscene";
dev.EndScene();
#endregion
Texture rendertargettexure = new Texture(dev, dev.DisplayMode.Width, dev.DisplayMode.Height, 1, Usage.RenderTarget, Format.X8R8G8B8,
Pool.Default);
oldrendersurface = dev.GetRenderTarget(0);
rendersurface = rendertargettexure.GetSurfaceLevel(0);
dev.StretchRectangle(oldrendersurface, renderrect, rendersurface, renderrect, TextureFilter.None);
Elvileg itt megy a textúrába a renderelt kép. Az effect csak egy sima textúrázó shader, semmi több.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
1. textúrázó shaderes render
2. Textúra létrehozás, hogy bele rendereljünk + getsurfacelevel + stretch, meg ami kell
3. ZBuffer kikapcs
4. A bloom shadernek átpasszintom ezt a textúrát és renderelem a quadot.
5. Egyéb render (text kiírás, stb...)
Na de akkor itt mikor renderelsz a textúrára?
TPG: Az első két lépés egy "kicsit eltér" attól, ahogy én írtam... Ha jól emléxem, a DX már ősidők óta direktbe a textúrára renderel nem? (Mert ez a módszer, az ős-opengl r2t-re emlékeztet, ahol először a framebufferbe rendereltek, aztán onnan kimásolták a képet, majd törölték a framebuffer-t, etc...)
|
|
|
|
Hát igazság szerint én a te cikked alapján dolgoztam, és nem nagyon láttam mást a vb-vel kapcsolatban, csak hogy fel van töltve inicnél. Nem is teljesen értettem a cikkedenek ezen részét (egyébként ha jól tudom te eleve nem tömbbként adod meg a D3DPOINTVERTEX-et). Szóval azt a vb-s részt szívesen meghallgatnám újra, mert ezek szerint nem értettem meg a cikked ... A VS-es gondolat tényleg gyanus...Átírom!
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
kuzanth :
Közben az is eszembe jutott, hogy a D3DPOINTERVERTEX-et sem lehetett egy az egyben átírni úgy, ahogy TheProGamer mondta!!!
Én megadtam az én FVF-emet, az átalakítás már a te feladatod mivel én jelenleg olvasás és konzolos progik írása szinten vágom a C#-ot, az MDX elég messze áll még tőlem (azért megérteni megértem az MDX kódot). Egyébként átfutottam a kódodon, és találtam pár gyanus dolgot. PL:post-process menetben nincsen vertex-shader mivel a quad már alap esetben a transoformált értékeket tartalmazza tehát nem kell mátrixokkal bántani. A másik számomra érdekes a VB feltöltése a quad-nál. Ott abba a tömbbe amibe dolgozol hogy kerülnek bele a vertexek adatai? Sztem nézz ennek utána, mert lehet hogy csak én vagyok hülye és nem értem de az is lehet hogy tényleg nem stimmel ott valami.
Reality is almost always wrong. - House
|
|
|
|
Közben az is eszembe jutott, hogy a D3DPOINTERVERTEX-et sem lehetett egy az egyben átírni úgy, ahogy TheProGamer mondta!!!
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
MaNiAc :
Nem úgy kéne, hogy az egészet rendereled egy textúrára (képernyőre nem), aztán bekapcsolod a bloom shader-t, majd a képernyőre teszel egy sima quad-ot, és végül arra ráhúzod az előbb legyártott textúrát?
Jah, de ő is majdnem ugyanezt mondja csak máshogy. Vagy nem? A kódban kb ez a menet működik ha jól láttam.
Reality is almost always wrong. - House
|
|
|
|
Elvileg ezt csinálom, csak sztem nagyon bekavar az, hogy C++ -ban lehet előre meg nem adott méretű struktúra alapján vertexbuffert létrehozni. Azaz nem kell beállítani az értékeket, csak létrehozod a struktúrát, és azt már passzinthatod is a vb konstruktorába. A C# szól, hogy ez Unmanaged kódhoz vezet, ezért asszem nem is engedi. Egyébként ezt csinálom :
1. textúrázó shaderes render
2. Textúra létrehozás, hogy bele rendereljünk + getsurfacelevel + stretch, meg ami kell
3. ZBuffer kikapcs
4. A bloom shadernek átpasszintom ezt a textúrát és renderelem a quadot.
5. Egyéb render (text kiírás, stb...)
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
kuzanth :
Úgy értem, hogy amikor megvan a bloom effect, a végeredményt kell ráhúzni a quadra, nem? Tehát megy a sima render, felette meg a quad, amin már a bloomos effect van. Ha nem akkor félreértettem az egész PostP.-t....
Nem úgy kéne, hogy az egészet rendereled egy textúrára (képernyőre nem), aztán bekapcsolod a bloom shader-t, majd a képernyőre teszel egy sima quad-ot, és végül arra ráhúzod az előbb legyártott textúrát?
Elméletben ez lenne az összes, egyszerűbb shader-re épülő (mint pl a bloom) postprocess menete, legalábbis nagyvonalakban...
|
|
|
|
Idézet
kuzanth :
Szívesen elküldöm a kódot, ha az segít, bár elég...hogy is mondjam...csúnya a külalak (egyelőre csak azt akartam, h fusson, aztán majd utánna szépítgetem.). A teljes kód zippelve 160k, az *.ex-et át kell nevezni *.exe-re. Elvileg ez lesz az
Már vizsgálom.
Reality is almost always wrong. - House
|
|
|
|
Szívesen elküldöm a kódot, ha az segít, bár elég...hogy is mondjam...csúnya a külalak (egyelőre csak azt akartam, h fusson, aztán majd utánna szépítgetem.). A teljes kód zippelve 160k, az *.ex-et át kell nevezni *.exe-re. Elvileg ez lesz az
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
kuzanth :
Hát elvileg ez lett az eredménye az átiratnak  . Valamit nagyon, de nagyon el......
Hmm egyenlőre próbálom felfogni mit ábrázol a kép, de nekem egyenlőre átkozottul ismerős valahonnan. Megpróbálom reprodukálni.
Reality is almost always wrong. - House
|
|
|
|
Nézzük már meg a kódot, mert sztem zsír ugyanazt csinálom, mint ami a cikkben volt, de még mindig nem műkszik.
Kód: ...
//ez itt az osztály konstruktora
vb = new VertexBuffer(dev, 6*sizeof(float)+sizeof(uint), Usage.None, PointerVertexFVF, Pool.Default); //lehet, hogy itt lesz gond, mert C#-ban nem lehet előre meg nem határozott méretű vb-t létrehozni
D3DPOINTERVERTEX[] d3dpv = new D3DPOINTERVERTEX[4];
int[] array = new int[4];
vb.Lock(0, typeof(D3DPOINTERVERTEX), LockFlags.Discard, array);
d3dpv[0].color = d3dpv[1].color = d3dpv[2].color = d3dpv[3].color = 0xFFFFFFFF;
d3dpv[0].p = new Vector4(0.0f, 767.0f, 0.0f, 1.0f);
d3dpv[0].tu = 0.0f; d3dpv[0].tv = 1.0f;
d3dpv[1].p = new Vector4(0.0f, 0.0f, 0.0f, 1.0f);
d3dpv[1].tu = 0.0f; d3dpv[1].tv = 0.0f;
d3dpv[2].p = new Vector4(1023.0f, 767.0f, 0.0f, 1.0f);
d3dpv[2].tu = 1.0f; d3dpv[2].tv = 1.0f;
d3dpv[3].p = new Vector4(1023.0f, 0.0f, 0.0f, 1.0f);
d3dpv[3].tu = 1.0f; d3dpv[3].tv = 0.0f;
vb.Unlock();
...
...
//A renderen belül itt jön egy szimpla mátrix beállítás, és egy shaderes textúrázás, majd rajzolás, azaz semmi extra. Ezután jön a PP.
Texture rendertargettexure = new Texture(dev, dev.DisplayMode.Width, dev.DisplayMode.Height, 1, Usage.RenderTarget, Format.X8R8G8B8,
Pool.Default);
oldrendersurface = dev.GetRenderTarget(0);
rendersurface = rendertargettexure.GetSurfaceLevel(0);
dev.StretchRectangle(oldrendersurface, renderrect, rendersurface, renderrect, TextureFilter.None);
dev.Clear(ClearFlags.Target | ClearFlags.ZBuffer,
System.Drawing.Color.FromArgb(0, 0, 0), 1.0f, 0);
dev.SetRenderState(RenderStates.ZEnable, false);
dev.SetRenderState(RenderStates.Lighting, false);
dev.BeginScene();
passes = effect1.Begin(0);
for (int ef = 0; ef < passes; ef++)
{
effect1.SetValue("WorldViewProj", mat * view * proj);
effect1.SetValue("blurvalue", 3.0f);
effect1.SetValue("bloomvalue", 1.5f);
effect1.SetValue("meshtexture", rendertargettexure);
dev.SetStreamSource(10, vb, 10 * sizeof(float) + sizeof(uint)); //ez kérdéses
dev.VertexFormat = PointerVertexFVF; //és ez is kérdéses
effect1.BeginPass(ef);
dev.DrawPrimitives(PrimitiveType.TriangleStrip, 0, 2);
effect1.EndPass();
}
effect1.End();
//dev.SetRenderState(RenderStates.ZEnable, true);
//dev.SetRenderState(RenderStates.Lighting, true);
dev.EndScene();
//Ezek után már csak a textek kiírása van hátra, tehát szintén semmi extra.
Mit rontok el?
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Hát elvileg ez lett az eredménye az átiratnak . Valamit nagyon, de nagyon el......
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
kuzanth :
Úgy értem, hogy amikor megvan a bloom effect, a végeredményt kell ráhúzni a quadra, nem? Tehát megy a sima render, felette meg a quad, amin már a bloomos effect van. Ha nem akkor félreértettem az egész PostP.-t....
Ha jól értem jah. Fogod az RT texet amit bloomolni akarsz rápakolod a fullscreen quad-ra, ráengeded a bloom shadert és renderelsz. A ZBuffer-t meg kilövöd mert tök felesleges és csak bekavarhat.
Reality is almost always wrong. - House
|
|
|
|
Úgy értem, hogy amikor megvan a bloom effect, a végeredményt kell ráhúzni a quadra, nem? Tehát megy a sima render, felette meg a quad, amin már a bloomos effect van. Ha nem akkor félreértettem az egész PostP.-t....
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
kuzanth :
Biztos a vertexbuffert csinálom meg rosszul, de egyelőre csak fekete hátteret látok, ill. néha-néha bejön egy színes háromszög-szerű izé (de legalább már nincs hiba üzenet...). Az előző kérdésem pedig nem a bloomhoz kapcsolódott, hanem a megjelenítéséhez.
Azt próbáltad már hogy csak egy sima texet húzol a fullscreen quadra? Az eredményeiből elég sokmindenre lehet következtetni.
Egyébként a bloom megjelenítése nem a bloomhoz kapcsolódik? Itt is az a lényeg hogy a bloomot nem az objektumokon hajtjuk végre hanem post process az elkészült 64/128bites lebegőpontos textúrán elég sok menetben (ugyebár a bloom annyiban különbözik a HDR-től hogy nincs luminance calc, hanem fix lum értékkel dolgoznak csak bright pass, exposure conrtol/tone mapping meg bloom és star filter van).
Reality is almost always wrong. - House
|
|
|
|
Biztos a vertexbuffert csinálom meg rosszul, de egyelőre csak fekete hátteret látok, ill. néha-néha bejön egy színes háromszög-szerű izé (de legalább már nincs hiba üzenet...). Az előző kérdésem pedig nem a bloomhoz kapcsolódott, hanem a megjelenítéséhez.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
kuzanth :
Sajna még nem tudtam tesztelni, de közben eszembe jutott egy dolog (hívhatjuk problémának is ). Ha csak bizonyos dolgokat akarunk bloomolni, akkor ugye azokkal külön kell foglalkozni. Ezzel nincs is baj. De mi van akkor, ha egy bloomos modellt FÉLIG(!!!) eltakar egy nem bloomos??? A bloom nem fog "átlátszani" az elöl lévő modellen??? Itt ugyanis már ki van kapcsolva a ZBuffer, szóval még azt sem tudnám mondani, hogy majd ott eldől, hogy mi látszódjon és mi ne... Ha sikerül előcsalnom az effectet, ezt mindenképp megpróbálom, de addig érdekelnek a vélemények!
Szerintem félreérted a bloom fogalmát teljesen, most nem állok neki megmagyarázni mivel tervezem az egész bloom/HDR témát cikk keretein belül kitárgyalni még a hétvégén (meg be akarom fejezni a shaderes cikk második részét és belekezdeni egy Deffered Shading-et tárgyalóba, márcsak az a kérdés mi fog ebből megvalósulni).
Reality is almost always wrong. - House
|
|
|
|
Sajna még nem tudtam tesztelni, de közben eszembe jutott egy dolog (hívhatjuk problémának is ). Ha csak bizonyos dolgokat akarunk bloomolni, akkor ugye azokkal külön kell foglalkozni. Ezzel nincs is baj. De mi van akkor, ha egy bloomos modellt FÉLIG(!!!) eltakar egy nem bloomos??? A bloom nem fog "átlátszani" az elöl lévő modellen??? Itt ugyanis már ki van kapcsolva a ZBuffer, szóval még azt sem tudnám mondani, hogy majd ott eldől, hogy mi látszódjon és mi ne... Ha sikerül előcsalnom az effectet, ezt mindenképp megpróbálom, de addig érdekelnek a vélemények!
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
|
Idézet
kuzanth :
Már majdnem megcsináltam a működő kódot, amikor észrevettem, hogy valamilyen egyéni vertexbuffert kéne használni. A cikkedben ennyit látok : D3DSCREENVERTEX. Ennek viszont nem látom a megvalósítását. Bár magamtól próbáltam olyan vb-t csinálni, ami a kódból valószínűnek tűnik, de amikor beírtam a "4*sizeof()"-ot, azt mondta, hogy ez unmanaged kódhoz vezet, mert nincs pontos kezdő méret. Megtennéd, hogy bedobod ide a vb-hez tartozó kódot?! Kösze! Ja és kéne a felhasználni kívánt vertexek típusa is (én vmi ilyet írtam, mert C#-ban nem volt olyan típus, mint a cikkedben : vertextype.Position | vertextype.Texture1). Ez így nem tudom jó-e...?
Én egy picit univerzálisabb FVF-et használok:
struct D3DPOINTERVERTEX
{
D3DXVECTOR4 p;
DWORD color;
FLOAT tu, tv; //lehetne D3DXVECTOR2 is de nekem ez valamiért megragadt a kódban
};
const DWORD PointerVertexFVF = (D3DFVF_XYZW|D3DFVF_DIFFUSE|D3DFVF_TEX1);
A Diffuse color jól jöhet bármikor de lényegében elhagyható, a D3DFVF_XYZW meg lehet még D3DFVF_XYZRHW is de nem D3DFVF_XYZ (a D3DFVF_XYZW és a D3DFVF_XYZRHW is már transzformált koordinátákat feltételez a vertex bufferben tehát nem fogja végigszorozni a három mátrix-al). Gondolom innen már pillanatok alatt át tudod tolni kódot C# alá.
Reality is almost always wrong. - House
|
|
|
|
Már majdnem megcsináltam a működő kódot, amikor észrevettem, hogy valamilyen egyéni vertexbuffert kéne használni. A cikkedben ennyit látok : D3DSCREENVERTEX. Ennek viszont nem látom a megvalósítását. Bár magamtól próbáltam olyan vb-t csinálni, ami a kódból valószínűnek tűnik, de amikor beírtam a "4*sizeof()"-ot, azt mondta, hogy ez unmanaged kódhoz vezet, mert nincs pontos kezdő méret. Megtennéd, hogy bedobod ide a vb-hez tartozó kódot?! Kösze! Ja és kéne a felhasználni kívánt vertexek típusa is (én vmi ilyet írtam, mert C#-ban nem volt olyan típus, mint a cikkedben : vertextype.Position | vertextype.Texture1). Ez így nem tudom jó-e...?
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???
|
|
|
Legújabb project:
Smashed Potatoes
Legutóbb frissített
project:
Smashed Potatoes
Friss kép a galériából:
|
