[Direct3D/C#] Gamedesign problemen

[roy-t]

flippen de textures?

Of bedoel je nogsteeds qua performance? (na je jaa gevonden dacht ik dat het helemaal opgelost was)

noob-input: gebruik je 7x een uitgerekte texture of komt de texture telkens terug, dit scheelt misschien/ wordt door de videokaart misschien anders gezien.

(ik begeef me nu op glad, onbekend, ijs, maar soms geeft een noob mij een 'tipje' en zie ik het ineens, dus wie weet, ik post gewoon maar wat )

[Mischa_NL]

therat10430 schreef op vrijdag 13 juli 2007 @ 00:22:
flippen de textures?

Of bedoel je nogsteeds qua performance? (na je jaa gevonden dacht ik dat het helemaal opgelost was)

noob-input: gebruik je 7x een uitgerekte texture of komt de texture telkens terug, dit scheelt misschien/ wordt door de videokaart misschien anders gezien.

(ik begeef me nu op glad, onbekend, ijs, maar soms geeft een noob mij een 'tipje' en zie ik het ineens, dus wie weet, ik post gewoon maar wat )

textures hebben wel tiling en die hielp ook wel kwa performance nadat ik die minder zette.
lijkt het er dan op dat ik nú al op de limit van texture fillling zit op mijn video kaart?
zo ja wtf zijn die dingen kut ?

[roy-t]

Mischa_NL schreef op vrijdag 13 juli 2007 @ 02:05:
[...]
textures hebben wel tiling en die hielp ook wel kwa performance nadat ik die minder zette.
lijkt het er dan op dat ik nú al op de limit van texture fillling zit op mijn video kaart?
zo ja wtf zijn die dingen kut ?

wat is je videokaart? En je zei toch dat de textures kleiner maken niet hielp? dan lijkt het me niet dat de textfilling vol zit.

(nogmaals: ik post weer op goed geluk )

[Mischa_NL]

therat10430 schreef op vrijdag 13 juli 2007 @ 10:29:
[...]


wat is je videokaart? En je zei toch dat de textures kleiner maken niet hielp? dan lijkt het me niet dat de textfilling vol zit.

(nogmaals: ik post weer op goed geluk )

Het tekenen van mips hielp niet, het écht sturen van kleinere textures en het minder tilen ervan hielp wel.
echter leek het weinig te helpen omdat mijn RAM volzat en dus daar ineens een bottleneck zat!

[Mischa_NL]

Kick!

Ik zit nu met een probleempje in mijn shaders.
Ik ben bezig met shadow mapping en een aantal filters (gaussian blur) voor het soft shadowing.

Nu wil ik die gaussian blur uiteraard op de GPU doen. En daar gaat het mis! Ik heb een ShadowMap met PCF (Percentage Closer Filtering) welke ik vervolgens wil blurren om 'pixels' te voorkomen!

De aanpak:
Ik stuur mijn texture met PCF naar de gpu dmv een variable. Ik render (drawprims) een quad van 2 triangles met position (screen size) en texcoords. Deze stuur ik zonder een transform door naar de PixelShader omdat ik (volgens mij) met transformed vertices te doen heb welke ik niet meer om hoef te zetten.
In de Pixelshader doe ik een lookup van de texture en output dezelfde pixel.
Wat dus de gewenste uitkomst zou zijn is: een identieke plaat als degene die ik erin heb gestopt. Wat ik echter krijg is een compleet zwarte texture!

Ikzelf denk dat de fout ergens zit met coordinaten die niet goed zitten. Ik heb gedebugged maar minimalistischer dan dit kan ik het niet maken.

Shadercode

code:

Texture xShadowMap;
sampler xShadowSampler = sampler_state { texture = <xShadowMap>; magfilter = LINEAR; minfilter = LINEAR; mipfilter=LINEAR; AddressU = Clamp; AddressV = Clamp;};

VSOUTPUT_BLUR BlurScene_VS( InputVs In )
{
    VSOUTPUT_BLUR OUT = (VSOUTPUT_BLUR)0;

    OUT.vPosition = In.Pos;
    OUT.vTexCoord = In.TexCoords;

    return OUT;
}

float4 BlurSceneH_PS( VSOUTPUT_BLUR IN ): COLOR0
{
    return tex2D( xShadowSampler, IN.vTexCoord );
}

technique BlurScene
{
    pass Pass0
    {        
        VertexShader = compile vs_3_0 BlurScene_VS();
        PixelShader = compile ps_3_0 BlurSceneH_PS();
    }
}

Vervolgens mijn draw routine:

C#:

ShadowMapFixedPoint = [mijn shadowmap welke ik gedebugged heb en dus CORRECT is!!]
RtsHelper3 = new RenderToSurface(world.device, world.Width, world.Height, Format.X8R8G8B8, true, DepthFormat.D16);
ShadowMapBlurred = new Texture(world.device, world.Width, world.Height, 1, Usage.RenderTarget, Format.X8R8G8B8, Pool.Default);
RenderSurface3 = ShadowMapBlurred.GetSurfaceLevel(0);

quad.Create(world.device,0,0,world.Width,world.Height);

RtsHelper3.BeginScene(RenderSurface3);
world.device.Clear(ClearFlags.Target | ClearFlags.ZBuffer, Color.Black, 1.0f, 0);

mesh.shader.SetTechnique("BlurScene");
mesh.shader.AddEffectValue("xShadowMap", ShadowMapFixedPoint);

quad.Draw(world.device, mesh);
            
RtsHelper3.EndScene(Filter.None);

en ten slotte de quad class

C#:

    class Quad
    {
        private VertexBuffer vb;    
        
        public void Create(Device device, int posX, int posY, int sizeX, int sizeY)
        {
            EngineVertexFormat[] quad = new EngineVertexFormat[6];
            
            quad[2] = new EngineVertexFormat(posX,posY,0,0);
            quad[1] = new EngineVertexFormat(posX+sizeX,posY,1,0);
            quad[0] = new EngineVertexFormat(posX+sizeX,posY+sizeY,1,1);

            quad[3] = new EngineVertexFormat(posX,posY+sizeY,0,1);
            quad[4] = new EngineVertexFormat(posX+sizeX,posY+sizeY,1,1);
            quad[5] = new EngineVertexFormat(posX,posY,0,0);

            vb = new VertexBuffer( typeof(EngineVertexFormat), 6, device, Usage.WriteOnly, EngineVertexFormat.Format, Pool.Default);
            vb.SetData(quad, 0, LockFlags.NoOverwrite);
        }

        public void Draw(Device device,CustomMesh mesh)
        {       
            VertexElement[] velements = new VertexElement[]
            {
                new VertexElement(0, 0, DeclarationType.Float3, DeclarationMethod.Default, DeclarationUsage.Position, 0),
                new VertexElement(0, 12, DeclarationType.Float2, DeclarationMethod.Default, DeclarationUsage.TextureCoordinate, 0),
                VertexElement.VertexDeclarationEnd
            };
            
            device.SetStreamSource ( 0, vb, 0 );
            device.VertexDeclaration = new VertexDeclaration(device, velements);

            int numpasses = mesh.shader.Begin();

            for (int j = 0; j < numpasses; j++)
            {
                mesh.shader.BeginPass(j);
                device.DrawPrimitives(PrimitiveType.TriangleList, 0, 6);
                mesh.shader.EndPass();
            }
            
            mesh.shader.End();
            
        }
    }

    public struct EngineVertexFormat
    {
        public Vector3 Pos;
        public Vector2 TexCoord;
        
        public static readonly VertexFormats Format = VertexFormats.Position | VertexFormats.Texture0;
        
        public EngineVertexFormat(int PosX, int PosY, int u, int v)
        {
            Pos.X = PosX;
            Pos.Y = PosY;
            Pos.Z = 0;
            TexCoord.X = u;
            TexCoord.Y = v;
        }

    }

Ik snap dat dit veel code is, en misschien niet helemaal duidelijk. Jammer genoeg kom ik er zelf niet uit, anders zou ik jullie er niet mee lastig vallen!

[.oisyn]

Wat is die shadowmap, een depthbuffer middels nVidia's hardware shadowmap feature? Daar kun je namelijk niet zomaar pixels van lezen - je stopt er een x,y,z in, waarbij hij vervolgens de depth waarde op (x, y) vergelijkt met je gegeven z, en een 0 of 1 teruggeeft (of ergens daartussenin in het geval van "bilinear filtering", waarbij hij 4 van dat soort samples doet), afhankelijk van of de pixel in de schaduw zit of niet.

Waarom is die texture trouwens zwart, heeft ie wel wat gerenderd of is dat gewoon de initiele waarde? Clear 'm anders eens met een bepaalde kleur, dan weet je iig of het zwarte pixels zijn (fout in pixelshader), of dat er überhaupt niets gerenderd is (fout in vertices/vertex shader)

[Mischa_NL]

.oisyn schreef op maandag 16 juli 2007 @ 23:27:
Wat is die shadowmap, een depthbuffer middels nVidia's hardware shadowmap feature? Daar kun je namelijk niet zomaar pixels van lezen - je stopt er een x,y,z in, waarbij hij vervolgens de depth waarde op (x, y) vergelijkt met je gegeven z, en een 0 of 1 teruggeeft (of ergens daartussenin in het geval van "bilinear filtering", waarbij hij 4 van dat soort samples doet), afhankelijk van of de pixel in de schaduw zit of niet.

Waarom is die texture trouwens zwart, heeft ie wel wat gerenderd of is dat gewoon de initiele waarde? Clear 'm anders eens met een bepaalde kleur, dan weet je iig of het zwarte pixels zijn (fout in pixelshader), of dat er überhaupt niets gerenderd is (fout in vertices/vertex shader)

Ik denk dat ik het gevonden heb. Ik heb inmiddels 'waarden' op mijn scherm maar deze kloppen niet omdat het world coords zijn, maar dit moeten screen/pixel coords zijn.
Maar ik ben er nu zo gefrustreerd over, zit er al anderhalve dag mee namelijk. Stop nu, morgne nog eens naar kijken.

edit/
Die shadowmap is gemaakt door het depthbuffer uit te lezen en vervolgens om te zetten naar een shadowmap (wit zwart).

[ Voor 5% gewijzigd door Mischa_NL op 17-07-2007 00:32 ]

[Odin]

Ik ben ongeveer met hetzelfde bezig als Mischa_NL, ik hoop dan ook dat het goed is dat ik mijn vraag in zijn topic neerzet.
Ik ben bezig met een camera functie die de camera aanstuurt zoals in first person shooters. Alleen krijg ik vrij vreemd gedrag dat ik niet kan bevatten. wat ik doe is het manipuleren van de View-matrix aan de hand van de muis en keyboard input:

C++:

/* The Camera function handles the view matrix */
void cApplication::Camera()
{

    //ToDo: Add Settings for Invert mouse, sensitivity

    LPDIRECT3DDEVICE9 pDevice = Graphics()->GetDevice();

    static float XMouseMovement = 0.0f;
    static float YMouseMovement = 0.0f;

    static float XMovement = 0.0f;
    static float ZMovement = 0.0f;

    if ( pDevice ) {
        D3DXMATRIX matView;    // the view transform matrix

        /* Retrieve mouse state */
        DIMOUSESTATE MouseState = Input()->GetMouseState();
        
        if ( Input()->KeyPressed(DIK_W) ){
            ZMovement += 0.02f;
        }
        
        if ( Input()->KeyPressed(DIK_S) ){
            ZMovement -= 0.02f;
        }

        if ( Input()->KeyPressed(DIK_A) ){
            XMovement += 0.02f;
        }

        if ( Input()->KeyPressed(DIK_D) ){
            XMovement -= 0.02f;
        }

        XMouseMovement += 0.2f*(float)MouseState.lX;
        YMouseMovement += -0.2f*(float)MouseState.lY;   // + or - dependant on inverse mouse
        
        
        D3DXMatrixLookAtLH(&matView,
                        &D3DXVECTOR3 (XMovement, 6.0f, ZMovement),   // the camera position
                        &D3DXVECTOR3 (XMouseMovement, YMouseMovement, 0.0f),    // the look-at position
                        &D3DXVECTOR3 (0.0f, 1.0f, 0.0f));   // the up direction

        pDevice->SetTransform(D3DTS_VIEW, &matView);    // set the view transform to matView
    }
}

Ik denk dat ik wiskundig iets over het hoofd zie, en google helpt me weinig met dit probleem.

[Creepy]

Misschien handig dat je even aangeeft wat het vreemde gedrag nu precies is en uiteraard wat je zelf hebt geprobeerd om het op te lossen. Je dump nu een vraag + wat code en wij mogen voor je gaan debuggen, dat is natuurlijk niet de bedoeling. Debuggen moet je in eerste instantie zelf doen en dat lijkt je nu niet gedaan te hebben. Zie ook Programming Beleid - De Quickstart

[ Voor 75% gewijzigd door Creepy op 18-07-2007 13:02 ]

[Woy]

Odin schreef op woensdag 18 juli 2007 @ 12:54:
Alleen krijg ik vrij vreemd gedrag dat ik niet kan bevatten.

En wat is dat vreemde gedrag?

[Mischa_NL]

Kun je wel 'lopen' als je de mousemovement niet gebruikt?
Positie van de muis is zoals je weet relatief en niet absoluut.
Verder lijkt het erop dat je iedere keer je variabelen reset als je de camera functie aanroept? In dat geval moet je wel je oude positie opvragen en erbij stoppen.

[Creepy]

Mischa_NL schreef op woensdag 18 juli 2007 @ 13:03:
Verder lijkt het erop dat je iedere keer je variabelen reset als je de camera functie aanroept? In dat geval moet je wel je oude positie opvragen en erbij stoppen.

De positie is static, dus die wordt niet gereset.

[Odin]

Creepy schreef op woensdag 18 juli 2007 @ 13:00:
Misschien handig dat je even aangeeft wat het vreemde gedrag nu precies is en uiteraard wat je zelf hebt geprobeerd om het op te lossen. Je dump nu een vraag + wat code en wij mogen voor je gaan debuggen, dat is natuurlijk niet de bedoeling. Debuggen moet je in eerste instantie zelf doen en dat lijkt je nu niet gedaan te hebben. Zie ook Programming Beleid - De Quickstart

Ja sorry daarvoor,

als je met de w en s keys naar voren en naar achter loopt 'duikt' de camera naar beneden bij wat ik denk de 0 positie op de Z as van direct x, hierna is ook de horizontale besturing van de muis omgekeerd. strafen is ook vreemd, de camera draait een beetje om het model heen, en blijft ook op de x as. het is moeilijk uit te leggen.
Ik heb dus op google gezocht naar tutorial/beschrijvingen, hoe je de view-matrix dus goed aanpast, maar niets bruikbaars gevonden.

edit: het is niet dat er gedebugged moet worden, het is alleen dat ik niet begrijp hoe je de view matrix goed aanstuurd.

[ Voor 5% gewijzigd door Odin op 18-07-2007 13:20 ]

[.oisyn]

Het gebruik van de LookAt functie voor wat jij wilt bereiken is ook erg onhandig. LookAt() is handig als je naar een bepaald punt wilt kijken, gegeven een ander punt. Wat jij wilt, is gewoon een matrix bouwen gegeven je huidige positie en een kijkrichting. In principe controleer je die richting door je muispositie te interpreteren als euler angles - een rotatie over de X-as voor op-neer (dus Y-as van de muis), gevolgd door een rotatie over de Y-as voor links-rechts (X-as van de muis). De D3DXMatrixRotationYawPitchRoll(() functie is hier goed voor bruikbaar (yaw is links-rechts, pitch is op-neer. Roll kun je 0 houden). Hou dus absolute yaw- en pitch-waardes bij, die je aanpast adhv je muisbeweging.

Om de richting te bepalen van je beweging middels W,S,A,D, moet je naar de assen kijken in de matrix die je net gebouwd hebt. Voor strafen is de x-as belangrijk, oftewel de 3d vector in de eerste rij van je matrix. Voor vooruit/achteruit is de z-as van toepassing, dus de 3d vector in de derde rij van je matrix. Gebruik die assen om je positie te updaten (wil je vooruit bewegen, tel dan zAs * snelheid bij je positie op)

[Mischa_NL]

yes eindelijk gevonden wat er fout was...

C#:

            VertexElement[] velements = new VertexElement[]
            {
                new VertexElement(0, 0, DeclarationType.Float3, DeclarationMethod.Default, DeclarationUsage.Position, 0),
                new VertexElement(0, 12, DeclarationType.Float2, DeclarationMethod.Default, DeclarationUsage.TextureCoordinate, 0),
                VertexElement.VertexDeclarationEnd
            };

moest zijn:

code:

            VertexElement[] velements = new VertexElement[]
            {
                new VertexElement(0, 0, DeclarationType.Float4, DeclarationMethod.Default, DeclarationUsage.Position, 0),
                new VertexElement(0, 12, DeclarationType.Float2, DeclarationMethod.Default, DeclarationUsage.TextureCoordinate, 0),
                VertexElement.VertexDeclarationEnd
            };

Had position als float3.

[.oisyn]

Euh, dan moet je je texcoords ook 4 bytes opschuiven in de stream. Die 12 moet dan dus 16 worden op regel 4

[Verwijderd]

Zou je nog eens een screenshot willen posten van wat je nu hebt? Het is leuk dit topic te volgen, zo zie je maar dat zelfs als je er relatief veel tijd in stopt deze zaken erg lastig zijn om te leren.

[Odin]

.oisyn schreef op woensdag 18 juli 2007 @ 13:42:
Het gebruik van de LookAt functie voor wat jij wilt bereiken is ook erg onhandig. LookAt() is handig als je naar een bepaald punt wilt kijken, gegeven een ander punt. Wat jij wilt, is gewoon een matrix bouwen gegeven je huidige positie en een kijkrichting. In principe controleer je die richting door je muispositie te interpreteren als euler angles - een rotatie over de X-as voor op-neer (dus Y-as van de muis), gevolgd door een rotatie over de Y-as voor links-rechts (X-as van de muis). De D3DXMatrixRotationYawPitchRoll(() functie is hier goed voor bruikbaar (yaw is links-rechts, pitch is op-neer. Roll kun je 0 houden). Hou dus absolute yaw- en pitch-waardes bij, die je aanpast adhv je muisbeweging.

Om de richting te bepalen van je beweging middels W,S,A,D, moet je naar de assen kijken in de matrix die je net gebouwd hebt. Voor strafen is de x-as belangrijk, oftewel de 3d vector in de eerste rij van je matrix. Voor vooruit/achteruit is de z-as van toepassing, dus de 3d vector in de derde rij van je matrix. Gebruik die assen om je positie te updaten (wil je vooruit bewegen, tel dan zAs * snelheid bij je positie op)

ik wist wel dat er iets wiskundigs niet helemaal klopte . ontzettend bedankt voor je reactie.

[Mischa_NL]

.oisyn schreef op woensdag 18 juli 2007 @ 16:23:
Euh, dan moet je je texcoords ook 4 bytes opschuiven in de stream. Die 12 moet dan dus 16 worden op regel 4

Hahahahahaha waarom kijk ik hier nu pas. Logisch inderdaad. Had een rare fout die nu weg is.

Verwijderd schreef op woensdag 18 juli 2007 @ 16:26:
Zou je nog eens een screenshot willen posten van wat je nu hebt? Het is leuk dit topic te volgen, zo zie je maar dat zelfs als je er relatief veel tijd in stopt deze zaken erg lastig zijn om te leren.

Ik zal vannacht of morgen mijn nieuwe lichtmodel afhebben en dan post ik screens.
Ik zal dan ook de textures ff flink oppompen om het wat mooier te maken. Niet dat ik dan nog boven de 20fps uitkom, maar dat doet er dan even niet toe!

Even mijn (nog met 1 bugje) shadowmap full screen gezet:
http://img169.imagevenue....8506_tadaaa_122_106lo.jpg

[ Voor 7% gewijzigd door Mischa_NL op 18-07-2007 19:11 ]

[.oisyn]

Plaatje doet 't niet?

[Mischa_NL]

Klote imagevenue. Hier het plaatje met gelijk de 'fout'.
Kan weer maar niet ontdekken waar het fout gaat.

Het lijkt erop dat er ergens iets fout gaat met de depth aangezien de schaduwen wel zonder strepen gecast worden...

http://img461.imageshack.us/img461/5615/wtflo1.jpg

[ Voor 6% gewijzigd door Mischa_NL op 19-07-2007 00:02 ]

[Odin]

Ik ben weer een stuk verder met mijn Camera functie, strafen werkt goed, ik bereken telkens opnieuw de asses zodat er in de goede righting wordt gelopen.

De muisbesturing wil nog niet echt lekker, D3DXMatrixRotationYawPitchRoll() kan ik niet goed gebruiken omdat ik nu meerder matrices heb. Daarom gebruik ik D3DXMatrixRotationX() (en Y) om de rotaties van elke matrix aan te sturen. echter als ik naar het model in mijn wereld toe loop en dan met de muis naar het model draai wordt het model uitgestrekt. Ik heb geen flauw idee hoe dat kan en het is al lastig om goed te begrijpen hoe ik die view matrix goed manipuleer. Diverse tutorials helpen me ook niet verder, die zijn kort on gebruiken vaak alleen de LookAtLH() functie.

Hier mijn code tot nu toe:

C++:

void cApplication::Camera()
{

    //ToDo: Add Settings for Invert mouse, sensitivity

    LPDIRECT3DDEVICE9 pDevice = Graphics()->GetDevice();

    D3DXMATRIX ViewMatrix = Player()->GetViewMatrix();

    D3DXMATRIX PosMatrix;
    D3DXMATRIX RightMatrix;
    D3DXMATRIX UpMatrix;
    D3DXMATRIX LookMatrix;

    D3DXMatrixIdentity(&PosMatrix);
    D3DXMatrixIdentity(&RightMatrix);
    D3DXMatrixIdentity(&UpMatrix);
    D3DXMatrixIdentity(&LookMatrix);

    static D3DXVECTOR3 Position = D3DXVECTOR3(0,0,0);
    
    RightMatrix._11 = ViewMatrix._11;
    RightMatrix._12 = ViewMatrix._12;
    RightMatrix._13 = ViewMatrix._13;

    UpMatrix._21 = ViewMatrix._21;
    UpMatrix._22 = ViewMatrix._22;
    UpMatrix._23 = ViewMatrix._23;

    LookMatrix._31 = ViewMatrix._31;
    LookMatrix._32 = ViewMatrix._32;
    LookMatrix._33 = ViewMatrix._33;

    // Calculate Right,Look and up coordinates based on current position.
    D3DXVECTOR3 right =     D3DXVECTOR3((RightMatrix._11)+1.0f, RightMatrix._12, RightMatrix._13);
    D3DXVECTOR3 up =        D3DXVECTOR3(UpMatrix._21, (UpMatrix._22) + 1.0f, UpMatrix._23);
    D3DXVECTOR3 look =      D3DXVECTOR3(LookMatrix._31, LookMatrix._32, (LookMatrix._33) + 1.0f);


    static float XMouseMovement = 0.0f;
    static float YMouseMovement = 0.0f;


    if ( pDevice ) {

        /* Retrieve mouse state */
        DIMOUSESTATE MouseState = Input()->GetMouseState();
        
        if ( Input()->KeyPressed(DIK_W) ){
            Position -= 0.005f*look;
        }
        
        if ( Input()->KeyPressed(DIK_S) ){
            Position += 0.005f*look;
        }

        if ( Input()->KeyPressed(DIK_A) ){
            Position += 0.005f*right;
        }

        if ( Input()->KeyPressed(DIK_D) ){
            Position -= 0.005f*right;
        }

        // Update Position Matrix
        PosMatrix._43 = Position.z;
        PosMatrix._41 = Position.x;
        
        XMouseMovement = -0.005f*(float)MouseState.lX;
        YMouseMovement = -0.005f*(float)MouseState.lY;

        D3DXMatrixRotationY(&UpMatrix, XMouseMovement);
        D3DXMatrixRotationX(&RightMatrix, YMouseMovement);

        //D3DXMatrixRotationYawPitchRoll(&RightMatrix, XMouseMovement, YMouseMovement, 0);                      
        ViewMatrix = PosMatrix * RightMatrix * UpMatrix * LookMatrix;

        pDevice->SetTransform(D3DTS_VIEW, &ViewMatrix);    // set the view transform to matView

        Player()->UpdateViewMatrix(ViewMatrix);
    }
}

[.oisyn]

Waarom betrek je lookmatrix in de berekening van je viewmatrix? En waarom maak je uberhaupt eerst die Up-, Right- en LookMatrix? Up en Right ga je later overschrijven, en LookMatrix bevat zo in principe alleen maar bogus. Ik zie ook niet echt waarom je verschillende matrices zou willen eigenlijk... In principe zou de YawPitchRoll functie gewoon kunnen werken als je die gewoon met de PosMatrix vermenigvuldigt.

[ Voor 30% gewijzigd door .oisyn op 20-07-2007 16:29 ]

[Odin]

Dus jij zegt dat het volgende zou moeten werken:

C++:

    D3DXMATRIX ViewMatrix = Player()->GetViewMatrix();

    D3DXMATRIX PosMatrix;

    D3DXMatrixIdentity(&PosMatrix);

    static D3DXVECTOR3 Position = D3DXVECTOR3(0,0,0);
    static float XMouseMovement = 0.0f;
    static float YMouseMovement = 0.0f;

    // Calculate Right,Look and up coordinates based on current position, and processing the rotation of the mouse.
    D3DXVECTOR3 right =     D3DXVECTOR3((ViewMatrix._11 * cos(XMouseMovement)), ViewMatrix._12, ViewMatrix._13);
    D3DXVECTOR3 up =        D3DXVECTOR3(ViewMatrix._21, (ViewMatrix._22) + 1.0f, ViewMatrix._23);
    D3DXVECTOR3 look =      D3DXVECTOR3(ViewMatrix._31, ViewMatrix._32, ViewMatrix._33 * cos(XMouseMovement));

    if ( pDevice ) {

        /* Retrieve mouse state */
        DIMOUSESTATE MouseState = Input()->GetMouseState();
        
        if ( Input()->KeyPressed(DIK_W) ){
            Position -= 0.005f*look;
        }
        
        if ( Input()->KeyPressed(DIK_S) ){
            Position += 0.005f*look;
        }

        if ( Input()->KeyPressed(DIK_A) ){
            Position += 0.005f*right;
        }

        if ( Input()->KeyPressed(DIK_D) ){
            Position -= 0.005f*right;
        }

        // Update Position Matrix
        PosMatrix._43 = Position.z;
        PosMatrix._41 = Position.x;
        
        XMouseMovement += -0.005f*(float)MouseState.lX;
        YMouseMovement += -0.005f*(float)MouseState.lY;

        D3DXMatrixRotationYawPitchRoll(&ViewMatrix, XMouseMovement, YMouseMovement, 0);                     

        ViewMatrix = PosMatrix * ViewMatrix;

        pDevice->SetTransform(D3DTS_VIEW, &ViewMatrix);    // set the view transform to matView

        Player()->UpdateViewMatrix(ViewMatrix);
    }
}

Dit werkt nog niet helemaal, omdat wanneer de camera draait worden de directionele assen(right, look, up) niet goed berekend met die rotatie erin. waardoor bij het runnen het strafen perfect werkt totdat je de muis(yaw en pitch) erbij gaat betrekken.

Op een wiskunde manier moet dat dus bij het strafe mechanisme worden berekend, helaas is dit niet duidelijk te vinden in tutorial over camera's, die overigens 9 van de 10 keer niet de YawPitchRoll functie gebruiken.

[.oisyn]

Dat komt omdat je de vermenigvuldiging verkeerd om hebt staan . Je moet eerst de rotatie doen, en daarna pas de trasnlatie. ViewMatrix * PosMatrix dus.

.edit: nee, wacht, ik maakte een denkfout. Bovenstaande is idd een fout, maar niet de fout. De viewmatrix is de matrix van worldspace naar cameraspace, maar je wilt juist de matrix van de camera in worldspace, de inverse dus. Gelukkig is de inverse van een rotatie-matrix simpelweg de transpose van die matrix, dus ipv de rijen uit de matrix te halen, moet je de kolommen gebruiken.

[ Voor 56% gewijzigd door .oisyn op 23-07-2007 13:48 ]

[Odin]

zo dus:

C++:

    D3DXVECTOR3 right = D3DXVECTOR3(ViewMatrix._11, ViewMatrix._21, ViewMatrix._31);
    D3DXVECTOR3 up = D3DXVECTOR3(ViewMatrix._12, ViewMatrix._22, ViewMatrix._32);
    D3DXVECTOR3 look = D3DXVECTOR3(ViewMatrix._13, ViewMatrix._23, ViewMatrix._33);

Nu nu draait de camera rond 0,0,0 , positie veranderd nu ook wanneer je rotate met de muis.

edit:
vermenigvuldiging is ook omgedraaid: ViewMatrix = ViewMatrix * PosMatrix;

De YawPitchRoll functie gaat dus uit van rotatie om de assen bij 0,0,0 terwijl de hij dus uit moet gaan van de huidige positie. Ergens moet ik dat dus bij gaan houden, waar en hoe daar kom ik niet uit.

[ Voor 28% gewijzigd door Odin op 23-07-2007 15:42 ]

[.oisyn]

En heb je die vermenigvuldiging ook omgedraaid?

.edit: hmz, ik ben niet zo erg bekend met de D3DX library, maar die YawPitchRoll functie maakt waarschijnlijk geen viewmatrix, terwijl de LookAt functie dat typisch wel doet. Je moet de inverse dus hebben.

Ok, dan pakken we het anders aan. Ik heb nu even niet de MSDN tot mijn beschikking, maar ik neem aan dat d3dx wel gewoon een functie heeft om de (orthonormale) inverse van een matrix uit te rekenen? Doe dan zoiets:

C++:

YawPitchRoll(&RotMatrix, yaw, pitch, 0);
CameraMatrix = RotMatrix * PosMatrix;
ViewMatrix = Inverse(CameraMatrix);

Waarschijnlijk moet je nu wel even wat plusjes en minnetjes omdraaien in de code die de yaw, pitch en de positie berekent, maar dat merk je vanzelf

[ Voor 96% gewijzigd door .oisyn op 23-07-2007 16:03 ]

[Odin]

Geweldig, zoals je zegt werkt het goed, voor de volledigheid zet ik de werkende code neer

C++:

XMouseMovement += 0.005f*(float)MouseState.lX;
        YMouseMovement += 0.005f*(float)MouseState.lY;

        D3DXMatrixRotationYawPitchRoll(&RotMatrix, XMouseMovement, YMouseMovement, 0);                      

        ViewMatrix = RotMatrix * PosMatrix;
        D3DXMatrixInverse(&ViewMatrix, NULL, &ViewMatrix);

        pDevice->SetTransform(D3DTS_VIEW, &ViewMatrix);    // set the view transform to matView

[Mischa_NL]

Man Man Man! Wat een ingewikkelde materie die schaduws. Een app maken die gewoon rendert volgens 'natuurkundige wetten' is veel makkelijker volgens mij. Wat een stomme truukjes moet je allemaal gebruiken om schaduws in real time werkend te krijgen.
Ik krijg foute selfshadowing op mijn oppervlaktes die verder weg van de lichtbron steeds groter worden. Het lijken me precisie-afwijkingen.

[.oisyn]

Klopt, shadows zijn vrij gecompliceerd om het goed te krijgen. Maar troost je, het lukt bijna niemand . Zelfs in AAA titels zoals Gears of War zie je surface acne (foute selfshadowing door precisie-issues) en andere artifacts. Vooral voor belichting van grote gebieden door een zon-achtige lightsource die vrij laag staan (zoals 's ochtends en 's avonds) is beschikbare precisie een ramp.

Naast het gebruik van een andere depthbuffer (floating point icm inverse z werkt het beste) moet je denken aan shadow focussing op het zichtbare gebied, parallel-split shadowmaps (renderen naar verschillende shadowmaps, afhankelijk van de z-waarde van de te renderen pixels) en andere smerige trucjes om de precisie beter te distribueren. Maar wat je ook doet, artifacts zul je altijd blijven behouden.

[Sponge]

Klopt, schaduwen hebben enorm veel tijd gekost bij mijn project. En daarna moet je ook nog zorgen dat de resolutie van de shadowmap degelijk blijft - ver vanaf het licht punt, zoals .oisyn zegt. Het is dan ook een populair onderwerp op GD.net volgens mij

[Mischa_NL]

Kick!

Zo... Tijd dat er weer eens gewerkt wordt aan mijn Terrain renderer.
Heb simpele bumpmapping nu, en ben vandaag begonnen aan water.

Hoewel ik met het water zomaar wat aan het rotzooien geweest ben ziet het er niet eens vreselijk uit, nagaande dat het 2 triangels zijn met daarbovenop 1 texture...

Hier een screen:


Schaduwen heb ik gedropped zolang, dat komt weer wel een keer!

[roy-t]

Ziet er inderdaad prima uit, alleen wel erg lage fps voor dat kleine stukje.. of is dat in debug mode? (of op vage hardware )

[.oisyn]

Wat met water altijd een mooi effect geeft is als je wat (mid-frequency) noise maps in verschillende richtingen en snelheden over elkaar heen laat scrollen en een heightmap rendert van het gemiddelde van die waarden, waar je vervolgens de normalen uit berekent waarmee je je env mapping en specular highlights van de zon doet. Dan krijg je van die mooie schitteringen en lijkt het allemaal een stuk minder statisch

[ Voor 8% gewijzigd door .oisyn op 21-02-2008 00:26 ]

[Mischa_NL]

roy-t schreef op donderdag 21 februari 2008 @ 00:01:
Ziet er inderdaad prima uit, alleen wel erg lage fps voor dat kleine stukje.. of is dat in debug mode? (of op vage hardware )

Lage Fps komt door een aantal factoren.
Belangrijkste is dat ik nogal een shitload aan textures naar de gpu stuur, en deze getiled draw, zonder LOD of iets dergelijks. Hierdoor is er gewoon te weinig bandwith of hoe dat ook mag heten (op mijn 7600GT in ieder geval!)
Aantal primitives kan het probleem niet zijn, ik draw namelijk een grid van 256*256, niet gigantisch groot dus.

.oisyn schreef op donderdag 21 februari 2008 @ 00:23:
Wat met water altijd een mooi effect geeft is als je wat (mid-frequency) noise maps in verschillende richtingen en snelheden over elkaar heen laat scrollen en een heightmap rendert van het gemiddelde van die waarden, waar je vervolgens de normalen uit berekent waarmee je je env mapping en specular highlights van de zon doet. Dan krijg je van die mooie schitteringen en lijkt het allemaal een stuk minder statisch

Dat heb ik inderdaad ook als optie gelezen. Waar ik echter tussen twijfel is of ik het wate rga renderen op 2 triangles en dmv bumpmapping de illusie van golven wek, of daadwerkelijk gebruik maak van een heightmap en deze daadwerkelijk dmv een hoop triangles (en dan zéker een lod algoritme) omzet naar een mesh...
Lastige keuze. Beide hebben voor en nadelen denk ik.

Bumpmapping techniek is namelijk níet gpu intensief aangezien ik maar 2 triangles (een quad) render. Nadeel is echter dat met een hoek vlak op het water je bumpmapping vrijwel helemaal verloren gaat.

Een mesh is uiteraard gpu intensief omdat er een hoop extra primitives gerenderd moeten worden. Ook is het cpu intensief omdat ik een algoritme zal moeten schrijven om golven te creeeren. En daar komt het lullige. Die golven moeten iedere frame in een heightmap gestopt worden en naar de vs gestuurd worden, of iedere frame in een vertexbuffer gepropt moeten worden. direct een txt. naar de vs sturen lijkt me voor mijn gevoel handiger. Maar daar houd het niet op: Aangzien die golven niet alleen van positie veranderen maar ook van hoogte en dergelijke (mesh veranderd), zal ik ook constant de normalen van de hele heightmap moeten berekenen. En ik denk dat dat te zwaar is voor mijn 1700mhz. Ik heb een test gedaan om iedere frame normalen te berekenen van een heightmap en de fps was tussen de 6 en 8 fps... Maar misschien kan het berekenen van normalen effectiever dan dat ik het doe!

[.oisyn]

Die bumpmap methode is vooral handig voor de kleinere ripples. Echte golven kun je beter met mesh doen. Dit is natuurlijk in het algemeen waar - relief op detail-niveau met bumpmaps, relief op grote schaal met mesh.

[roy-t]

Misschien dat je nog wat aan deze tutorial hebt:

http://www.riemers.net/en...4/The_water_technique.php

Het is wel voornamelijk rimpelingen in het water en niet uber golven ofzo, maar tsja hoe meer tuts en ideeën hoe beter :-)

[Mischa_NL]

Kick!



Geoclipmaps geport naar XNA en c#! Heb als basis de code van FilouGK gebruikt.
Ik ben nu met een aantal dingen bezig te weten:
* Normalen fixxen, er zitten nog randen aan de zijkanten van de clipmaps. Oplossing nog niet gevonden.
* Licht morgen wat uitgebreider maken, nu slechts een diffuse + ambient lighting.
* Procedural Texture Splatting: Ik bou voor ieder cliplevel on the fly een texture welke real-time update, zoals ongeveer bij 'MegaTextures' © Carmack.
* Procedural Terrain Generation: Ik gebruik nu wat simpele noise algoritmes om wat te testen. Te weten Simplex Noise (Vlugge Perlin variant) als cohorent noise. Deze vervolgens met Turbulence/Ridge Multifractal, en een crappy voronoi algoritme. Al met al: onbekend terrein, veel proberen, veel falen...

Bugs:
* Toroidal update blijft een doorn in het oog. Bij hoge snelheden knalt de framerate in elkaar. Dit komt omdat er meer updates moeten zijn bij een hogere snelheid. De oplossing zou zijn om minder detail te updaten. Echter geeft dit problemen omdat het level ooit weer gerendert moet worden. Dit zorgt dus voor een MAJOR hickup op het moment dat je ineens weer traag beweegt. Dit is op te lossen door de clip over meerdere frames opnieuw aan te maken. Het probleem hierbij is alleen dat dit makkelijk klinkt maar in praktijk een heel stuk lastiger te bewerkstelligen is!


Source wil ik als daar vraag naar is wel ergens neerplempen. Er zijn volgens mij maar weinig fatsoenlijke XNA ports namelijk...

@ mods: ik weet niet of ik dit op deze manier mag posten maar het lijkt me opzich wel een handige posting voor mensen die op google informatie zoeken over Geoclipmaps.

[TJHeuvel]

Hier is wel vraag naar de source .

[roy-t]

Mischa_NL schreef op donderdag 26 november 2009 @ 03:39:
Kick!

[afbeelding]

Heb je ook een blog Mischa? Ik ben erg benieuwd om is bij elkaar te zien waar je allemaal mee bezig bent, helemaal nu je ook met XNA bezig bent (dichter bij mijn straatje ).

[Mischa_NL]

CyCloneNL schreef op donderdag 26 november 2009 @ 10:02:
Hier is wel vraag naar de source .

Dan zal ik alles eens strippen van de rest van mijn source en het een en ander online gooien (wellicht vandaag nog).

roy-t schreef op donderdag 26 november 2009 @ 10:36:
[...]


Heb je ook een blog Mischa? Ik ben erg benieuwd om is bij elkaar te zien waar je allemaal mee bezig bent, helemaal nu je ook met XNA bezig bent (dichter bij mijn straatje ).

Ik heb helaas geen blog maar het wordt hoog tijd dat ik daar eens mee begin... Tís namelijk wel interessant om die dingen op de een of andere manier te publiceren. De overstap naar xna was overigens wel logisch omdat MDX toch wel heel erg verouderd is nu... Het is alleen jammer dat sommige dingen in XNA ontbreken, en dat er geen ondersteuning voor DX10-DX11 features inzitten. De texture updates bijvoorbeeld zijn verschrikkelijk traag en dat is wel een essentieel onderdeel van GeoClipmaps.
Op het moment doe ik dit met een eigen 'SpriteBatch' class, die wat multi-functioneler (en sneller) is dan de ingebouwde in XNA, maar naar mijn idee nog sneller moet kunnen. Het probleem is dat ik per pixel update en dat de normals dus aan de randen van de clipmaps niet kloppen... Wellicht is het mogelijk de normalen 'on the fly' bij het renderen te genereren, maar daar ben ik eerlijk gezegd nog niet echt mee bezig geweest.

[roy-t]

Mischa_NL schreef op donderdag 26 november 2009 @ 17:50:
[...]

Dan zal ik alles eens strippen van de rest van mijn source en het een en ander online gooien (wellicht vandaag nog).


[...]
Ik heb helaas geen blog maar het wordt hoog tijd dat ik daar eens mee begin... Tís namelijk wel interessant om die dingen op de een of andere manier te publiceren. De overstap naar xna was overigens wel logisch omdat MDX toch wel heel erg verouderd is nu... Het is alleen jammer dat sommige dingen in XNA ontbreken, en dat er geen ondersteuning voor DX10-DX11 features inzitten. De texture updates bijvoorbeeld zijn verschrikkelijk traag en dat is wel een essentieel onderdeel van GeoClipmaps.
Op het moment doe ik dit met een eigen 'SpriteBatch' class, die wat multi-functioneler (en sneller) is dan de ingebouwde in XNA, maar naar mijn idee nog sneller moet kunnen. Het probleem is dat ik per pixel update en dat de normals dus aan de randen van de clipmaps niet kloppen... Wellicht is het mogelijk de normalen 'on the fly' bij het renderen te genereren, maar daar ben ik eerlijk gezegd nog niet echt mee bezig geweest.

Heb je het blog van Shawn Hargreaves al gevonden, hier staan veel tips, best practices en andere dingen in om XNA sneller te krijgen, hij weet alle ins en outs. (Is een van de developers van XNA).

Spam me maar even met een dm, of een postje als je een blog hebt. (Ik kan http://wordpress.com van harte aanraden).

ohja en http://tweakblogs.net natuurlijk (dankje RobIII voor het even tot de orde roepen ).

[ Voor 3% gewijzigd door roy-t op 27-11-2009 08:37 ]

[Mischa_NL]

Source is opgeschoond en geupload. Ik kan aanraden de 'release' versie te draaien aangezien die net wat soepeler loopt: veel plezier ermee.
Overigens alleen getest op een NVidia kaart. Shader model 3.0 is minimaal om het te draaien (door de vertex textures).
Als er iemand dingen veranderd of ziet die beter kunnen. Laat het me alsjeblieft weten!!!

[NC83]

Loopt ook op een Ati HD4850, alleen wil je misschien je camera wat sneller maken want die is echt heel erg langzaam. Daarnaast zou verlichting in de scene ook een mooie zijn zodat je de hoogte verschillen beter ziet.

Daarnaast merkte ik dat als je door de scene heen loopt je drawtime ineens naar 70ms schiet.

[ Voor 18% gewijzigd door NC83 op 28-11-2009 16:21 ]

[Mischa_NL]

NC83 schreef op zaterdag 28 november 2009 @ 16:16:
Loopt ook op een Ati HD4850, alleen wil je misschien je camera wat sneller maken want die is echt heel erg langzaam. Daarnaast zou verlichting in de scene ook een mooie zijn zodat je de hoogte verschillen beter ziet.

Daarnaast merkte ik dat als je door de scene heen loopt je drawtime ineens naar 70ms schiet.

Licht is aanwezig in de scene, alleen in het voorbeeld is de lichtbron statisch. In mijn eigen source zit er een skydome omheen, met een zonnetje in de lucht en dergelijke.
Het langzame lopen valt wel mee. Als je shift en control erbij pakt ga je pak hem beet een km of 80 per uur.
Sneller is een probleem omdat dan de cpu het niet meer bijhoudt. De procedural generation werkt nu nog op de CPU ipv de GPU, en die trekt dat gewoonweg niet.

[TJHeuvel]

Bedankt voor de source Mischa_NL! Al begrijp ik er (nog) niets van, is het onwijs hulpzaam.

[NC83]

Mischa_NL schreef op zaterdag 28 november 2009 @ 16:37:
[...]

Licht is aanwezig in de scene, alleen in het voorbeeld is de lichtbron statisch. In mijn eigen source zit er een skydome omheen, met een zonnetje in de lucht en dergelijke.
Het langzame lopen valt wel mee. Als je shift en control erbij pakt ga je pak hem beet een km of 80 per uur.
Sneller is een probleem omdat dan de cpu het niet meer bijhoudt. De procedural generation werkt nu nog op de CPU ipv de GPU, en die trekt dat gewoonweg niet.

Ah cheers dat had ik nog niet ontdekt ik had gewoon je camera een beetje aan gepast en de snelheid daar op 1 gezet zodat het wat sneller ging.

Komt er nog een GPU versie van de procedural generation?

[Mischa_NL]

NC83 schreef op zondag 29 november 2009 @ 02:34:
[...]

Ah cheers dat had ik nog niet ontdekt ik had gewoon je camera een beetje aan gepast en de snelheid daar op 1 gezet zodat het wat sneller ging.

Komt er nog een GPU versie van de procedural generation?

uiteraard uiteraard... dit is te traag namelijk. Ik hoop volgende week alles op de gpu te hebben.!

[Mischa_NL]

Na zeer veel proberen zijn er toch 2 vragen boven komen drijven:
Ik heb een normal map in tangent space, te weten .rb zijn gevuld met 'waarden' en g is altijd 1.
Nu wil ik uit deze normal map de slope/helling berekenen, maar ik heb nergens duidelijk kunnen vinden hoe dat in zijn werk gaat. Ik bereken de normal van een pixel en wil gelijk ook de slope uitrekenen.

Ik heb het volgende geprobeerd. Ik dacht zelf dat na normalisatie van de vector de Y component, degene die dus 1 was, de slope/helling weergeeft. Dit blijkt echter incorrect.

Stukje shader:

code:

//normal adv sobel operator
    float coef = 1;
    float4 n;
    float2 s1,s2,s3,s4;
    
    s1.x = getHeightAtCoordSimple(float2(In.coords.x-dU, In.coords.y    ));
    s2.x = getHeightAtCoordSimple(float2(In.coords.x   , In.coords.y-dU ));
    s3.x = getHeightAtCoordSimple(float2(In.coords.x+dU, In.coords.y    ));
    s4.x = getHeightAtCoordSimple(float2(In.coords.x   , In.coords.y+dU ));
    n.xy = normalize( float2( (s1.x - s3.x), (s2.x - s4.x))) * coef;
    
    Out.Normal = float4( packNormal(n.x), packNormal(n.y), 0, 0);

//slope uitrekenen...
    float4 texalpha  = float4(0,0,0,0);
    float3 normalF = float3(n.x,1,n.y);
    normalF = normalize(normalF);
    
    float slope = normalF.y;
    
    if (slope < 0.35)
    {
        texalpha = float4(0,0,0,1); 
    }
    
    Out.Texture = texalpha;

De volgende vraag waarop ik neit echt antwoord vind is de volgende: texture filters in hlsl. Hoe werk LINEAR filtering precies? Gebruikt dit filter een pixel boven onder links en rechts en blend daartussen?

Update op de terrain engine:
* Normalen worden gegenereerd op de gpu met behulp van multiple render targets (MRT's).
* TBN matrix voor licht gefixt waardoor specular higlights ineens wel lijken te kloppen.

Todo:
* D.m.v. texture lookups de courser niveaus updaten, zou 15 van de 20 calls naar de 'GenerateHeightAtXY' functie schelen, massive speedup gok ik.
* Toch ipv per pixel updaten de 4 clipshifts met grote quads updaten.
* Slope uitrekenen zodat ik op hoogte + slope kan gaan textue splatten
* Procedural generation uitgebreider maken (nu 12 octaves turbulence dmv simplex noise)
* Een bug met texture filtering/samplers fixxen.

Bij voorbaat dank alweer voor het beantwoorden.

[R4gnax]

Mischa_NL schreef op donderdag 21 februari 2008 @ 15:13:
Bumpmapping techniek is namelijk níet gpu intensief aangezien ik maar 2 triangles (een quad) render. Nadeel is echter dat met een hoek vlak op het water je bumpmapping vrijwel helemaal verloren gaat.

Een mesh is uiteraard gpu intensief omdat er een hoop extra primitives gerenderd moeten worden. Ook is het cpu intensief omdat ik een algoritme zal moeten schrijven om golven te creeeren. En daar komt het lullige. Die golven moeten iedere frame in een heightmap gestopt worden en naar de vs gestuurd worden, of iedere frame in een vertexbuffer gepropt moeten worden. direct een txt. naar de vs sturen lijkt me voor mijn gevoel handiger. Maar daar houd het niet op: Aangzien die golven niet alleen van positie veranderen maar ook van hoogte en dergelijke (mesh veranderd), zal ik ook constant de normalen van de hele heightmap moeten berekenen. En ik denk dat dat te zwaar is voor mijn 1700mhz. Ik heb een test gedaan om iedere frame normalen te berekenen van een heightmap en de fps was tussen de 6 en 8 fps... Maar misschien kan het berekenen van normalen effectiever dan dat ik het doe!

Wat dacht je er van om je water te renderen met volume rendering technieken? Kan je tegenwoordig heel goed in real time doen met shaders op je grafische kaart. Kijk maar eens naar Realistic Water Volumes in Real-Time, van Baboud en Décoret.

Hun demo filmpje ziet er echt super uit, met verschrikkelijk mooie golf effecten en correcte reflectie en refractie. Kijk maar eens naar het stukje rond de 02:15, waar ze met de muis cursor golven door het water slepen. Verbazingwekkend cool.

[ Voor 7% gewijzigd door R4gnax op 02-12-2009 22:53 ]

[.oisyn]

R4gnax schreef op woensdag 02 december 2009 @ 22:47:
[...]


Wat dacht je er van om je water te renderen met volume rendering technieken?

Ik denk er iig van dat het complete onzin is om je tijd te spenderen aan een dergelijke realistische modellering van de werkelijkheid terwijl het door de boel te faken mbv een reflection en refraction map en distortions aan de hand van de water normal er net zo goed uitziet maar gigantisch veel sneller is . Leuk dat je het tegenwoordig in real time kunt doen, maar je houdt niet echt veel shader throughput meer over voor de rest van je scene.

Mischa_NL schreef op woensdag 02 december 2009 @ 20:15:
Na zeer veel proberen zijn er toch 2 vragen boven komen drijven:
Ik heb een normal map in tangent space, te weten .rb zijn gevuld met 'waarden' en g is altijd 1.
Nu wil ik uit deze normal map de slope/helling berekenen, maar ik heb nergens duidelijk kunnen vinden hoe dat in zijn werk gaat. Ik bereken de normal van een pixel en wil gelijk ook de slope uitrekenen.

Ik heb het volgende geprobeerd. Ik dacht zelf dat na normalisatie van de vector de Y component, degene die dus 1 was, de slope/helling weergeeft. Dit blijkt echter incorrect.

Slope is de tangent van je surface, die per definitie loodrecht staat op de normal. Door het nemen van het y-component doe je effectief een dotproduct met (0, 1, 0), oftewel, je kijkt hoeveel de normal omhoog wijst, terwijl je juist bent geïnteresseerd in hoeveel hij opzij wijst. Ik zou simpelweg 1 min die waarde nemen als slope. Correcter is waarschijnlijk om de cross te nemen met (0, 1, 0) (dan krijg je de bitangent parallel aan de surface, zeg maar de richting van de isolijn van gelijke hoogte - wel even normalizen trouwens), en dan weer te crossen met de normal (dan krijg je de tangent, dus de vector die wijst richting het hoogste punt op de surface). Daar het y-component van is dan daadwerkelijk je slope.

Dus
float3 tangent = n × (0, 1, 0) × n;
float slope = tangent.y;

Maar goed, eigenlijk wil je dat allemaal niet, want je berekent je normal uit je height map, en dat is een veel betere bron voor je slope: namelijk het verschil tussen de hoogste sample en de laagste sample.

[ Voor 58% gewijzigd door .oisyn op 03-12-2009 01:35 ]

[Mischa_NL]

.oisyn schreef op donderdag 03 december 2009 @ 01:06:
[...]

Ik denk er iig van dat het complete onzin is om je tijd te spenderen aan een dergelijke realistische modellering van de werkelijkheid terwijl het door de boel te faken mbv een reflection en refraction map en distortions aan de hand van de water normal er net zo goed uitziet maar gigantisch veel sneller is . Leuk dat je het tegenwoordig in real time kunt doen, maar je houdt niet echt veel shader throughput meer over voor de rest van je scene.


[...]

Slope is de tangent van je surface, die per definitie loodrecht staat op de normal. Door het nemen van het y-component doe je effectief een dotproduct met (0, 1, 0), oftewel, je kijkt hoeveel de normal omhoog wijst, terwijl je juist bent geïnteresseerd in hoeveel hij opzij wijst. Ik zou simpelweg 1 min die waarde nemen als slope. Correcter is waarschijnlijk om de cross te nemen met (0, 1, 0) (dan krijg je de bitangent parallel aan de surface, zeg maar de richting van de isolijn van gelijke hoogte - wel even normalizen trouwens), en dan weer te crossen met de normal (dan krijg je de tangent, dus de vector die wijst richting het hoogste punt op de surface). Daar het y-component van is dan daadwerkelijk je slope.

Dus
float3 tangent = n × (0, 1, 0) × n;
float slope = tangent.y;

Maar goed, eigenlijk wil je dat allemaal niet, want je berekent je normal uit je height map, en dat is een veel betere bron voor je slope: namelijk het verschil tussen de hoogste sample en de laagste sample.

Ik weet echt niet wat ik verkeerd doe maar het werkt gewoon niet .
Ik word er helemaal gek van dat zoiets simpels niet wil lukken.

code:

    float3 normal = normalize(float3(n.x,n.y,1));
    float3 tangent = cross(normal, (0, 1, 0));
    tangent = normalize(tangent);
    tangent = cross(tangent, normal);
    float slope = tangent.y;

Ik heb allerlei andere variaties geprobeerd maar niks lijkt te kloppen... het lijkt als ik uberhaubt iets krijg alsof slechts 1 'kant' gebeurt. Ik krijg dan aan 1 kant van de berg rare waarden en aan de andere kant helemaal niks. It's driving me mad...
Is de elevationmap samplen niet veel 'duurder' dan de slope bepalen uit een reeds bepaalde normal?

[NC83]

Mischa_NL schreef op donderdag 03 december 2009 @ 03:20:
[...]

Ik weet echt niet wat ik verkeerd doe maar het werkt gewoon niet .
Ik word er helemaal gek van dat zoiets simpels niet wil lukken.

code:

    float3 normal = normalize(float3(n.x,n.y,1));
    float3 tangent = cross(normal, (0, 1, 0));
    tangent = normalize(tangent);
    tangent = cross(tangent, normal);
    float slope = tangent.y;

Ik heb allerlei andere variaties geprobeerd maar niks lijkt te kloppen... het lijkt als ik uberhaubt iets krijg alsof slechts 1 'kant' gebeurt. Ik krijg dan aan 1 kant van de berg rare waarden en aan de andere kant helemaal niks. It's driving me mad...
Is de elevationmap samplen niet veel 'duurder' dan de slope bepalen uit een reeds bepaalde normal?

tangent = cross(tangent, normal); <-- Dit is een binormal

De berekening die je daar doet geeft je een assenstelsel net zoals dat je dit in een camera class doet om de camera assen te vinden.

[Edit] Nog geen koffie gehad alleen op varnamen gelet.

[R4gnax]

.oisyn schreef op donderdag 03 december 2009 @ 01:06:
[...]

Ik denk er iig van dat het complete onzin is om je tijd te spenderen aan een dergelijke realistische modellering van de werkelijkheid terwijl het door de boel te faken mbv een reflection en refraction map en distortions aan de hand van de water normal er net zo goed uitziet maar gigantisch veel sneller is . Leuk dat je het tegenwoordig in real time kunt doen, maar je houdt niet echt veel shader throughput meer over voor de rest van je scene.

Ja, want met een reflection en refraction maps kun je ook echt zo goed golvend water maken, niet waar?

Volume rendering kun je ook met fake data doen. Er hoeft niet echte physics achter te zitten. Het staat je wèl toe om golven echte geometrische diepte te geven: on the fly, op de GPU en zonder meshes te moeten manipuleren en continu naar de GPU te moeten her-uploaden.

[.oisyn]

R4gnax schreef op donderdag 03 december 2009 @ 10:56:
[...]


Ja, want met een reflection en refraction maps kun je ook echt zo goed golvend water maken, niet waar?

Nee, dat doe je met een height map, die je vanuit de vertex shader kunt samplen. En het processen van de golven in die height map is niets meer dan een simpele blur operatie.

En sowieso, waar hebben we het over als je het als mesh behandeld, wat niet meer is dan een array van floats met puur en alleen de height samples, aangezien de rest van de mesh (in de x en z richting) statisch is. Dus het is dan een kwestie van meerdere streams gebruiken.

.edit: picta


Overigens, wat je voor het gemak maar even vergeet is dat je sowieso op de CPU wat verwerking zult moeten doen voor gameplay mechanics. Iets dat in het water drijft zal ook met de golven mee moeten dijnen, anders ziet het er echt niet uit.

[ Voor 44% gewijzigd door .oisyn op 03-12-2009 12:00 ]

[.oisyn]

Mischa_NL schreef op donderdag 03 december 2009 @ 03:20:
[...]

Ik weet echt niet wat ik verkeerd doe maar het werkt gewoon niet .
Ik word er helemaal gek van dat zoiets simpels niet wil lukken.

code:

    float3 normal = normalize(float3(n.x,n.y,1));
    float3 tangent = cross(normal, (0, 1, 0));
    tangent = normalize(tangent);
    tangent = cross(tangent, normal);
    float slope = tangent.y;

Waarom neem je daar nu ineens (n.x, n.y, 1) als normal ipv (n.x, 1, n.y)? Ik ging er vanuit dat (0, 1, 0) recht omhoog wees bij een compleet horizontale surface (oftewel allemaal gelijkwaardige height samples). Als jij (0, 0, 1) als "omhoog" definieert dan moet je ook met (0, 0, 1) crossen. Overigens kan het zijn dat de crossproducts dan de verkeerde kant op staan, dat zul je zelf even moeten evalueren. Voor een linkshandig coordinatenstelsel met y=up zou het moeten werken.

Is de elevationmap samplen niet veel 'duurder' dan de slope bepalen uit een reeds bepaalde normal?

Ja maar je samplet 'm toch al om de normal te bepalen . Diezelfde samples kun je ook gebruiken voor het berekenen van je slope.

[Mischa_NL]

.oisyn schreef op donderdag 03 december 2009 @ 11:35:
Ja maar je samplet 'm toch al om de normal te bepalen . Diezelfde samples kun je ook gebruiken voor het berekenen van je slope.

Verdomd zeg. Daar zit wat in .

Waarom ik overigens ineens (x,y,1) gebruik geen idee, te lang mee bezig geweest gisteren denk ik, dan ga je stomme fouten maken.

Overigens, voor water denk ik dat ik gewoon een 2e geoclipmap gebruik: Water heeft niet echt 'punten' dus detail zal in de verte bijna niet verloren gaan, iets dat met terrain icm geoclipmaps wel het geval is. Dit in combinatie met als ik het goed weet een FFT tabel ofzoiets zou als ik het nog goed weet redelijke resultaten moeten geven. FFT (fast fourier transform) wordt oa in crysis gebruikt, en dat ziet er toch niet misselijk uit...

[ Voor 34% gewijzigd door Mischa_NL op 03-12-2009 15:19 ]

[Mischa_NL]

Nou ik ben nog even met die slope aan de gang gegaan maar het lukt gewoon niet... alle mogelijke combinaties wel een beetje geprobeerd...

code:

    float3 nnormal = normalize(float3(n.x,1,n.y));
    float3 tangent = cross(normalize(float3(0,1,0)), nnormal);
            tangent= normalize(cross(tangent, nnormal));
    float slope = tangent.y;    
        
            
    if (slope > 0.15)
    {
        texalpha = float4(0,0,0,0); 
    }

De normal map klopt wel (gekeken met normal map maker van NVidia en komt zeer aardig overeen).

Ik zal ook even mijn TBN matrix posten in de render.fx, misschien dat iemand daar iets aan heeft.

code:

    float3  normal = float3(tex2Dlod(Normals, float4(TexCoords, 0.0, 0.0)).rg,1);
            normal  = normal.rbg;
            
    float3 n = mul(normal,          (float3x3)World);
    float3 t = mul(float3(1,0,0),   (float3x3)World);
    float3 b = mul(float3(0,0,1),   (float3x3)World);
    float3x3 TangentBinormalNormal = float3x3(  t.x,b.x,n.x,
                                                t.y,b.y,n.y,
                                                t.z,b.z,n.z);

Ik krijg bij het uitrekenen van de slope constant het idee dat slechts 1 kant berekend wordt. Bijvoorbeeld: 1 kant van de berg klopt, de andere niet. Gek hoe zo iets klaarblijkelijk simpels zo verrekte lastig is...

[.oisyn]

In dat bovenste voorbeeld heb je de params van het eerste cross product omgedraaid. Dat geeft je een vector die juist naar beneden wijst ipv naar boven.

Het moet zijn: tangent = cross(normalize(cross(normal, float3(0, 1, 0))), normal).
Maar goed, heb je PIX er al eens bijgepakt en je shader gedebugged?

[Mischa_NL]

.oisyn schreef op donderdag 03 december 2009 @ 21:29:
In dat bovenste voorbeeld heb je de params van het eerste cross product omgedraaid. Dat geeft je een vector die juist naar beneden wijst ipv naar boven.

Het moet zijn: tangent = cross(normalize(cross(normal, float3(0, 1, 0))), normal).
Maar goed, heb je PIX er al eens bijgepakt en je shader gedebugged?

PIX maakt er ASM van? Om eerlijk te zijn ben ik geen ASM held (ik kan het ècht niet).

Anyhow. Het blijft 'ruis' teruggeven. Dat geeft als tangent.y ong. 1.0... Ik denk dat ik maar ergens anders aan ga werken want dit wordt me too much...

[Mischa_NL]

Aha!

Daar komt het antwoord...
Ik kreeg het niet werkend omdat height-samples op courser clipmaps natuurlijk verder uit elkaar liggen... Hier hield ik geen rekening mee.

WIP screenie:




Voor de geïnteresseerde de proof-of-concept code zeg maar...

code:

    float slopex = abs(s1.x - s3.x)/dU/scale;  //absolute verschil tussen hor. samples
    float slopey = abs(s2.x - s4.x)/dU/scale;   //en tussen vert.
        
    if (slopex > 0.8 || slopey > 0.8) // als vert of hor > 0.8
        texalpha.a = tex2D(TerrainColor,float2(Out.Elevation.r,0)).a;//steen showen

Ook ben ik wel benieuwd of er mensen zijn met goede kwaliteit textures. De textures die ik nu gebruik zijn vrij crappy, en de specular en normal maps zomaar gegenereerd en niet echt high quality.
Iemand die links heeft of toevallig wat high qualitiy textures in zijn bezit heeft?

[ Voor 52% gewijzigd door Mischa_NL op 11-12-2009 21:56 ]

[NC83]

.oisyn schreef op donderdag 03 december 2009 @ 21:29:
In dat bovenste voorbeeld heb je de params van het eerste cross product omgedraaid. Dat geeft je een vector die juist naar beneden wijst ipv naar boven.

Het moet zijn: tangent = cross(normalize(cross(normal, float3(0, 1, 0))), normal).
Maar goed, heb je PIX er al eens bijgepakt en je shader gedebugged?

PIX is kut om op windows shaders mee te debuggen hartstikke fijne tool voor XBox shader debugging maar niet voor windows. Vista x64 krijgt het zelfs zover dat als ik op debug vertex klik de applicatie gewoon crasht en ja ik draai PIX(x64).

[armageddon_2k1]

Mischa_NL schreef op vrijdag 11 december 2009 @ 21:03:
Ook ben ik wel benieuwd of er mensen zijn met goede kwaliteit textures. De textures die ik nu gebruik zijn vrij crappy, en de specular en normal maps zomaar gegenereerd en niet echt high quality.
Iemand die links heeft of toevallig wat high qualitiy textures in zijn bezit heeft?

Voor Flight Simulator 2004 had je indertijd user-made add-ons met verbeterde textures voor het landschap. Deze bevatten allemaal seamless textures voor verschillende slopes van bergen. Misschien moet je daar even op zoeken.

[.oisyn]

NC83 schreef op vrijdag 11 december 2009 @ 21:46:
[...]

PIX is kut om op windows shaders mee te debuggen hartstikke fijne tool voor XBox shader debugging maar niet voor windows. Vista x64 krijgt het zelfs zover dat als ik op debug vertex klik de applicatie gewoon crasht en ja ik draai PIX(x64).

Als je fatsoenlijk shaders wilt kunnen debuggen zul je je sowieso met de asm bekend moeten maken. En natuurlijk wel zorgen dat je je shaders compiled in debug mode. Overigens werkt shader debugging hier prima in Windows 7 x64.

[NC83]

MIschien is het punt dat mijn shaders niet in debug zijn gecompiled en ik er vanuit ga dat d3dx dit voor me doet een keer onderzoeken maar. Want het zou afentoe wel handig zijn om het wel te kunnen.

[.oisyn]

Als je de D3DXCompileShader*** functies gebruikt kun je een vlaggetje meegeven dat hij als debug moet compileren

[NC83]

C++:

bool Effect::loadEffectFile( const String& filename, LPDIRECT3DDEVICE9 device )
{
WORD flags = D3DXFX_NOT_CLONEABLE;
#ifdef DEBUG
    flags |= D3DXSHADER_DEBUG;
#endif
    if (FAILED(D3DXCreateEffectFromFile( device, filename.getWString().c_str(), NULL, m_include, flags, NULL, &m_effect, &m_errors )))
    {
        ERR << "Couldn't compile effect file:" << END;
        if (m_errors != NULL)
        {
            char* errors = new char[m_errors->GetBufferSize() + 1];
            errors = (char*)m_errors->GetBufferPointer();
            errors[m_errors->GetBufferSize()] = 0;
            string errormsg(errors);
            ERR << "Effect Compile errors: \n" << errormsg << END;
            delete [] errors;
        }
        return false;
    }
    return true;
}

Zoals dat dus dan begrijp ik nog niet helemaal waarom het verkeerd gaat kan zijn dat ik een preprocessor command ben vergeten te definieren maar dat geloof ik niet.

edit:

Denk dat ik em heb de lib had wel DEBUG defined maar het project dat de exe bouwt niet maar ff toegevoegd.

[ Voor 10% gewijzigd door NC83 op 15-12-2009 21:25 ]

[Mischa_NL]

NC83 schreef op dinsdag 15 december 2009 @ 21:21:

C++:

bool Effect::loadEffectFile( const String& filename, LPDIRECT3DDEVICE9 device )
{
WORD flags = D3DXFX_NOT_CLONEABLE;
#ifdef DEBUG
    flags |= D3DXSHADER_DEBUG;
#endif
    if (FAILED(D3DXCreateEffectFromFile( device, filename.getWString().c_str(), NULL, m_include, flags, NULL, &m_effect, &m_errors )))
    {
        ERR << "Couldn't compile effect file:" << END;
        if (m_errors != NULL)
        {
            char* errors = new char[m_errors->GetBufferSize() + 1];
            errors = (char*)m_errors->GetBufferPointer();
            errors[m_errors->GetBufferSize()] = 0;
            string errormsg(errors);
            ERR << "Effect Compile errors: \n" << errormsg << END;
            delete [] errors;
        }
        return false;
    }
    return true;
}

Zoals dat dus dan begrijp ik nog niet helemaal waarom het verkeerd gaat kan zijn dat ik een preprocessor command ben vergeten te definieren maar dat geloof ik niet.

edit:

Denk dat ik em heb de lib had wel DEBUG defined maar het project dat de exe bouwt niet maar ff toegevoegd.

ik was laatst bezig en ik kreeg ook vage errors over dat ik een valid ps en vs moest hebben, uiteindeijk waren de ps en vs wel 'valid', maar hadden ze teveel instructies, en crashte de app. Al met al, kijik je niet dood op wat de error is maar probeer te kijken waarom je de error krijgt.

Overigens ben ik nu bezig met texturing.
Vraagje aan oisyn de expert haha: ik ben met textue atlassing bezig, heb jij een link, of kennis hoe ik dit het beste kan aanpakken.

Atlasses zijn essentieel vanwege het feit dat de slope- en altmap een texture aanwijzen van 0 tm 15 (in 1 texture) die laten zien moet worden. Echter blijf ik seams houden door mig en magfilter (volgens mij).

Ik hoop dat de pro's hier een antwoord op hebben, kwa een paper of implementatie welke goed werkt.

Hierna ga ik overigens de boel ombouwen toe planetary engine, zodat ik planten kan gaan renderen ipv vlakke stukkies terrein. Hoop onderzoek gedaan, en ik ga cube/sphere mappen met een global mesh met daarin de clipmaps... gaat overigens waarschijnlijk nog wel weken duren gok ik, voordat ik dat vor elkaar heb..

[NC83]

Mischa_NL schreef op woensdag 16 december 2009 @ 00:33:
ik was laatst bezig en ik kreeg ook vage errors over dat ik een valid ps en vs moest hebben, uiteindeijk waren de ps en vs wel 'valid', maar hadden ze teveel instructies, en crashte de app. Al met al, kijik je niet dood op wat de error is maar probeer te kijken waarom je de error krijgt.

Ow maar daar heb je ander tools voor zoals de AMD shader analyser die je aangeeft hoeveel instructies je gebruikt. Een ander leuk probleem dat ook vaak voorkomt daarbij is loop unrolling in shaders vooral in SM2 maar 3 heeft er ook last van. Dit gaf namelijk leuke shader compile errors tijdens mijn dissertation.

Mischa_NL schreef op woensdag 16 december 2009 @ 00:33:
[...]
Vraagje aan oisyn de expert haha: ik ben met textue atlassing bezig, heb jij een link, of kennis hoe ik dit het beste kan aanpakken.

http://developer.nvidia.com/object/texture_atlas_tools.html met white paper is wat ik heb gebruikt toen ik het geimplementeerd heb. Staar je niet dol op hun packing code want die is niet effiecient, en daar waarschuwen ze ook voor in de code comments. Packing algorithms kun je overal op Inet vinden trouwens ( http://www.blackpawn.com/texts/lightmaps/default.html )
Een punt texture atlas is niet geschikt voor mipmaps het kan wel maar is niet aan te raden. Iid geen hardware generated mips omdat je dan allemaal blend problemen krijgt met de omliggende textures.

[ Voor 67% gewijzigd door NC83 op 16-12-2009 00:49 ]

[Mischa_NL]

Update!
Ik heb de Texture atlassen nog steeds niet 100% gefixt, ik blijf seams houden door de min en magfilter.



Realisme is ver te zoeken, maar tis allemaal WIP uiteraard. Anti-aliasing stond ook uit zie ik...

[Mischa_NL]

Zo, en maar weer eens een vraag + een updateje.

Na veel gezeik met die gpugeoclipmaps toch maar besloten de boel overboord te gooien.
Ik heb, omdat voorbeelden niet echt te vinden waren, een eigen quadtree terrain gebouwd, en dat werkt zonder meer fantastisch!

Echter vraag ik me af hoe ik het beste kan splitten. Mij leek het handig om te splitten als de screen pixels per patch kleiner worden dan een bepaald getal, dit zorgt voor een constante resolutie.
Het probleem is dat ik geen idee heb hoe dit te doen. Ook google helpt me dit keer niet veel verder.

Ook maar even een screen:


Bij voorbaat dank alweer!

[PrisonerOfPain]

Mischa_NL schreef op vrijdag 08 januari 2010 @ 22:41:
Mij leek het handig om te splitten als de screen pixels per patch kleiner worden dan een bepaald getal, dit zorgt voor een constante resolutie.

Vertices unprojecten en kijken naar het oppervlakte van je triangle lijkt me het makkelijkst :-). Vziw heeft DirectX geen gluUnproject equivalent, maar dat is niet al te lastig om in elkaar te schroeven.

[ Voor 12% gewijzigd door PrisonerOfPain op 08-01-2010 23:29 ]

[Mischa_NL]

PrisonerOfPain schreef op vrijdag 08 januari 2010 @ 23:27:
[...]


Vertices unprojecten en kijken naar het oppervlakte van je triangle lijkt me het makkelijkst :-). Vziw heeft DirectX geen gluUnproject equivalent, maar dat is niet al te lastig om in elkaar te schroeven.

Even zitten kijken naar de project functie in XNA, maar het is uiteraard niet handig omdat de wereld bol is, en de patches dus 'gebogen' zitten en niet recht voor de camera staan.

Wat ik eigenlijk exact wil doen is het volgende:
* bereken de afstand van camera tot patch.
* hoe groot is deze patch als hij RECHT voor de camera staat
* als hij groter is dan [getal] split hem.

OVerigens, als dit een achterlijke manier is om te splitten hoor ik het graaag!

//edit. wellicht duidelijker:
wat ik dus wil weten is als een object recht voor de camera op een bepaalde afstand staat, hoeveel pixels beslaat het dan in screen space. Ik hoef dus niet te weten hoeveel pixels dat object daadwerkelijk beslaat, maar hoeveel een object met die grootte, met de normaal naar de camera beslaat!


edit2/ Oplossing is verbijsterend simpel!
Als de eerste split-afstand 100.000 is, dan is de 2e 50.000 en de derde 25.000, and so on...

[ Voor 23% gewijzigd door Mischa_NL op 09-01-2010 14:41 ]

[Mischa_NL]

Geen idee of het toegestaan is maar ik hou hier toch maar een beetje bij waar ik mee bezig ben. Beter dat de mensen hier komen kijken dan op gamedev lijkt me!

Allereerst hier de planeet zoals die op het moment gerenderd wordt. Textures zijn 'placeholders' en wordt nog compleet aangepast. Ook de heightdata is een simpele 50 octaves turbulence 3d noise tex.


Frustum + Horizon Culling geimplementeerd. Alleen patches die in de view frustum en zichtbaar zijn (geen occluders zoals horizon) worden naar de gpu gestuurd. De zwarte punt is de camerapositie, lichte gedeelte het gecullde:


Ook het zeer ingewikkelde stitching bleek verdomde makkelijk! If neighbour_lod < my_lod then stitch. Simpelweg in de vertex buffer vertexen 'verplaatsen' om zodoende een waaier te krijgen:


Voor geintresseerden:

code:

    /*                              //
    //                              //
    //          STITCHING           //
    //                              //
    //                              */

    // if vertex is uneven its 1, else its 0.
    float2 UnevenVertex = (input.gridPos.xy) % 2;
    float2 localPos = (input.gridPos.xy)/(PatchSize-1)*2-1; 
        
    // if border, perform stitching
    if (localPos.y == -1)
    {
        input.gridPos.x = input.gridPos.x + UnevenVertex.x*(localPos.y*pow(input.LodChange.x,2));
    }
    else if (localPos.y == 1)
    {
        input.gridPos.x = input.gridPos.x + UnevenVertex.x*(localPos.y*pow(input.LodChange.z,2));
    }
    else if (localPos.x == -1)
    {
        input.gridPos.y = input.gridPos.y + UnevenVertex.y*(localPos.x*pow(input.LodChange.w,2));
    }
    else if (localPos.x == 1)
    {
        input.gridPos.y = input.gridPos.y + UnevenVertex.y*(localPos.x*pow(input.LodChange.y,2));
    }

Patchsize: Aantal vertexen per patch
gridPos: vertexpositie relatief aan de patch: patchsize = 15, gridpos:[0;14]
lodChange: x=top, y=right, z=bottom, w = left. bool met daarin of neighbour resolutie kleiner is. Zo ja stitchen!

Veel bereikt in een aantal dagen om het zo maar te zeggen.

De engine voert overigens maar 1 drawcall per 'zijde' van de planeet uit (6 stuks dus). Alle heightdata wordt bij split gerendert naar een texture-atlas. bij de update-pre/render vul ik een instancebuffer met de positie, neighbour-data en patch-id. Vervolgens zoek ik tijdens de render in de atlas de goede patch op. Zorgt er dus voor dat de draw calls geminimaliseerd worden.

PS. let ook op de heerlijk hoge framerates!!

Er zijn echter nog dingen waar ik naar op zoek ben. En dat is met name een 'split-schema'. Dat wil zeggen, wanneer moet ik een node laten splitten in 4 kinderen? Ik heb het nu lineair vanaf een vooringestelde afstand. en dan als afstand de helft wordt, split ik. Het lijkt me dat dit beter moet kunnen! Iemand ideeën?

Coming up: Normal mapping & diffuse lighting!

[ Voor 7% gewijzigd door Mischa_NL op 15-01-2010 02:51 ]

[Mischa_NL]

Wederom is tangent space weer hetgeen wat me niet lukt.

Ik heb een zogenaamde geo-sphere, waar dus op de bol de uv coordinaten niet naar de polen lopen maar netjes over de hele bol verdeeld zijn. Zie de wire een paar posts terug.

Nu wil ik dus omrekenen een tbn matrix maken waar ik vervolgens mijn lightdir doorheen gooi. Dit om mijn tangent space normal maps te kunnen gebruiken.

Echter ben ik het spoor weer bijster. De normaal heb ik al heel simpel gevonden. Dat is namelijk de vertex-positie genormaliseerd. Echter hoe bereken ik vervolgens de tangent? deze ligt neem ik aan haaks op de normaal? Kan ik die vector fixen vanuit de normaal?

Tangent space heeft me iedere keer weer te pakken

[PrisonerOfPain]

code:

float3 T(0, 0, 0);
float3 T1 = cross(N, float3(0, 0, 1));
float3 T2 = cross(N, float3(0, 1, 0));

T = (length(T1) > length(T2)) ? T1 : T2;

float3 B = cross(T, N);

Misschien dat je ze nog moet normalizen, maar als de normal op unit-length is zou dat niet moeten hoeven.

Maar goed, als je geen animaties gebruikt kun je makkelijker af met object-space normal maps :-)

