Pages: [1]   Go Down
  Print  
Author Topic: HLSL Semantic question - TEXCOORD[n]  (Read 18881 times)
February 27, 2012, 02:55:27 pm
I have an output struct similar to this:

struct VSOut
{
   float4 position    : POSITION;
   float3 normal   : NORMAL;
   float4 uv0      : TEXCOORD0;
   float3 uv1        : TEXCOORD1;
   float3 uv2      : TEXCOORD2;
   float3 eye_vec    : TEXCOORD3;
   float3 overlay   : TEXCOORD4;
   float3 test      : TEXCOORD5;  
   float3 colour   : COLOR0;
};


(1)
When HLSL docs refer to TEXCOORD[N] how can I determine the max number of
TEXCOORD elements that are available for use?

(2)
Is there any danger that using too many struct elements could prevent the shader from working correctly on some hardware?

(3)
Is the [N] max number:

  (a) Hardware dependent?
  (b) Shader model dependent
  (c) both of the above
  (d) none of the above

E.g. on a Laptop with an NVidia QuadroFX 3600M I can compile TEXCOORD15 successfully,
but not TEXCOORD16; (Compilation fails with: Error X4502: invalid input semantic TEXCOORD16).
February 27, 2012, 06:07:50 pm
That would be (b). Shader model 3.0 supports up to 16 TEXCOORD interpolators. You can of course also COLOR interpolators, but they are also limited and they interpolate in a different way when AA is enabled. (Look for centroid sampling.)
February 27, 2012, 06:34:04 pm
Perfect!

Thanks.
February 28, 2012, 11:57:05 am
Perfect!

Thanks.

I'm not really sure the texcoords interpolate differently. As far as I know the sampler just interprets the incoming coordinates with half a pixel offset (so 0,0 is in fact the top left of a pixel and not the center as you would expect).  I think the incoming coordinates themselves are interpolated just like positions, normals and color.
February 28, 2012, 12:00:21 pm
Note that you can just pack your coordinates. There are 16 float4 registers you can use which is a total of 64 values. You can use them to transfer 4 matrices for example. With complex shaders (especially if they have shadow map coordinates in them) we often have to cut up the vectors and divide them over the 16 float4 values.

If you do your rendering deferred this problem is largely solved because each shader does not implement things like shadow mapping.
February 28, 2012, 04:11:16 pm
I'm not really sure the texcoords interpolate differently. As far as I know the sampler just interprets the incoming coordinates with half a pixel offset (so 0,0 is in fact the top left of a pixel and not the center as you would expect).  I think the incoming coordinates themselves are interpolated just like positions, normals and color.
The difference in interpolation is very small, but the TEXCOORD semantic is interpolated to the center of the pixel. The COLOR semantic is interpolated to the average of the centers of the visible AA samples.

Normals don't exist separately for interpolation, since you have to pass those through a TEXCOORD or COLOR semantic. I assume the position is interpolated like TEXCOORD to the center of the pixel. So, COLOR is the one interpolated (a very little bit) differently from the others.
February 28, 2012, 06:01:16 pm
The difference in interpolation is very small, but the TEXCOORD semantic is interpolated to the center of the pixel. The COLOR semantic is interpolated to the average of the centers of the visible AA samples.

Normals don't exist separately for interpolation, since you have to pass those through a TEXCOORD or COLOR semantic. I assume the position is interpolated like TEXCOORD to the center of the pixel. So, COLOR is the one interpolated (a very little bit) differently from the others.

So, is this only when AA is enabled? I never noticed any difference. I must say I never use the COLOR semantic except for outputting color or grabbing the vertex info.
February 28, 2012, 06:11:25 pm
So, is this only when AA is enabled? I never noticed any difference. I must say I never use the COLOR semantic except for outputting color or grabbing the vertex info.
Yes, only with AA enabled this can make a difference. It's usually not visible. You could compare some value with the two different interpolations to determine whether AA has been applied though. I also never use the COLOR semantic actually.
February 28, 2012, 06:25:34 pm
Yes, only with AA enabled this can make a difference. It's usually not visible. You could compare some value with the two different interpolations to determine whether AA has been applied though. I also never use the COLOR semantic actually.

By the way you should have received an email from me concerning the test release for Quest3D5 check it out because there are several improvements in the shader department.

You can do instancing now for example Cheesy Also new is the way the compiler reports warnings and we increased the size of the compiler window.

This is a closed beta by the way so don't ask for access everyone! The final will be released soon enough.

Instancing works by creating a second ObjectData which contains an array of matrices so each instance has it's own matrix.  It's the fastest way to render many objects at once. Although you have only one matrix you can pack imformation to store more than just a location. For example we stored position and a heading so we had 12 values left for other information like color or an animation offset.
February 29, 2012, 01:27:37 am
Instancing works by creating a second ObjectData which contains an array of matrices so each instance has it's own matrix.  It's the fastest way to render many objects at once. Although you have only one matrix you can pack imformation to store more than just a location. For example we stored position and a heading so we had 12 values left for other information like color or an animation offset.

Sounds great!!  Will you be able to add/change/remove matrices in run time?
February 29, 2012, 10:13:11 am
Sounds great!!  Will you be able to add/change/remove matrices in run time?

No you can't because it's essentially a second vertex buffer containing the unique data for each instance. So, you will need to recreate this buffer when you want to change it. It works with a for-loop and with each iteration you add one instance to the list. Works great for drawing things like rocks, grass and trees though.

Remember that any communication between the GPU and CPU dramatically reduces performance. This means that when you want to render pieces of grass for example you can generate the instances with an initialization step so you can tweak the number of grass objects but during rendering you should avoid operations like this. To dynamically render grass objects around the camera it's best to calculate their positions in the vertex shader.

In your application you should create an OOInstancelist containing all the instances and then create a "generatemesh" function or something like that which cycles trough your OOInstancelist and updates the mesh.
February 29, 2012, 10:27:47 am
Is there any example of this instancing pipeline in RC? I did not find any.

ali-rahimi.net
February 29, 2012, 10:34:26 am
No you can't because it's essentially a second vertex buffer containing the unique data for each instance. So, you will need to recreate this buffer when you want to change it. It works with a for-loop and with each iteration you add one instance to the list. Works great for drawing things like rocks, grass and trees though.
Ah, ok. At first I assumed it would be a NaturePainter to hold the instances, but I guess that is not the case. Doesn't matter that much for me.

Are the primary and secondary ObjectData linked in any way or can you mix them however you want? (Draw multiple primary ObjectData's with the same secondary matrix list.)

And the biggest question of course. What is the speed difference? The instancing technique we had access to before was only useful for objects up to about 1000 triangles. I've also tried it for drawing simple grass planes, but it was faster to just send one huge block of grass to the GPU. Can I expect this technique to also improve performance when drawing 100.000 objects of 2 triangles or 2 objects of 100.000 triangles?
February 29, 2012, 10:51:10 am
Would the instancing being done through HLSL or do we have a set of channels for that (like nature painter)?

It seems time to start learning HLSL...
February 29, 2012, 10:56:11 am
Would the instancing being done through HLSL or do we have a set of channels for that (like nature painter)?

It seems time to start learning HLSL...

In HLSL you won't notice anything about HLSL. For the vertex shader it's just like having one huge mesh containing all instances. Sometimes you want HLSL to be aware of the instances though so we store an instance index for each instance. In the vertex shader we read this index so we know which index we are dealing with.
Pages: [1]   Go Down
  Print  
 
Jump to: