UNITY_PROJ_COORD? where is the explanation?I cannot find it

.

 

The definition is in HLSLSupport.cginc:

Code (csharp):

1.  
2. #if defined(SHADER_API_OPENGL)  !defined(SHADER_TARGET_GLSL)
3. #define UNITY_BUGGY_TEX2DPROJ4
4. #define UNITY_PROJ_COORD(a) a.xyw
5. #else
6. #define UNITY_PROJ_COORD(a) a
7. #endif
8.  

 

thank you,Marty

 

Thank you. I was having trouble finding this, and the documentation only said that it returns the given value (as is) most of the time. That documentation literally replaced one question with two. When does it actually do anything? And, when it does do something, what does it do?

 

If you look at the shader code from Unity 5.0 through Unity 2018.2 for that line, you'll see this in HLSLSupport.cginc:

Code (CSharp):

1. #if defined(SHADER_API_PSP2)
2. #define UNITY_BUGGY_TEX2DPROJ4
3. #define UNITY_PROJ_COORD(a) (a).xyw
4. #else
5. #define UNITY_PROJ_COORD(a) a
6. #endif

That

SHADER_API_PSP2

define refers to the PlayStation Vita (which was referred to as the PlayStation Portable 2 before release). It had that extra code to work around some quirks of that hardware's graphics API and how it handled projected texture coordinates. It was the last device Unity supported that still had the issue they were trying to work around.

That issue was the texture sampling function

tex2Dproj()

, which was used for things like sampling a screen space texture, had two different versions. One that took float4 UVs, and one that took float3 UVs. On some old hardware, only one of those worked correctly, the float3 input, so there was code to try to ensure the float3 version was used for those older devices. In both cases the xy value was divided by the last value in the vector, either the z or the w, then used as normal texture UVs. On old hardware this divide was handled in the hardware itself, and it was faster to let the hardware do it than do it in the shader.

Today the issue is moot. Basically no hardware implements it in hardware anymore, and

tex2Dproj(_tex, uv.xyzw)

and

tex2D(_tex, uv.xy / uv.w)

compile to identical shader code. This would be true even if Unity hadn't overridden the

tex2Dproj

functions with the later

tex2D

form in the cginc files to begin with. The reason why Unity overloads the original function is many modern graphics APIs don't even bother implementing a "proj" version of the texture sampler, let alone one that takes a float3 uv. So for their shader cross compiling it's easier to just remove any usage of the original function entirely.

Since Unity 2018.3 that part of the cginc now looks like this:

Code (csharp):

1. #define UNITY_PROJ_COORD(a) a

Yeah, that's it. Any reference to the PSP2 has been almost entirely expunged from the code base since Unity dropped support for it. And with that there aren't any platforms that need that special handling anymore.


So to answer your question, today it does nothing. There is no reason to use it and it only exists for backwards compatibility.

 

I was literally half way through writing up a question about this when I stumbled across this and it answered my question so thanks @bgolus. BTW I have to say in my journey of learning shaders you have answered a good quarter of my questions @bgolus so thank you