[Mischa_NL]

raar raar raar raar raar .

code:

vs
    float3 n = mul(normal,                          (float3x3)worldMatrix);     
    float3 t = mul(normal,                          (float3x3)worldMatrix);
    float3 b = mul((cross(n,t)),                    (float3x3)worldMatrix);
    float3x3 TangentBinormalNormal = float3x3(  t,b,n);

    output.LightDirection = float4(mul(LightDirection, TangentBinormalNormal),1.0).zxyw;    

ps
    float4 diffuse = dot( normalize(input.LightDirection.xyz), normalize(float3(0,1,0))) * DiffuseIntensity * DiffuseColor;
    float4 diffuse2 = dot( normalize(LightDirection.xyz), normalize(Input.Normal)) * DiffuseIntensity * DiffuseColor;

diffuse1 = lightdirection in tangent space, normal = up
diffuse2 = lightdirection in object space, normal = sphere normal

Geeft bijna dezelfde resultaten.
Zeer appart. Diffuse2 is wat 'feller', dus het is niet exact hetzelfde, maar het kan er imho mee door!

Weer bedankt maar weer!

correctie, dat was alleen omdat lightdir float3(-1,0,0) was...

Ik zal dat van jou proberen PoP

[ Voor 5% gewijzigd door Mischa_NL op 21-01-2010 00:58 ]

