Not enough TEXCOORDn attributes. Any way to free up some used by Unity?

Unity Engine
1

Background:
I’ve been commissioned to write a series of Unity 3 Surface Shaders that take advantage of Valve’s Radiosity Normal Mapping technology. On top of this, I also needed to add Detail Mapping + Normal-Mapped Environment Mapping. All this is intended to be used with Unity 3’s deferred lighting pipeline.

Problem:
As per the artist’s request, I have tried to add support for Unity’s built-in texture Tiling Offset options. As a result, I end up with an Input struct that looks like this:

struct Input 
 {
        float2 uv_MainTex;
        float2 uv_DetailMap;
        float2 uv2_LightMap0; 
        float3 worldRefl;
        INTERNAL_DATA
};

This raises the error that _ShadowCoord is trying to use TEXCOORD index 8, which is invalid. Is there any way I can disable this, so I can continue to use my current setup? Or is it hardwired, and thus unchangeable?

Any help would be most appreciated. Thanks.

2

You can reuse UV’s but it means that you won’t get the nice scaling / unity texture set up. If I’m in this situation I just say screw it and pass the raw mesh UV’s through the vertex shader and use them in the shader editor. If I do need any scaling ect I just pass them in as properties and do the panning and scaling manually. It’s not as nice as the builtin system but saves interpolators!

Here is a snippet that should help:

			struct Input {
				float4 meshUV;
			};


			void vert (inout appdata_full v, out Input o) {
				o.meshUV.xy = v.texcoord.xy;
				o.meshUV.zw = v.texcoord1.xy;
			}
			

			void surf (Input IN, inout EditorSurfaceOutput o) {
				o.Albedo = 0.0;
				o.Normal = float3(0.0,0.0,1.0);
				o.Emission = 0.0;
				o.Gloss = 0.0;
				o.Specular = 0.0;
				o.Alpha = 1.0;
				o.Albedo = (IN.meshUV.xyxy);
				o.Alpha = 1.0;
			}
3

Well yes, that would be the easiest solution, and that is what I initially used. However, the artist requested that I try to find a way to use the built-in panning and scaling UI. The really annoying part is that I can get it to work with any combination of two of the features I listed in my first post. The problem only occurs when I try to use all three features at once.

So should I assume I will just have to use properties and manually apply the transformations?

4

Yes. Using internal data adds a lot of interpolators (it’s pretty much the TBN matrix). There is a limit to how many interpolators sm2.0 and sm3.0 can support. Have you tried changing to sm3.0 you will get 2 extra interpolators that way.

5

Sadly, I already added “#pragma target 3.0” for some of my earlier features, due to the instruction limits. Even with that, it still isn’t enough. :frowning: