Sign in to follow this  
  • entries
    455
  • comments
    639
  • views
    422027

TLM : The Journal Spam

Sign in to follow this  
_the_phantom_

81 views

Having had a look at PIX and after some brief fighting with it out of which I emerged victorious I can now say with confidence that my texture is indeed black (as in zero in all the channels) for my source data.

For giggles I set the texture to all white (0xFF on all channels) via the clear function and, despite PIX confirming that the texture is indeed white, the same output colour pattern can be seen.

So, the problem lays in one of two places as far as I can gather;

1) my code for setting up the textures as streams.
The problem with this is it's like 2 or 3 lines of code and I've copied them word for word (vars excluded of course) from the ATI docs.

2) Shaders.
My guess is I haven't understood the vertex decl stuff correctly and I'm sending trash down the pipeline. Of course, this doesn't explain why I'm seeing the patterns I do which is a puzzle indeed...

For refernce, the image produced is as follows;

The shader code which produces it is as follows;

struct VS_INPUT
{
float2 position : POSITION;
// float3 position : POSITION;
float2 TexCoord : TEXCOORD0;
float4 Normal : NORMAL;
float Height : TEXCOORD1;
};

struct VS_OUTPUT
{
float4 position : POSITION;
float2 TexCoord : TEXCOORD0;
float4 vPosition : TEXCOORD1;
float3 Normal : NORMAL;
};

VS_OUTPUT DefaultVS(in VS_INPUT v)
{
VS_OUTPUT o = (VS_OUTPUT)0;

// o.position = mul(float4(v.position.x, v.Height, v.position.y, 1.0f), mWorldViewProj);
o.position = mul(float4(v.position.x, 0.0, v.position.y, 1.0f), mWorldViewProj);
// o.position = mul(float4(v.position, 1.0f), mWorldViewProj);
// o.vPosition = o.position;
o.vPosition = float4(v.Height, 0.0f, 0.0f, 0.0f);
// o.vPosition = float4(v.Normal.xyz, 0.0f);
o.TexCoord = v.TexCoord.xy;
o.Normal = v.Normal.xyz;

return o;
}

float4 FinalRender(in VS_OUTPUT p) : COLOR
{
// Perform the final render
// Using PS Warn Lighting
/* float3 PixelToLight = float3((pLightPosition - p.vPosition).xyz);
float3 Normal = normalize(p.Normal);
float3 Dir = normalize(PixelToLight);

float warnValue = pow(dot(Dir, PixelToLight), WarnExponent);

return (warnValue * dot(Normal, Dir) * float4(1.0,1.0,1.0,1.0) / pow(length(PixelToLight), 2.0));
*/


return float4(p.vPosition.xyz, 1.0);
}



With a Vertex Decl of

D3DVERTEXELEMENT9 decl[] =
{
{ 0, 0, D3DDECLTYPE_FLOAT2, D3DDECLMETHOD_DEFAULT , D3DDECLUSAGE_POSITION , 0 }, // Position (X & Z)
{ 0, 8, D3DDECLTYPE_FLOAT2, D3DDECLMETHOD_DEFAULT , D3DDECLUSAGE_TEXCOORD , 0 }, // Texture co-ordinates
{ 1, 0, D3DDECLTYPE_FLOAT4, D3DDECLMETHOD_DEFAULT , D3DDECLUSAGE_NORMAL , 0 }, // Normal information
{ 2, 0, D3DDECLTYPE_FLOAT1, D3DDECLMETHOD_DEFAULT , D3DDECLUSAGE_TEXCOORD , 1 }, // Height map information
D3DDECL_END()
};



If anyone can see a glaring error in all that which would possibly cause that output then I'd be happy to be told about it [smile]
Sign in to follow this  


3 Comments


Recommended Comments

Your use of the POSITION semantic as input into the pixel shader shouldn't work (unless there's some special R2VB thing).

Only ps_3_0 has access to position data and that's via a 2D VPOS semantic, not the POSITION semantic the vertex shader uses.

Using undefined semantics gives you undefined results - which would cover what you're seeing.

If you really need the position data, use another TEXCOORD or look into using ps_3_0 and VPOS.

hth
Jack

Share this comment


Link to comment
It looks to me like your offsets in the vertex declaration are not correct. The second element of each of the elements should be the offset from the beginning of the total structure. See HERE for more details.

I am pretty sure that will fubar your vertex data - and it should lead to some form of a modulus operation on the input to the pipeline, which could lead to a repetitive pattern like you are seeing. Hope this helps!

EDIT: sorry - you are using multiple streams, so the offsets you have look correct...

Share this comment


Link to comment
How big is your texture? I've had ATI driver problems with textures less than 4 pixels wide (albeit with their OpenGL driver)

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now