[PrisonerOfPain]

Je tbn klopt in dit geval niet aangezien het geen geldig coordinatensysteem specificeerd omdat je tangent en normal gelijk zijn.

[.oisyn]

Voor het berekenen van binormals (bitangents is een betere term, maar soit, iedereen heeft het nou eenmaal over binormals) en tangents zijn de texturecoordinaten van de vertices van de polygonen van belang. De tangent loopt namelijk in de richting van de x-as van de texture, en de binormal in de richting van de y-as (of whatever jij liever hebt, de kern van het verhaal is dat het afhangt van hoe de texture op de surface gemapped is). Denk er maar aan: als je de normal map zou roteren met x graden dan moet de light vector in texture space -x graden worden gedraaid. Hou wel rekening met discontinuities op de edges. Dat een vertex die wordt gedeeld door twee polygonen voor beide polygonen hetzelfde texturecoordinaat gebruikt wil niet zeggen dat de tangents en binormals voor die twee polygonen op dat punt gelijk zijn. De kans is groot dat je in sommige gevallen vertices moet gaan dupliceren.

Als je textures altijd quads zijn en lopen van (0, 0) linksboven naar (1, 1) rechtsonder versimpelt dat de boel wel, want dan is je tangent gewoon de richting van vertex linksboven naar vertex rechtsboven, en de binormal de richting van vertex linksboven naar vertex linksonder. Wel even voor de bolling van de polygoon compenseren (je vertex normal is immers ook niet gelijk aan je face normal)

