using VFACE in surface shader

Graphics Shaders & Materials
1

I have this shader code:

    Cull Off
      
   CGPROGRAM
   #pragma surface surf Standard fullforwardshadows vertex:myvert
   // Use shader model 3.0 target, to get nicer looking lighting
   #pragma target 3.0
   half _BackfaceExtrusion;

       sampler2D _MainTex;

struct Input {
        float2 uv_MainTex;
        float3 worldPos;
        float myface : VFACE;      
    };

    half _Glossiness;
    half _Metallic;
    fixed4 _Color;
  

    void myvert (inout appdata_full v, out Input IN) {
        //float3 viewDir = normalize(ObjSpaceViewDir(v.vertex));
        //float dotProduct = dot(v.normal, viewDir);
        //if(dotProduct<0) v.vertex.xyz -= v.normal * _BackfaceExtrusion;
        UNITY_INITIALIZE_OUTPUT(Input,IN);
        if(IN.myface<0) v.vertex.xyz -= v.normal * _BackfaceExtrusion;
    }

    void surf(Input IN, inout SurfaceOutputStandard o) {
        fixed4 c = tex2D(_MainTex, IN.uv_MainTex) * _Color;
        o.Albedo = c.rgb;
        // Metallic and smoothness come from slider variables
        o.Metallic = _Metallic;
        o.Smoothness = _Glossiness;
        o.Alpha = c.a;
    }
    ENDCG

I simply want to get the backfaces extruded using VFACE.
But I am always getting VFACE = 0 using the above code.
Could anyone give me a hint on this?

Flickering on HoloLens 2 but not in editor
2

VFACE (or SV_isFrontFace) can be used in the fragment shader (when surf is called), or written to by a geometry shader in DX10+. The value does not yet exist in the vertex shader as it gets calculated as part of the rasterization process which is between the vertex shader and the fragment shader, so trying to access it in “myvert” which is called during the vertex shader is going to just be either uninitialized memory or more likely always zero.

You’ll need to do a dot product against the view direction and surface normal, though unless you’re vertices are all unwelded and your vertex normals are aligned with the surface (ie: flat shaded) the results will be quite ugly. On something like a sphere you’ll get several vertices that are back facing and front facing within a single triangle causing it to get warped rather than having a clean “front” and “back” mesh. To do it properly would require using a geometry shader so you can have access to all 3 vertices of each triangle and computing a surface normal or enforcing the normal extrusion across all vertices of a triangle evenly. But Unity’s surface shaders do not support geometry shaders, so it would mean a fully custom vertex / fragment shader or hand modifying the generated code from a surface shader.

1 Like
3

Thanks. That is just what I was missing.

Basically I am just adding a #pragma multi_compile feature to my shader.
I was using VFACE so far, because I needed facing directiont on the fragment function level.
Now I need the facing direction it on the vertex function level - I guess I should define my custom variable based ondotProduct = dot(v.normal, viewDir) and then use it also in my fragment function to avoid the VFACE limitations.
Are there any advantages on using VFACE over dot product against the view direction and surface normal that I would be loosing?

4

A minor, but important correction, that’s a dot product of the vertex normal and the view direction. Even when done in the fragment shader it’s still an interpolation of the vertex normals, this is often referred to as the surface normal, but it isn’t actually. The true surface normal for each tri is a single constant direction across the entire tri, where as each of the vertex normals might be facing any direction.

Basically it’s possible (and quite likely on anything smoothed) that as a tri turns away from the camera some of the vertex normals of that one tri might have normals that are facing away from the camera and some that are facing towards. It’s even possible for all of the vertex normals to be facing away when the tri itself is still facing the camera, and vice versa. In short a dot product is actually a poor approximation of if a face is actually facing the camera or not as there’s little guarantee of the vertex normals matching the facing. So you might have all or just some of a tri being treated as flipped in the shader when it isn’t.

If you want to know if a tri is facing the camera, use VFACE.
If you want to know if a vertex normal is facing the camera, use a dot product. Also if you need a smooth transition, like a fresnel, you need to use the dot product too since VFACE is binary, even if it’s exact value differs between APIs (some do 0 or 1, some do false or true, some do -1 or 1, and some do 0x0000 or 0xFFFF)

3 Likes
5

Means it could be said that vertex normals include smoothing data, VFACE does not; i.e. if there is no smoothing the results should be the same, right?

6

Should be very close, yes.

