játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5511
FZoli:    4894
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2529

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] > 19 < [20] [22]
Aravisz - Tag | 4 hsz       Online status #36601   2006.11.14 06:56 GMT+1 óra  
Idézet
TheProGamer :
Heightmapből kell egy domborzatot előállítani vertex shaderrel? Mert az nem olyan nehéz, ráhúzod a heightmapot a sík terrain alapra, a vertex shaderben mintát veszel a heightmap-ból majd a minta alapján módosítod az adott vertex y koordinátáját. Ezzel csak két baj van: 1, csak gef6xxx és felette fog működni (vagy ezzel egyenértékü Radeonon) mert csak SM3.0-ban lehet vertex shaderben textúrából mintát venni
2, a kapott terep normáljai nem jó irányba fognak állni, ahhoz hogy az új normálokat kiszámoljuk kellenének a környező vertexek amiket meg vertex shader-ben nem lehet elérni (ezért lesz jó dolog a Geometry Shader ott ezt meg lehet csinálni). Ezt ki lehet küszöbölni úgy hogy csinálsz a heightmap mellé egy normal map-et is ami az adott vertexekhez tartozó normálokat tárolja és a vertex shaderben ebből is mintát veszel majd ezt küldöd megfelelő módosítások után tovább normálvektorként.




Pontosan ezt szeretném csinálni. De a kód írásával van főleg problémám, hlsl-ben kellene implementálnom (mert ugye a Quest3D, csak ezt fogadja el). Az első probléma is már nagy probléma. De megpróbálok egy új vidkarit kérni. Az elmélethez vannak anyagaim pl. itt. Ha vki tudna valami működő shaderrel szolgálni, azt meghálálnám . Nekem az egyszerű is bonyolult még egyelőre, de igyekszem!
Köszi.
A.

   
TPG - Tag | 3402 hsz       Online status #36599   2006.11.14 06:50 GMT+1 óra  
Idézet
TheProGamer :
Heightmapből kell egy domborzatot előállítani vertex shaderrel? Mert az nem olyan nehéz, ráhúzod a heightmapot a sík terrain alapra, a vertex shaderben mintát veszel a heightmap-ból majd a minta alapján módosítod az adott vertex y koordinátáját. Ezzel csak két baj van: 1, csak gef6xxx és felette fog működni (vagy ezzel egyenértékü Radeonon) mert csak SM3.0-ban lehet vertex shaderben textúrából mintát venni
2, a kapott terep normáljai nem jó irányba fognak állni, ahhoz hogy az új normálokat kiszámoljuk kellenének a környező vertexek amiket meg vertex shader-ben nem lehet elérni (ezért lesz jó dolog a Geometry Shader ott ezt meg lehet csinálni). Ezt ki lehet küszöbölni úgy hogy csinálsz a heightmap mellé egy normal map-et is ami az adott vertexekhez tartozó normálokat tárolja és a vertex shaderben ebből is mintát veszel majd ezt küldöd megfelelő módosítások után tovább normálvektorként.


Most belegondolok végülis be lehet szerezni a környező vertexeket is, mivel a terrain alapből szabályos négyzetekből áll ezért ki tudjuk számolni az alaphelyüket a heightmap-ből pedig a keletkezett helyüket, innen meg a normálokat.
Reality is almost always wrong. - House

   
TPG - Tag | 3402 hsz       Online status #36596   2006.11.14 06:25 GMT+1 óra  
Idézet
Aravisz :
Már megint én...
Írt már valaki terrain shadert, akár egy egyszerű heightmap alapján? Nem hiszem, hogy olyan hülyék lennétek mint én, nálam ez érthető, én lány vagyok (mellesleg inkább művészlélek mint programozó, de most ezt meg kell oldanom, sajnos )