PrisonerOfPain schreef op donderdag 21 januari 2010 @ 00:42:

code:

float3 T(0, 0, 0);
float3 T1 = cross(N, float3(0, 0, 1));
float3 T2 = cross(N, float3(0, 1, 0));

T = (length(T1) > length(T2)) ? T1 : T2;

float3 B = cross(T, N);

Wat je hier doet is in feite willekeurige tangent en binormals uitrekenen, maar dat is voor normal mapping niet zo handig.

Misschien dat je ze nog moet normalizen, maar als de normal op unit-length is zou dat niet moeten hoeven.

T moet genormalized worden. Er komt bij unit-length vectoren alleen een unit-length vector uit het crossproduct als de vectoren haaks op elkaar staan (de lengte is namelijk gelijk aan sin(a) * ||A|| * ||B||, en aangezien ||A|| = ||B|| = 1 moet a wel 90 zijn).

[ Voor 40% gewijzigd door .oisyn op 21-01-2010 01:17 ]

[PrisonerOfPain]

.oisyn schreef op donderdag 21 januari 2010 @ 00:59:
Wat je hier doet is in feite willekeurige tangent en binormals uitrekenen, maar dat is voor normal mapping niet zo handig.

Correct, ik sprong iets te snel tot de conclusie dat de tangent perpendicular was op de normal en dus op een dergelijke manier berekend kon worden. Wat er eigenlijk moet gebeuren is dat de tangent afgeleid moet worden uit de uvs en de posities van de vertices, voor je ze naar de vertex shader stuurt.