One other advantages to using VFACE is bandwidth and shader performance. To use the dot product you need to pass the normal and view direction from the vertex shader to the fragment shader. That’s 6 floats ( actually 8 unless you do careful data packing) and there is a cost to to transferring that data. Additionally you have to do the dot product in the shader which is a few extra instructions. If your shader isn’t already needing / using that data elsewhere then it’ll be cheaper to use VFACE since it’s always being calculated during rasterization and is available to the fragment shader.

2 Likes
7

SV_isFrontFace with pixel shader example:

Shader "Face"
{
    SubShader
    {
        Pass
        {
            Cull Off
            CGPROGRAM
            #pragma vertex vertex_shader
            #pragma fragment pixel_shader
          
            void vertex_shader (inout float4 vertex:POSITION,inout float2 uv:TEXCOORD0)
            {
                vertex = UnityObjectToClipPos(vertex);
            }
          
            float4 pixel_shader (float4 vertex:POSITION,float2 uv:TEXCOORD0, bool IsFacing:SV_IsFrontFace) : SV_TARGET
            {
                return IsFacing ? float4(1,0,0,1) : float4(0,0,1,1);
            }
            ENDCG
        }
    }
}

VFACE with surface shader example:

// https://github.com/przemyslawzaworski/Unity3D-CG-programming/blob/master/surface_shaders/vface.shader
Shader "Vface"
{
    SubShader
    {
        Cull Off
        CGPROGRAM
        #pragma target 5.0
        #pragma surface SurfaceShader Standard
      
        struct Input { float IsFacing:VFACE; };

        void SurfaceShader( Input i , inout SurfaceOutputStandard o )
        {
            float4 color = (i.IsFacing>0) ? float4(1,0,0,1) : float4(0,0,1,1);
            o.Emission = color.rgb;
            o.Alpha = color.a;
        }

        ENDCG
    }
}
2 Likes
8

You can use VFACE in a vertex fragment shader as well. The compiled shader will use the appropriate semantic for the platform and translate it to a -1.0 or 1.0 value.

For example, a shader written like this:

fixed4 frag (half facing : VFACE) : SV_Target
{
    ...

Will for DX11 produce a compiled shader equivalent to this:

fixed4 frag (bool IsFacing : SV_IsFrontFacing) : SV_Target
{
    half facing = IsFacing ? 1.0 : -1.0;
    ...

Also I wanted to clarify a bit posted previously:

Really, all modern shader languages expect to be a bool like SV_IsFrontFacing. OpenGL’s equivalent gl_FrontFacing, Metal’s front_facing, and Vulkan’s FrontFacing are all bool values. Beyond that is really just the internal differences in how different shader languages handle bool values. You should be safe using SV_IsFrontFacing in your shaders regardless of the platform you compile to. Only the original Direct3D 9 VFACE was a -1 or 1 value, and Unity no longer supports D3D9.

Unfortunately Surface Shaders are stuck with VFACE since the feature was added when Unity still supported D3D9, so you’re stuck with an extra shader instruction if you don’t need that -1 or 1 float.

5 Likes
Double-sided shader with other half with semi-alpha.
9

Is there a way to use VFACE in vertex shader?
And it seems the lightmap only can be fetch correctly for the front face. Is there a way to let back face pick up lightmap correctly, when back face is facing the light and front face is back to the light?

10

No. I thought my previous posts in this thread already covered that pretty well, but I’ll go into more detail as to why that doesn’t even make sense.

VFACE (or SV_IsFrontFacing) is whether or not the triangle being rendered is facing towards or away from the camera. The vertex shader has no knowledge of the triangle it might be used with at all, not to mention the facing of that triangle won’t be known until all vertex shaders for all 3 vertices of that triangle have finished running. And since you’re presumably wanting to use it in a still running vertex shader, that’s not exactly possible. Even ignoring that, each vertex may be used as the corner of any number of triangles in the mesh. It is possible (though highly unlikely outside of some fairly simple shapes) that one vertex is reused by every triangle in the mesh. So which “facing” would the vertex shader even use?

So, to reiterate for the third or fourth time in this thread:

You cannot use VFACE in the vertex shader. The closest you can get is by doing a dot product against the vertex normal with the view direction. But but that will never 100% match VFACE even in the best case of a flat shaded mesh were each vertex is only used with one triangle and the vertex normal matches the triangle facing.

3 Likes
11

Hmm I got an invalid vs_4_0 input semantic ‘VFACE’

struct Input
{

float IsFacing : VFACE;

float4 vertex : POSITION;

float3 normal : NORMAL;

UNITY_VERTEX_INPUT_INSTANCE_ID
};

Wondering about clash with something else in there.