Heightmapből kell egy domborzatot előállítani vertex shaderrel? Mert az nem olyan nehéz, ráhúzod a heightmapot a sík terrain alapra, a vertex shaderben mintát veszel a heightmap-ból majd a minta alapján módosítod az adott vertex y koordinátáját. Ezzel csak két baj van: 1, csak gef6xxx és felette fog működni (vagy ezzel egyenértékü Radeonon) mert csak SM3.0-ban lehet vertex shaderben textúrából mintát venni
2, a kapott terep normáljai nem jó irányba fognak állni, ahhoz hogy az új normálokat kiszámoljuk kellenének a környező vertexek amiket meg vertex shader-ben nem lehet elérni (ezért lesz jó dolog a Geometry Shader ott ezt meg lehet csinálni). Ezt ki lehet küszöbölni úgy hogy csinálsz a heightmap mellé egy normal map-et is ami az adott vertexekhez tartozó normálokat tárolja és a vertex shaderben ebből is mintát veszel majd ezt küldöd megfelelő módosítások után tovább normálvektorként.
Reality is almost always wrong. - House

   
TPG - Tag | 3402 hsz       Online status #36593   2006.11.14 06:15 GMT+1 óra  
Idézet
g_imi :
Nem tudom h van-e jeéentősége de rájöttem a problémára.
A következő dolgok kellenek a pass(ok)ba, amelyek közül én párat kihagytam:

ZEnable=true;
AlphaBlendEnable = true;
SrcBlend = SrcAlpha;
DestBlend = InvSrcAlpha;
BlendOp=Add;
ZEnable=true;
ZWriteEnable=false;
CullMode=none;





Nah igen a passokat nem különösen néztem. Egyébként meg kétszer szerepel a ZEnable=true; (és egyébként is true az alapbeállítása).
Reality is almost always wrong. - House

   
Aravisz - Tag | 4 hsz       Online status #36591   2006.11.14 05:45 GMT+1 óra  
Már megint én...
Írt már valaki terrain shadert, akár egy egyszerű heightmap alapján? Nem hiszem, hogy olyan hülyék lennétek mint én, nálam ez érthető, én lány vagyok (mellesleg inkább művészlélek mint programozó, de most ezt meg kell oldanom, sajnos )

   
g_imi - Tag | 236 hsz       Online status #36555   2006.11.13 16:21 GMT+1 óra  
Nem tudom h van-e jeéentősége de rájöttem a problémára.
A következő dolgok kellenek a pass(ok)ba, amelyek közül én párat kihagytam:

ZEnable=true;
AlphaBlendEnable = true;
SrcBlend = SrcAlpha;
DestBlend = InvSrcAlpha;
BlendOp=Add;
ZEnable=true;
ZWriteEnable=false;
CullMode=none;



   
g_imi - Tag | 236 hsz       Online status #36490   2006.11.13 08:23 GMT+1 óra  
Értem.
De elvileg az elgondolás jó ugye?
Pl csak a példa kedvéért meg lehetne azt csinálni h bemenő paraméterként megadom pl a színt+az átlátszóságot és csak egy pass-t használnék. Ebben a pass-ban menne 1 ciklus mondjuk 10-ig, és a shadereket a ciklus magban újra és újta fordítanám de más és más bemenő értékekkel.
Lehetséges lenne? Ez azér fontos nekem mert pár shadert szeretnék implementálni a progiba de az engine-be csak minimálisan akarnék belenyulni (mivel az nem az én dolgom), valamint a forráskód sincs meg+dx10 használata a cél amit iszonyú lassan emulálna a kártyám.

Lenne még 1 kérdésem: van rá másik mód h az effektfájlon keresztül érjem el a cuccokat. pl mátrixok meg ilyesmik. Asszem a glsl-ben voltak ilyen beépített fv-ek és nem a programon belül kellett gondoskodni rólla.

   
TPG - Tag | 3402 hsz       Online status #36484   2006.11.13 07:57 GMT+1 óra  
Van egy olyan halvány gyanúm hogy a DXSAS-hoz tartozó részeken állítottál el valamit. Innentől viszont nem tudok segíteni, én nem használok DXSAS-t (írtam helyette saját cumót).
Reality is almost always wrong. - House

   
g_imi - Tag | 236 hsz       Online status #36441   2006.11.13 03:26 GMT+1 óra  
Bocs h már megint én! A shaderek terén az elmélet megvan csak a gyakorlat hiányzik.
A effektfájlom tartalma ez:

#include <sas\sas.fxh>

int GlobalParameter : SasGlobal
<
int3 SasVersion = {1, 1, 0};

string SasEffectDescription = "HLSL Hands-On Workshop: Completed solution";
string SasEffectCompany = "Microsoft Corporation";
bool SasUiVisible = false;
>;


//-----------------------------------------------------------------------------------------
// Variables
//-----------------------------------------------------------------------------------------
float4x4 World
<
string SasBindAddress = "Sas.Skeleton.MeshToJointToWorld[0]";
bool SasUiVisible = false;
>;

float4x4 View
<
string SasBindAddress = "Sas.Camera.WorldToView";
bool SasUiVisible = false;
>;

float4x4 Projection
<
string SasBindAddress = "Sas.Camera.Projection";
bool SasUiVisible = false;
>;

float3 MaterialDiffuseColor
<
string SasUiControl = "ColorPicker";
> = { 1.0f, 0.0f, 0.0f };


struct VS_INPUT
{
float3 Position : POSITION;
};

struct VS_OUTPUT
{
float4 PositionProjected : POSITION;
};

VS_OUTPUT VS(VS_INPUT input)
{
VS_OUTPUT Out = (VS_OUTPUT)0;

// transform the position and normal
float3 worldPosition = mul(float4(input.Position, 1), World); // position (view space)

Out.PositionProjected = mul(float4(worldPosition, 1), mul( View, Projection) );

return Out;
}



float4 PS1(VS_OUTPUT input) : COLOR
{
return float4( 1,0,0, 1);

}

float4 PS2(VS_OUTPUT input) : COLOR
{
return float4( 0,0,1, 0);
}

technique RenderScene
{
pass P0
{
VertexShader = compile vs_2_0 VS();
PixelShader = compile ps_2_0 PS1();
}
pass P1
{
VertexShader = compile vs_2_0 VS();
PixelShader = compile ps_2_0 PS2();
AlphaBlendEnable = TRUE;
SrcBlend = ONE;
DestBlend = ONE;
}
}


A végeredmény pedig egy lila gömb annak ellenére hogy a 2. passban az alfa értéke 0. Tuti h én hagytam ki vlmt, de nem tudom h mit?
Az effect fájlt a dx9 sdk meshview-erével szoktam megnézni, mivel ez a leggyorsabb mód

   
g_imi - Tag | 236 hsz       Online status #36425   2006.11.13 00:49 GMT+1 óra  
Értem!
Köszönöm a segítséget. Így h létezik rá módszer neki is látok!!!

   
TPG - Tag | 3402 hsz       Online status #36393   2006.11.12 13:55 GMT+1 óra  
Idézet
g_imi :
Helló mindenkinek!
Nekem az lenne a kérdésem h pl olyan dolgoknál mint mondjuk a szőr amit több fázisban kellene létrehozni 1 passban csináljam meg?
Úgy értem h ha pl 60 layert használok akk ne kelljen 60 pass-ot készítenem, hanem pl 1 pass-ban 1 ciklussal letudnám az egészet.
Lehetséges ez? Vagy ciklusokat csak a progiban vagy a shaderben használhatok csak?
Azért lenne fontos mert az engne-t nem én írom és szeretném a shadereimet a dx sdk meshviewer-ével tesztelni.
Nagyon nagy butaság amit kérdezek?