[Mischa_NL]

De texturecoordinaten lopen eender met de vertexposities. vertex[0,0] == texc[0,0] vertex[1,1] == texc[1,1].

Ik maak van een platte grid met x en y coordinaten in de vs een bol. zijde van de kubus heeft een aparte map, wat het texturen dus zeer gemakkelijk zou moeten maken.
Alle Texcoords liggen dus zodoende ook binnen een patch ook even ver uit elkaar.

Is het volgende niet mogelijk?

vertexpos normalizen geeft de normaal op de sphere.
vertexpos.x+1,yz = volgende vertex, trek huidge pos af van deze en je hebt de verschilvector == tangent?
bitangent = cross(n,t)

Ik snap niet waarom dat niet zou kunnen werken

PrisonerOfPain schreef op donderdag 21 januari 2010 @ 01:14:
[...]


Correct, ik sprong iets te snel tot de conclusie dat de tangent perpendicular was op de normal en dus op een dergelijke manier berekend kon worden. Wat er eigenlijk moet gebeuren is dat de tangent afgeleid moet worden uit de uvs en de posities van de vertices, voor je ze naar de vertex shader stuurt.

Uv's zijn niet te berekenen voor ze in de vs komen, het is namelijk een static platte mesh, die een functie ingaat en daar corresponderende 'coordinaten op de bol' toekent. Als ik de uv's ga meesturen naar de gpu is heel het instancen van patches ineens onmogelijk.

