Vertex Shader [SOLVED]

Started by
18 comments, last by RobM 15 years, 8 months ago
Tim's idea for using instancing is a good one - I should imagine it'll work nicely on paper, but do be careful about performance testing it. A bit outdated now, but I know there were some earlier SM2/SM3 GPU's that weren't quite so instancing-friendly, especially with unaligned strides or something like that.

Quote:...This would take up too much memory though, as my terrain at the highest LOD level is made up of 4096 65x65 patches.
Have you considered a streaming architecture? I've had success with a crude implementation years back and am currently toying with some code to take advantage of multithreading for this. You can potentially reduce the in-memory working set down to an acceptable level whilst effectively making the landscape unbounded in size...

Quote:Original post by RobMaddison
It would appear to me that my engine somehow things I'm tryin to use the fixed function pipeline. Is there a way to tell which I'm using? I'm currently using the DXUT libraries just to get things up and running. If there's a "SetDeviceToUseFVF" or something similar I can just do a search for it in my code.
There is no such call unfortunately - that'd just make things far too easy [cool]

I'd recommend grabbing a single-frame capture using PIX and stepping through it to the offending Draw**() call. You should be able to pull up the device state at that point in time and find out what its basing that message on.

It's common enough in complex D3D apps to think you're setting pipeline state in a certain way only to find a leaked state ruining the party. PIX will tell you exactly what state the device is in and if this isn't what you expect then you've got an application bug - you could be lucky and find that the message is due to something like this.

The flipside of course is that the state matches what you're expecting and you've either proven that your app isn't setting the correct state or you simply cant do what you're trying to do - any of the 3 outcomes being quite useful to know!

hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

Advertisement
Well, I'm getting close...

My vertex declaration looks like this:

D3DVERTEXELEMENT9 declTerrainXYZ[]={  {0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0},  {1, 0, D3DDECLTYPE_FLOAT2, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TEXCOORD, 0},  D3DECL_END()};


The inputs to my vertex shader are:

V_To_P SimpleVertexShader( float3 Position : POSITION, float2 yy : TEXCOORD){  V_To_P Output = (V_To_P)0;  float4 newPos = float4(Position.x, yy.x, Position.z, 1.0);  Output.Position = mul(newPos, xViewProjection);  ...  return Output;}


and a snippet of my c++ code:

hr = DXUTGetD3DDevice()->SetVertexDeclaration(<as above>);hr = DXUTGetD3DDevice()->SetStreamSource(0, <VertexBufferWithD2DXVECTOR3Verts>, 0, sizeof(D3DXVECTOR3));hr = DXUTGetD3DDevice()->SetStreamSource(1, <VertexBufferWithHeightFloatPairs>, 0, sizeof(float) * 2);hr = DXUTGetD3DDevice()->SetIndices(<regular indices>);


I am getting the correct triangles drawn, but the heights are not being picked up by the second stream, i.e. in the shader yy.x (and yy.y) is coming through as zero and the vertex buffer definitely contains heights.

Any ideas folks?

Thanks
Shouldn't the first line of the shader have TEXCOORD0 not TEXCOORD? Other than that I don't know.
inherently interactive - my game design blog
Hi Tim

I did try that one and it didn't work. What I did do is pad the second stream out to D3DXVECTORS and supply it as a POSITION1 field which worked perfectly, but defeats the object of my exercise. So I know the shader and drawing code is correct, it's just I need to find a way to pass in 1 float as the second input.

Thanks
Rob
Hmm, thats odd. I can't see anything obviously wrong with the code you posted, and the method works as I've used it myself, I'm not really sure what to suggest, sorry.

One thing I did notice is that you are using D3DDECLTYPE_FLOAT2 when the docs say that you should be able to use D3DDECLTYPE_FLOAT1 with D3DDECLUSAGE_TEXCOORD, which would halve the memory you need. Of course thats only true if it actually works.
inherently interactive - my game design blog
Hi Tim

Yes, I've tried it with just about every float including D3DDECLTYPE_FLOAT1 and nothing seems to work other than D3DDECLTYPE_FLOAT3 and POSITION(1). I'm now reinvestigating my vertex buffer creation just to be 100% sure it contains the height values. It's something I've checked and analyised twice before, but I'm running out of ideas!

Thanks
Don't pass an FVF to CreateVertexBuffer, pass 0. This may make D3D complain if the FVF and your declaration are different. Other than that, the only reason I could see it complaining is that you haven't actually activated your effect before you draw. I have several shaders where my position is short2, and it works fine.

If you aren't using a shader, and have fixed pipeline vertex processing, your inputs have to be what the fixed pipe wants. For a shader you can input whatever you want. Since you have a shader, all I can think of is that it's not actually being used, and the fixed pipeline is complaining at you.
Does the card that you're trying to run this on have hardware vertex processing? Did you enable it with D3DCREATE_HARDWARE_VERTEXPROCESSING?

If I remember correctly software vertex processing is much more restrictive on what you can put in the declarations.
Quote:Does the card that you're trying to run this on have hardware vertex processing? Did you enable it with D3DCREATE_HARDWARE_VERTEXPROCESSING?

If I remember correctly software vertex processing is much more restrictive on what you can put in the declarations.


I haven't explicitly set that flag (D3DCREATE_HARDWARE_VERTEXPROCESSING), I'll check - it certainly looks to be using hardware vertex processing (it's extremely fast).

Quote:
Don't pass an FVF to CreateVertexBuffer, pass 0. This may make D3D complain if the FVF and your declaration are different.


I do pass zero in the FVF param of CreateVertexBuffer.

Quote:Other than that, the only reason I could see it complaining is that you haven't actually activated your effect before you draw. I have several shaders where my position is short2, and it works fine.


The actual drawing of the vertices is working fine with regard to the effect/shader. I am passing in untransformed world terrain vertices and the shader is transforming them to my viewport perfectly. The following line in my shader:

Output.Position = mul(newPos, xViewProjection);


Proves that theory. The terrain grid draws perfectly well, it's just flat.

One thing I've been musing over for the last few minutes is whether the elements I put into my vertex buffer need to be in a struct with an x accessor. It works with two streams of D3DXVECTOR3 types - I'm wondering whether my second vertex buffer should be filled with something like:

struct oneFloatVertex
{
float x;
};

At the moment, I just fill it with float types. I'm wondering if the vertex shader needs something with an accessor in order to use the yy.x accessor I've used in my shader.

Thanks for all the help so far guys.
Thanks to everyone for their help on this, but I've figured it out (and how annoyingly simple is the fix!).

Essentially, the vertex buffers are fine but this declaration:

D3DVERTEXELEMENT9 declTerrainXYZ[]={  {0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0},  {1, 0, D3DDECLTYPE_FLOAT1, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TEXCOORD, 0},  D3DECL_END()};


Needs to be this in the vertex shader signature:

V_To_P SimpleVertexShader( float3 Position : POSITION, float4 Ypos : TEXCOORD){  V_To_P Output = (V_To_P)0;  float4 newPos = float4(Position.x, Ypos.x, Position.z, 1.0);  Output.Position = mul(newPos, xViewProjection);  ...  return Output;}


Notice that the Ypos TEXCOORD input type is a float4, not a float1 as you'd expect. I read somewhere that a D3DDECLTYPE_FLOAT1 expands to float4(x, 0.0, 0.0, 1.0).

Now working perfectly.

Thanks again

This topic is closed to new replies.

Advertisement