SM2.0-tól az alap vezérlési szerkezetek (elágazás és a háromféle ciklus) használhatóak shaderekben is viszont meg van kötve hogy max hány utasításból állhat egy shader (PS2.0: 32texture+64arithmetic; PS3.0: 512; VS2.0: 256; VS3.0: 512) és a ciklusban lévő kódot annyiszor kell venni ahányszor az ismétlődni fog. Magyarul nagyon kevés kódnak kell lennie a ciklusban hogy 60-szor lefuthasson. Egyébként meg ha van egy passod amit 60-szor kell alkalmazni a meshen akkor elég a cuccot egyszer megírni és a mesht 60-szor lerenderelni vele mindig frissítve a bemenő adatokat.
Reality is almost always wrong. - House

   
g_imi - Tag | 236 hsz       Online status #36389   2006.11.12 13:46 GMT+1 óra  
Helló mindenkinek!
Nekem az lenne a kérdésem h pl olyan dolgoknál mint mondjuk a szőr amit több fázisban kellene létrehozni 1 passban csináljam meg?
Úgy értem h ha pl 60 layert használok akk ne kelljen 60 pass-ot készítenem, hanem pl 1 pass-ban 1 ciklussal letudnám az egészet.
Lehetséges ez? Vagy ciklusokat csak a progiban vagy a shaderben használhatok csak?
Azért lenne fontos mert az engne-t nem én írom és szeretném a shadereimet a dx sdk meshviewer-ével tesztelni.
Nagyon nagy butaság amit kérdezek?

   
Aravisz - Tag | 4 hsz       Online status #36354   2006.11.12 08:58 GMT+1 óra  
Sziasztok!
Eléggé új vagyok ebben a shaderprogramozásban, de a működésüket már értem stb, és most rátérek a lényegre.
A GPU GEMS 2-ben a Terrain Rendering Using GPU-Based Geometry Clipmaps nevű fejezeten leírtakat valaki megvalósította már itt? Vagy netán érezne késztetést enne kipróbálására? http://research.microsoft.com/~hoppe/#gpugcm - itt megtalálhatjátok a róla szóló cikkeket, és elég részletes dokumentációt hozzá.
A konkrét cél: szeretnék egy olyan terrain-t létrehozi ami LOD (Level of Detail) technikát alkalmaz shadereken keresztül.
Ami még érdekes lehet az a L3DT program, aminek a viewer-e realtime-ban generál terepet a heightmappekből, és szintén LOD technikát alkalmaz, a viewer forrása pedig nyílt hozzáférésű.
A shader írását HLSL-ben kellene megvalósítani, ehhez az FXComposer nyújt majd segítséget.
Ha valaki esetleg tud nekem segíteni bármiben is, vagy szeretne velem együttműködni, azt szívesen venném! Egyedül sajnos nagyon elesettnek érzem magam.
Bármilyen ötletet szívesen várok!
Üdv,
Aravisz

   
gymisi - Törzstag | 212 hsz       Online status #34996   2006.11.03 00:56 GMT+1 óra  
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...

   
Jedi - Tag | 175 hsz       Online status #34986   2006.11.02 15:35 GMT+1 óra  
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.

   
Kuz - Törzstag | 4455 hsz       Online status #34946   2006.11.02 12:18 GMT+1 óra  
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???

   
Kuz - Törzstag | 4455 hsz       Online status #34722   2006.11.01 09:52 GMT+1 óra  
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???

   
gymisi - Törzstag | 212 hsz       Online status #34719   2006.11.01 09:44 GMT+1 óra  
Nézd meg újra, hogy biztosan jó textúrát adsz-e át..

   
Kuz - Törzstag | 4455 hsz       Online status #34717   2006.11.01 09:32 GMT+1 óra  
"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???

   
Kuz - Törzstag | 4455 hsz       Online status #34716   2006.11.01 09:22 GMT+1 óra  
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???

   
gymisi - Törzstag | 212 hsz       Online status #34715   2006.11.01 09:12 GMT+1 óra  
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

   
gymisi - Törzstag | 212 hsz       Online status #34702   2006.11.01 05:57 GMT+1 óra  
Kuzanth! pm ment!

   
Kuz - Törzstag | 4455 hsz       Online status #34682   2006.11.01 04:26 GMT+1 óra  
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???

   
Kuz - Törzstag | 4455 hsz       Online status #34374   2006.10.30 11:55 GMT+1 óra  
Ú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???

   
TPG - Tag | 3402 hsz       Online status #34373   2006.10.30 11:53 GMT+1 óra  
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

   
Kuz - Törzstag | 4455 hsz       Online status #34371   2006.10.30 11:43 GMT+1 óra  
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???

   
TPG - Tag | 3402 hsz       Online status #34122   2006.10.28 15:30 GMT+1 óra  
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

   
TPG - Tag | 3402 hsz       Online status #34121   2006.10.28 15:19 GMT+1 óra  
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

   
Kuz - Törzstag | 4455 hsz       Online status #33977   2006.10.27 02:02 GMT+1 óra  
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???

   
Kuz - Törzstag | 4455 hsz       Online status #33781   2006.10.26 01:03 GMT+1 óra  
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???

   
TPG - Tag | 3402 hsz       Online status #32741   2006.10.18 08:49 GMT+1 óra  
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

   
Kuz - Törzstag | 4455 hsz       Online status #32731   2006.10.18 07:56 GMT+1 óra  
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???

   
TPG - Tag | 3402 hsz       Online status #32611   2006.10.17 08:04 GMT+1 óra  
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

   
syam - Törzstag | 1491 hsz       Online status #32572   2006.10.17 02:18 GMT+1 óra  
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
   