[ Voor 35% gewijzigd door Mischa_NL op 21-01-2010 01:26 ]

[.oisyn]

Mischa_NL schreef op donderdag 21 januari 2010 @ 01:24:
vertexpos normalizen geeft de normaal op de sphere.
vertexpos.x+1,yz = volgende vertex, trek huidge pos af van deze en je hebt de verschilvector == tangent?

Dat werkt alleen voor de vertex op (0, 0, -1). Denk eraan dat de vertex op (1, 0, 0) een "naar rechts" heeft van (0, 0, 1) in world space, en de vertex op (0, 0, 1) een naar rechts van (-1, 0, 0).

Je hebt echt adjacent vertex informatie nodig, en dat heb je momenteel niet.

[ Voor 15% gewijzigd door .oisyn op 21-01-2010 01:59 ]

[Mischa_NL]

.oisyn schreef op donderdag 21 januari 2010 @ 01:56:
[...]

Dat werkt alleen voor de vertex op (0, 0, -1). Denk eraan dat de vertex op (1, 0, 0) een "naar rechts" heeft van (0, 0, 1) in world space, en de vertex op (0, 0, 1) een naar rechts van (-1, 0, 0).

Je hebt echt adjacent vertex informatie nodig, en dat heb je momenteel niet.

Ik heb vertices in object space, dus de sphere zijn coordinaten lopen als volgt ( 4 patches op X = omtrek)

