Jump to content

  • Log In with Google      Sign In   
  • Create Account


GrayScale

Member Since 23 Nov 2007
Offline Last Active Today, 02:51 AM
-----

Posts I've Made

In Topic: DX9 Deferred Shading: I have a couple problems that need solving

05 April 2014 - 09:27 PM

I switched to the 32 bit depth buffer that did not work. After further investigation I discovered that there's z-fighting or depth fighting going on. Some of the color from the other side of the cube is winning the depth test some how. I've tried some of the more basic methods for resolving the problem like adjusting the far and near planes. That did not work. So far only adjusting the perspective's  field of view from D3DX_PI/4.f to D3DX_PI/3.f works but that alters the shape of the model abit too much. Any solutions? I'm going to try enabling backface culling next and adjusting the models winding order.

 

Edit:

Okay so yeah applying back face culling was the solution. Thanks for the help Phil T.

 

Can anyone answer the second problem, about the model not rendering when the  camera sits directly above it, along the y-axis?


In Topic: DX9 Deferred Shading: I have a couple problems that need solving

02 April 2014 - 08:54 PM

The surface formats are all 4 8bit channels

if( FAILED(graphics->device()->CreateTexture( w, h, 1, D3DUSAGE_RENDERTARGET,
        D3DFMT_A8R8G8B8, D3DPOOL_DEFAULT, &g_colorRT, 0 ) ) )
        return false;

    if( FAILED(graphics->device()->CreateTexture( w, h, 1, D3DUSAGE_RENDERTARGET,
        D3DFMT_A8R8G8B8, D3DPOOL_DEFAULT, &g_normalRT, 0 ) ) )
        return false;

    if( FAILED(graphics->device()->CreateTexture( w, h, 1, D3DUSAGE_RENDERTARGET,
        D3DFMT_A8R8G8B8, D3DPOOL_DEFAULT, &g_depthRT, 0 ) ) )
        return false;

    if( FAILED(graphics->device()->CreateTexture( w, h, 1, D3DUSAGE_RENDERTARGET,
        D3DFMT_A8R8G8B8, D3DPOOL_DEFAULT, &g_lightRT, 0 ) ) )
        return false;

I've also tried 4 16bit channels, D3DFMT_A16B16G16R16. but that same line is there. Here is the artifact again carrying over to the light shader. The light is on one side of the model and the camera is on the oppiste side pointing back at the model. So the screen should be completely black.

 

kz6n.png

I've tried using PIX but only manged to get it working once. I'll have another look at it.


In Topic: DX9 Deferred Shading: I have a couple problems that need solving

02 April 2014 - 05:34 PM

Phil T, Thanks for reply.

 

The image above is a snap shot of the model rotating along the y-axis, sitting at the origin.

here's the setup code:

D3DXMATRIX    origin, world, view, projection, worldViewProjection, inverseView, rotationX, rotationY;

    D3DXMatrixIdentity( &world );
    D3DXMatrixIdentity( &origin );
    D3DXMatrixTranslation( &world, 0, 0, 0 );
    D3DXMatrixRotationX( &rotationX, SMYUTI_DegreeToRadian( 0.f ) );
    D3DXMatrixRotationY( &rotationY, SMYUTI_DegreeToRadian( ang+=( 50.f/fps ) ) );
    D3DXMatrixPerspectiveFovLH( &projection, D3DX_PI/4.f, float(SCREEN_WIDTH)/float(SCREEN_HEIGHT), 1.f, 500.f );
    D3DXMatrixLookAtLH( &view, &CameraPosition, &D3DXVECTOR3(0,0,0), &D3DXVECTOR3(0,1,0) );
    D3DXMatrixInverse( &inverseView, 0,  &(view*projection) );

    world                = origin * rotationX * rotationY * world;
    worldViewProjection    = world * view * projection;

Also when you say point sampling, you mean this, right:

dev->SetSamplerState(0, D3DSAMP_MINFILTER,D3DTEXF_POINT);
dev->SetSamplerState(0, D3DSAMP_MAGFILTER,D3DTEXF_POINT);
dev->SetSamplerState(0, D3DSAMP_MIPFILTER,D3DTEXF_POINT);
dev->SetSamplerState(0, D3DSAMP_ADDRESSU, D3DTADDRESS_CLAMP);
dev->SetSamplerState(0, D3DSAMP_ADDRESSV, D3DTADDRESS_CLAMP);
dev->SetRenderState( D3DRS_MULTISAMPLEANTIALIAS , FALSE );

Everything in the g-buffer looks fine except in the normal buffer of the g-buffer. I know for fact this is where the problem is at. So I too am assuming the issue is with the way that I store the normal data. I read somewhere that you could store data In view space to futher reduce the artifacts. I tried this and failed? Would you know how to, and if so, care to elaborate?


In Topic: Need help solving GJK woes

19 April 2013 - 12:31 PM

Yup, you're right about the minus sign, though. Anyhow, the code works fine now and all the bugs are gone. I will work on the optimization on a later date. Thanks for the help.


In Topic: Need help solving GJK woes

17 April 2013 - 11:15 PM

You do not mention how you actually calculate the normal vectors. If you have x=[x1, x2] the normal could be calculated as nx=[x2, -x1].

 

Wow! awesome, I thank you. Weeks of frustration summed up by something so trivial... a single minus sign. Does this have to do with the whole left-handedness and right-handedness thing?

This is how I calculated the normal before:

SMYUTI_Vector    normal()
{
        return SMYUTI_Vector( -this->y, this->x, this->z );
}

Then I swapped the minus sign just as you suggested and voila, no bugs.

Care to explain why this is? I read in the book, Mathematics and Physics for Game Programming that it does not matter in which component you place the minus sign when calculating the normal, clearly it does. Also what optimizations can be made? I thought the optimization was check outside of edge AB and edge AC, and/or vertex A, If not there then the origin is enclosed. Is it that both sides of each of the edges are being checked? If so, I figured it was for orientation, so that you know which direction you're facing. Nevertheless, Thanks Again for the help.
 


PARTNERS