Kuz - Törzstag | 4455 hsz       Online status #32567   2006.10.17 01:19 GMT+1 óra  
"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???

   
syam - Törzstag | 1491 hsz       Online status #32565   2006.10.17 01:12 GMT+1 óra  
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
   
Kuz - Törzstag | 4455 hsz       Online status #32561   2006.10.17 00:38 GMT+1 óra  
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???

   
TPG - Tag | 3402 hsz       Online status #32475   2006.10.16 08:01 GMT+1 óra  
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

   
Kuz - Törzstag | 4455 hsz       Online status #32471   2006.10.16 06:45 GMT+1 óra  
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???

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #32469   2006.10.16 06:27 GMT+1 óra  
Értem én, csak ez így tetves lassú... egyrészt a másolás, másrészt az AA miatt... Megér ennyit az AA?
Dare to imagine!
http://www.insaneidea.hu
   
TPG - Tag | 3402 hsz       Online status #32467   2006.10.16 05:46 GMT+1 óra  
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

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #32466   2006.10.16 05:41 GMT+1 óra  
Na ennyire nem vagyok azert benne az MDX-ben A StretchRectangle() mit csinal pontosan?
Dare to imagine!
http://www.insaneidea.hu
   
Kuz - Törzstag | 4455 hsz       Online status #32465   2006.10.16 05:34 GMT+1 óra  
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???

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #32464   2006.10.16 05:08 GMT+1 óra  
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...)
Dare to imagine!
http://www.insaneidea.hu
   
Kuz - Törzstag | 4455 hsz       Online status #32461   2006.10.16 05:04 GMT+1 óra  
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???

   
TPG - Tag | 3402 hsz       Online status #32459   2006.10.16 04:50 GMT+1 óra  
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

   
Kuz - Törzstag | 4455 hsz       Online status #32458   2006.10.16 04:41 GMT+1 óra  
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???

   
TPG - Tag | 3402 hsz       Online status #32457   2006.10.16 04:39 GMT+1 óra  
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

   
Kuz - Törzstag | 4455 hsz       Online status #32456   2006.10.16 04:39 GMT+1 óra  
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???

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #32451   2006.10.16 04:29 GMT+1 óra  
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...
Dare to imagine!
http://www.insaneidea.hu
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] > 19 < [20] [22]