code:

00 10 00 10 00 10 00 10 
 ---   ---   ---   --- 
| \ | | \ | | \ | | \ |
 ---   ---   ---   --- 
01 11 01 11 01 11 01 11

Dan is het toch zo dat de tangent van patch 1 als volgt is: T = 1-0 = 1 . Verdubel ik de verteices dan wordt het: 1-0.5=0.5 en 0.5 bij de 2e?


Andersgezegd: ik kan in de shader bepalen welke vertex aangrenzend is.

[ Voor 4% gewijzigd door Mischa_NL op 21-01-2010 02:09 ]

[.oisyn]

Mischa_NL schreef op donderdag 21 januari 2010 @ 02:06:
[...]

Ik heb vertices in object space, dus de sphere zijn coordinaten lopen als volgt ( 4 patches op X = omtrek)

code:

00 10 00 10 00 10 00 10 
 ---   ---   ---   --- 
| \ | | \ | | \ | | \ |
 ---   ---   ---   --- 
01 11 01 11 01 11 01 11

Nee dat is onzin, je beschrijft nu hoe de texture coordinaten zijn, niet de posities van de vertices zelf. Wat je uiteindelijk wilt is een matrix van world space (waarin je licht is) naar texture space (waarin je normals zijn). Die zijn dus afhankelijk van hoe de texture in de wereld gemapped is. Oftewel, je u en v coordinaten in world space (dit zijn je tangent en binormal vectors). Je u gaat in image space naar (1, 0), maar in world space is dat afhankelijk van de orientatie van je quad en de mapping van de texture op de quad. De quad bovenop de bol heeft een andere orientatie dan de quad aan de zijkant van de bol. Om die orientatie te bepalen heb je adjacent vertex info nodig.

Andersgezegd: ik kan in de shader bepalen welke vertex aangrenzend is.

Niet in de vertex shader, die info zul je dan mee moeten geven. Het kan wel in de geometry shader als je DX10 gebruikt.

[ Voor 4% gewijzigd door .oisyn op 21-01-2010 03:00 ]

[PrisonerOfPain]

.oisyn schreef op donderdag 21 januari 2010 @ 02:59:
Niet in de vertex shader, die info zul je dan mee moeten geven. Het kan wel in de geometry shader als je DX10 gebruikt.

Dat, of moeilijk gaan doen met R2VB, maar goed dan zit je vast aan een gelimiteerd aantal kaarten. Maar dat zit je met geometry shaders ook. Of 2 keer zoveel data naar de GPU streamen. Of object space normal maps gebruiken zodat je onder de hele tbn-matrix uit kunt komen.

[ Voor 16% gewijzigd door PrisonerOfPain op 21-01-2010 11:43 ]

[NC83]

Jullie vergeten wel dat dit project een XNA project is tot nu toe dus dan heb je al geen toegand tot DX10 of R2VB, zover ik weet.

[Mischa_NL]

PrisonerOfPain schreef op donderdag 21 januari 2010 @ 11:41:
[...]


Dat, of moeilijk gaan doen met R2VB, maar goed dan zit je vast aan een gelimiteerd aantal kaarten. Maar dat zit je met geometry shaders ook. Of 2 keer zoveel data naar de GPU streamen. Of object space normal maps gebruiken zodat je onder de hele tbn-matrix uit kunt komen.

Ik denk dat ik inderdaad maar voor Object Space maps ga. 'k Heb alleen geen idee hoe die te berekenen. Gewoon World Pos vertexen gebruiken?

[Mischa_NL]

Mischa_NL schreef op donderdag 21 januari 2010 @ 16:50:
[...]

Ik denk dat ik inderdaad maar voor Object Space maps ga. 'k Heb alleen geen idee hoe die te berekenen. Gewoon World Pos vertexen gebruiken?

En ik heb nog steeds geen idee, ik heb het geprobeerd ...
Ik snap niet hoe ik uit de height samples die ik heb de object space normal map kan genereren.

Ik heb het volgende:

5X float3 voor het berekenen van de normaal (Texcoords van omliggende pixels en eigen pixel).
5X float heightsamples
1x float3 met daarin de UpVector gespecificeerd.

Simpelweg de OS positie van de pixel als normaal nemen genereert zowaar een OS normal map voor een sphere!
Maar uiteraard is het geen mooie globe maar zijn er 'bergen'. Hoe kan ik die normaal van de bergen die nou combineren met de normaal van de sphere?
Of hoe genereer ik een OS normaal aan de hand van die vier aangrenzende pixels?

Normal mapping is echt niet mijn cup of thee lijkt he ...

/edit
Reeds gelukt... Normalen werden goed berekend ik berekende de vertex positie in object space niet goed... + en * lijken ook zo op elkaar

[ Voor 6% gewijzigd door Mischa_NL op 26-01-2010 18:32 ]

[Mischa_NL]

