# .fx HLSL Semantics problem

This topic is 4310 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey, So, I'm working on some HLSL using the .fx system and I've run into a bit of a problem. I fully admit I'm kinda hacking this together and learning as I go so I'm probably missing some base knowledge somewhere so any help someone can give would be appricated [smile] The problem seems to be it doesn't like the same samantic being used for two different sized vars as input and output. My struct def looks like this;
struct VS_INPUT
{
float2 Position : POSITION;   // only reading X&Z
float2 TexCoord : TEXCOORD0;
float4 Normal : NORMAL;
float Height : PSIZE;         // Y comes from here
};

struct VS_OUTPUT
{
float4 Position : POSITION;   // Complains about this being invalid
float2 TexCoord : TEXCOORD0;
float3 Normal : NORMAL;
};


The error it gives me is; "./TLM Modules/shaders/FullShader.fx(47,20): error X4502: invalid input semantic 'POSITION': Legal indices are in [1,15]" If I change the second POSITION to POSITION1 then it compiles there BUT throws an error later saying "error X4541: vertex shader must minimally write all four components of POSITION" Height comes from a R2VB so I can't fold that in with the X&Z co-ords as things stand. The FvF I'm using for it looks thusly;
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_FLOAT3, D3DDECLMETHOD_DEFAULT	, D3DDECLUSAGE_NORMAL	, 0	},	// Normal information
{ 2, 0, D3DDECLTYPE_FLOAT1, D3DDECLMETHOD_DEFAULT	, D3DDECLUSAGE_PSIZE	, 0	},	// Height map information
D3DDECL_END()
};


With streams 1 and 2 coming from two R2VB targets. Any clues as to how I should hook this all up? (for reference the two shaders which use the output struct are;
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, 0.0f), mWorldViewProj);
o.TexCoord = v.TexCoord;
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.Position).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));
}



##### Share on other sites
Your code looks correct, not sure why you're getting an error.

A few suggestions I can make:

1) Try using POSITION0 as the semantic, though I always just use POSITION and it works fine.
2) Try a different name for the Position component. I'm looking at FXComposer's default material code, and they specifically name the output OUT.hPosition and the input IN.position. IIRC, FX Composer colors Position (with a capital P) blue, so it might be reserved. Also note they use different names for the input and output, though I doubt that's the problem.
3) Try using float3 for the input position. Float2 should really work, but maybe that's it.

Also, which SDK version are you using? The Dec '06 SDK included a new compiler, so it might be acting a bit funny in some places.

EDIT: For a reference, here's the vertex structure in the default FX Composer material, which compiles with both the old compiler and the new one. Maybe you could try it to see if you still get an error (indicating something else is wrong).
//------------------------------------struct vertexInput {    float3 position				: POSITION;    float3 normal				: NORMAL;    float4 diffuse				: COLOR0;};struct vertexOutput {    float4 hPosition		: POSITION;    float4 diffAmbColor		: COLOR0;    float4 specCol			: COLOR1;};

2nd EDIT: Almost forgot, I'm not sure if the PSIZE semantic is valid when not drawing Point Sprites. I'd recommend, for compatibility reasons, just marking it as a texcoord instead.

Hope this helps.

##### Share on other sites
Cheers for the reply [smile]

1. I probably should have pointed out I'd already tried that as a solution.. my bad

2. tried renaming to 'position', same problem. It doesn't seem to be a name, but just in case I change it to 'vposition' in the output struct, still the same problem.

3. Tried float3 (had to change both position and uv as they are in an interleaved buffer and I didn't fancy the headache of sorting that out), no change there either [sad]

I'm indeed using the 'dec 06 SDK, I'm also compiling as vs_3_0 and ps_3_0 targets (X1900XT gfx card so it has the caps for what I'm doing).

Hmmm, would that work? I'm passing in a float and I thought that texcoord stuff would require 2 fp values not just one?

##### Share on other sites
Quote:
 Original post by phantomI'm indeed using the 'dec 06 SDK, I'm also compiling as vs_3_0 and ps_3_0 targets (X1900XT gfx card so it has the caps for what I'm doing).

Shader Model 3 has extra limitations on semantics. Have a read in the SDK, under "Shader Model 3" (in the index), the section called "Match Semantics on vs_3_0 and ps_3_0 Shaders". It's a bit messy, but could explain your problems.

Also, is there any special reason you're not using SM2 for this? I can't see anything that isn't supported in SM2, and using that would remove the limitations SM3 has (not to mention being able to run on more cards).

Quote:
 reply to edit2:Hmmm, would that work? I'm passing in a float and I thought that texcoord stuff would require 2 fp values not just one?

Texcoords can be any length, 1 to 4.

Hope this helps.

##### Share on other sites
OK, I tried the renaming, it gave the same error.
I even tried changing the semanitic for 'Height' to TEXCOORD1 and it still bombed out (this was with the rest of the changes in place as well).

##### Share on other sites
Quote:
Original post by sirob
Quote:
 Original post by phantomI'm indeed using the 'dec 06 SDK, I'm also compiling as vs_3_0 and ps_3_0 targets (X1900XT gfx card so it has the caps for what I'm doing).

Shader Model 3 has extra limitations on semantics. Have a read in the SDK, under "Shader Model 3" (in the index), the section called "Match Semantics on vs_3_0 and ps_3_0 Shaders". It's a bit messy, but could explain your problems.

Switching all the shaders to SM2.0 (vs_2_0 and ps_2_0) gives a whole new error report [sad]
ERROR: Failed to compile 'FullShader.fx':------ Begin Error Listing ------./TLM Modules/shaders/FullShader.fx(47,20): error X4502: invalid ps_2_0 input semantic 'POSITION'./TLM Modules/shaders/FullShader.fx(49,18): error X4502: invalid ps_2_0 input semantic 'NORMAL'./TLM Modules/shaders/FullShader.fx(47,20): error X4502: invalid ps_2_0 input semantic 'POSITION'./TLM Modules/shaders/FullShader.fx(258,25): ID3DXEffectCompiler::CompileEffect: There was an error compiling expressionID3DXEffectCompiler: Compilation failed------ End Error Listing ------

Quote:
 Also, is there any special reason you're not using SM2 for this? I can't see anything that isn't supported in SM2, and using that would remove the limitations SM3 has (not to mention being able to run on more cards).

Ah, I (nievely it seems) assumed as SM3.0 is more capible it would be a better target *sighs*
And extra cards isn't an issue; this is a degree research project which will probably never see light of day outside of my college and anyone who happens to download it [grin]

Quote:
 reply to edit2:Hmmm, would that work? I'm passing in a float and I thought that texcoord stuff would require 2 fp values not just one?

Texcoords can be any length, 1 to 4.

Hope this helps.[/quote]

Hmmm, the SDK docs could be a little clearer about that. I admit I made a few assumptions but matching FvF types with semantic types seemed to make sense to me... ah well...

##### Share on other sites
You can't use POSITION in the pixel shader. You can copy the position into a TEXCOORD instead if you need it.

##### Share on other sites
OK, I've made a few changes:

- Back to SM3_0
- Added an extra float4 vPosition : TEXCOORD1 to the output struct
- referenced that in the PS instead of position

That all seems to compile, huzzah! [grin]

Thanks to sirob for his help here and on IRC and to the AP as well [grin]

On to the next problem!

1. 1
Rutin
33
2. 2
3. 3
4. 4
5. 5

• 13
• 9
• 9
• 9
• 14
• ### Forum Statistics

• Total Topics
633330
• Total Posts
3011385
• ### Who's Online (See full list)

There are no registered users currently online

×