Na het bouwen van globale planetaire ringen ga ik nu beginnen aan het maken van de ringen als je jezelf erin bevind. Dit alles alá Infinity: The Quest for Earth. Ik heb al het een en ander doorgedacht maar een aantal dingen kom ik niet aan uit:

De ringen hangen om een planeet in en bestaan uit een 2d disc-vormige mesh. De mesh heeft een start punt vanaf het centrum van de planeet en daarnaast een diameter van de ring. totale diameter van de ene naar de andere kant van de mesh is dus: (start + diameter) * 2.
Nu wil ik als LOD systeem gebruik maken van een octree, omdat het een 3d veld betreft. De 2d mesh van de ring is goed genoeg omdat die dikte slechts een paar kilometer is. Kom je dichterbij dan geven de daadwerkelijke asteroiden-meshes het volume.
Het octree-centre komt dus op de plek van het centrum van de planeet, en heeft het de hele ring erin zitten. Ik subdivide de tree op basis van afstand tot een octree node, en deze tree heeft een fixed aantal levels (bv: max 10). Hoe dieper je komt hoe kleiner de extra gespawnde asteroiden worden: dieperin de ring -> meer detail!
De octree zorgt op deze manier dus voor LOD, omdat de 100.000en asteroiden nooit allemaal tegelijk te renderen zijn.

Het spawnen van de asteroiden is echter het probleem. Ik wil graag dat de asteroiden daadwerkelijk aan de hand van tijd op een bepaalde plek te vinden zijn. Een 'random' seed gaat dus niet werken. Als ik 1 asteroide rood maak dan wil ik kunnen uitrekenen waar deze zich op een gesteld tijdstip bevind! Het probleem is: hoe weet ik zonder dat ik de snelheid etc van de asteroid heb, in welk deel van de octree deze zich bevind!?

* Eerst had ik het idee om de gehele octree een draaiing mee te geven. Probleem hierbij is dat dan elke asteroide met dezelfde snelheid beweegt. Dit is iets wat ik zeker niet wil, omdat het geen realistisch beeld gaat geven.

En dit is waar ik vast zit:

* De planetaire ring heeft geen fixed aantal asteroiden, waarschijnlijk is de enige oplossing om een ´max´ aantal stenen per compleet octree level te geven en te zorgen dat dit altijd dezelfde asteroiden worden, adhv een pseudo/random nummer.
* probleem hierbij is: hoe kan ik weten dat als ik aan de hand van een pseudo-random nummer een asteroide genereer, dat deze zich daadwerkelijk binnen de bound van de octree bevind?
* Updaten: hoe update ik deze tree? Voor elke steen iedere frame/paar frames kijken of ze zich nog in de bounds bevinden: if not->kill asteroid.

Ik zal vast veel te moeilijk denken bij dit probleem...

[Mischa_NL]

Toch weer maar een keer een update, met wat vragen erbij...

Zo ongeveer een complete rewrite verder is er wel het een en ander veranderd. Normal mapping heeft een hogere resolutie dan de geometry.
Verder maak ik niet langer gebruik van instancing ivm precisie op de gpu.
Daarnaast zijn normal maps nu (toch!) in tangent space.

Alle maps worden op de gpu gegenereerd. Dat wil zeggen per patch: geometry map, normal map en diffuse map. normals en diffuse op 8X resolutie in low orbit en 32(!) in high orbit.




Verder heb ik nog steeds problemen met precisie op de gpu. Patches liggen tussen -1 en 1, en op die manier haal ik dus maximale precisie uit mijn floats. Toch heb ik helaas niet genoeg. bij diepere levels (+18) is het duidelijk dat de precisie in de noise functie op de gpu op is... Ik vraag me nog steeds af hoe ik dit ooit kan gaan fixxen...
Is het mogelijk om 2d perlin noise te 'tilen'? ik kan hier eigenlijk niet echt duidelijk een antwoord op vinden.
Zo ja kan ik de kleine details dmv een tileable map opleuken, en nog dieper dmv een normal map die correspondeert met de detail texture.

Nog enkele pictures in low orbit / ground level:

[PrisonerOfPain]

Mischa_NL schreef op maandag 03 mei 2010 @ 23:44:

Is het mogelijk om 2d perlin noise te 'tilen'? ik kan hier eigenlijk niet echt duidelijk een antwoord op vinden.
Zo ja kan ik de kleine details dmv een tileable map opleuken, en nog dieper dmv een normal map die correspondeert met de detail texture.

Gegeven een noise-functie (of in mijn geval een noise-texture) werkte deze functie bij mij prima on de noise te tilen. Als je de noise op de GPU genereert kun je de tex2D aanroepen gewoon vervangen voor de noise-functie met de bijbehorende xy/uv coordinaten.

C:

float tiledNoise(sampler2D noise, float2 uv, float2 scale){
    float w = scale.x;
    float h = scale.y;
    
    uv = fmod(uv, scale);
    
    float t = (
        tex2D(noise, uv)                         * (w - uv.x) * (h - uv.y) +
        tex2D(noise, float2(uv.x - w, uv.y))     * uv.x       * (h - uv.y) +
        tex2D(noise, float2(uv.x - w, uv.y - h)) * uv.x       * uv.y +
        tex2D(noise, float2(uv.x, uv.y - h))     * (w - uv.x) * uv.y
    ) / (w*h);
    
    return t;
}

[ Voor 6% gewijzigd door PrisonerOfPain op 04-05-2010 01:45 ]

[.oisyn]

Wat natuurlijk gewoon een bilinear filter is . Overigens wil je nog steeds zorgen dat je uv coordinaten rond de 0/1 liggen.

[Mischa_NL]

.oisyn schreef op dinsdag 04 mei 2010 @ 11:42:
Wat natuurlijk gewoon een bilinear filter is . Overigens wil je nog steeds zorgen dat je uv coordinaten rond de 0/1 liggen.

Ik ben aan het proberen geweest om na een bepaalde diepte in de tree niks nieuws meer te genereren maar heightmaps van parents te samplen en deze linear te filteren. Klopt echter niet aan de randen. point filter werkt perfect. Dit is zeker omdat linear filteren aan de rand niet correct gebeurd? moet ik een extra pixel toevoegen?

[.oisyn]

Je hoeft geen extra pixel toe te voegen, maar je moet wel samplen tot aan de buitenste pixelcentra van de texture en niet verder. Ik weet even alleen niet uit m'n hoofd op het centrum van 1 texel nou op (0, 0) of op (0.5, 0.5) ligt. Wel dat DirectX voor framebuffers (schrijven) het ene gebruikt en voor textures (lezen) het andere .

.edit: volgens mij liggen texel centra gewoon in het midden. Als je map 32 pixels groot is, dan wil je dus ook maar samplen tussen 0.5/32 en 31.5/32 ipv tussen 0 en 1.

[ Voor 20% gewijzigd door .oisyn op 05-05-2010 02:10 ]

[Mischa_NL]

.oisyn schreef op woensdag 05 mei 2010 @ 02:05:
Je hoeft geen extra pixel toe te voegen, maar je moet wel samplen tot aan de buitenste pixelcentra van de texture en niet verder. Ik weet even alleen niet uit m'n hoofd op het centrum van 1 texel nou op (0, 0) of op (0.5, 0.5) ligt. Wel dat DirectX voor framebuffers (schrijven) het ene gebruikt en voor textures (lezen) het andere .

.edit: volgens mij liggen texel centra gewoon in het midden. Als je map 32 pixels groot is, dan wil je dus ook maar samplen tussen 0.5/32 en 31.5/32 ipv tussen 0 en 1.

Geprobeerd inderdaad. in de VS map ik de position als volgt:

code:

    // Half pixel offset for correct texel centering.
    In.position.xy -= 0.5;
    
    // Viewport adjustment.
    In.position.xy /= ViewportSize;
            
    In.position.xy *= float2(2, -2);
    In.position.xy -= float2(1, -1);
    
    Out.position = float4(In.position.xy,1,1);
    Out.TexCoord = In.Tex;

position word dan: [-1, 1] + halfpixel.
texcoords zijn [0-1].

Het leek me dat dit dan correct moet zijn, maar om de een of andere reden is het dat niet...

Moet ik wellicht de position [-1,1] houden en texcoords [0+halfpixel, 1 - halfpixel maken] ?

Ik zal eens gaan proberen!

[NC83]

Ja je moet de texcoords aanpassen en niet de posities

[.oisyn]

Feitelijk maakt dat niet zoveel uit. Wat je uiteindelijk wilt bewerkstelligen is dat de samplepunten waarop voor de pixels in de framebuffer de pixelshaders worden uitgevoerd uitgelijnd zijn met de samplepunten van je texture fetches. Dus ofwel je schuift je fetches op, ofwel je positie met tegengestelde richting.

[Mischa_NL]

.oisyn schreef op woensdag 05 mei 2010 @ 17:17:
Feitelijk maakt dat niet zoveel uit. Wat je uiteindelijk wilt bewerkstelligen is dat de samplepunten waarop voor de pixels in de framebuffer de pixelshaders worden uitgevoerd uitgelijnd zijn met de samplepunten van je texture fetches. Dus ofwel je schuift je fetches op, ofwel je positie met tegengestelde richting.

Dat vermoedde ik al inderdaad... Toch doet linear filtering om de een of andere reden niet wat ik wil. Wellicht een bug ergens anders in mijn code. ik ga op zoek!

[Mischa_NL]

Toch heb ik nog een vraag mbt pixel texel mapping!

Wat ik ervan begrijp is dat als je rendered in screenspace (dus RTT, dmv een quad) dat je dan de texture coordinaten moet aanpassen OF de positie coordinaten.

Dat wordt dan:

code:

//pos
new Vector2(-1 - half, 1 + half), new Vector2(1 - half, -1 + half),

//of voor tex
new Vector2(-1 + half, 1 - half), new Vector2(1 + half, -1 - half),

Nou denk ik dat ik het begrijp: als ik deze offset pak en bv een texture lookup doe, dan kloppen nu de coordinaten met de pixels.

Echter wat nou als ik de tCoords niet gebruik voor een TexLookup maar als input voor een noise functie?!
Dan klopt ineens die positie niet meer omdat tcoord = 0 niet geld voor pixel = 0, maar voor pixel = -0.5...

Verander ik dit vervolgens dan klopt het NOG niet... Ik snap er werkelijk niets meer van en google helpt me ook al niet!

Effectief de vraag:

Wanneer moet ik die halve pixel shiften? Moet dat ALTIJD als ik in screen space render? Of moet dit alleen als ik in deze rendering een texture lookup doe uit een andere texture?

Ik krijg de coordinaten op geen enkele manier perfect gematched

topic titel zou wel gewijzigd mogen worden opzich. Of nieuw topic aanmaken?

[ Voor 3% gewijzigd door Mischa_NL op 20-05-2010 21:54 ]

[.oisyn]

Waar het om gaat is wanneer je pixelshader wordt uitgevoerd. Laten we voor het gemak even denken in hele coordinaten (dus een 16 texels brede texture loopt van 0 tot 16, en eveneens zo voor de framebuffer). Als jij een quad tekent van (0, 0) tot (16, 16) dan runt je pixelshader voor elk hele coordinaat in DX9. Dus x=0, x=1, x=2, etc., t/m x=15. Gebruik je ook bijbehorende texturecoordinaten van (0, 0) tot (16, 16), dan worden die ook gewoon geinterpoleerd van 0 tot 16, wat betekent dat je bij x=0 ook u=0 hebt, en bij x=1 ook u=1, etc.

Het probleem is echter, als jij precies de texel linksboven in het texture wilt samplen, dan heb je (0.5, 0.5) als coordinaat nodig. Echter, de geinterpoleerde texture-coordinaat is bij de eerste pixel (0, 0). Schuif je je texture coordinaten naar rechtsonder - dus de texturecoordinaten van de quad lopen van (0.5, 0.5) tot (16.5, 16.5). En nu ik dit opschrijf besef ik me ook ineens waar de fout vandaan komt, zie jij 'm ook? Ja, dat was 16.5, en niet 15.5, zoals ik in mijn originele post suggereerde. Natuurlijk, de laatste sample, x=15, zal een u=15.5 hebben. Maar je quad loopt tot 16 (of minder, als het maar meer is dan 15), dus moet je texture ook zo ver doorlopen anders wordt hij gestretcht. Een andere optie is natuurlijk om je quad een halve pixel naar linksboven te bewegen, zoals je eerder al geprobeerd had.

Maar goed, dat geldt dus voor texture sampling. Wat jij voor je noise generator nodig hebt ligt natuurlijk aan je eigen wensen. De vraag die je moet stellen is: waar ligt precies het linkerbovenste noise sample, op (0, 0) of op (0.5, 0.5)?

Zie ook http://msdn.microsoft.com/en-us/library/bb219690(VS.85).aspx.
(Let er trouwens wel op dat dit met D3D10 veranderd is - daar wordt een pixel in de framebuffer wel op (0.5, 0.5) gesampled, zoals in OpenGL)

[ Voor 10% gewijzigd door .oisyn op 21-05-2010 00:39 ]