Creating a new LODFade node that exposes the LODFade values

[bencloward]

Please read the Contributing guide before making a PR.

• Read the Graphics repository & Yamato FAQ.

Checklist for PR maker

• Have you added a backport label (if needed)? For example, the need-backport-* label. After you backport the PR, the label changes to backported-*.
• Have you updated the changelog? Each package has a CHANGELOG.md file.
• Have you updated or added the documentation for your PR? When you add a new feature, change a property name, or change the behavior of a feature, it's best practice to include related documentation changes in the same PR. If you do add documentation, make sure to add the relevant Graphics Docs team member as a reviewer of the PR. If you are not sure which person to add, see the Docs team contacts sheet.
• Have you added a graphic test for your PR (if needed)? When you add a new feature, or discover a bug that tests don't cover, please add a graphic test.

---

Purpose of this PR

Exposes the LODFade parameters to Shader Graph, which would otherwise only be available using a custom code node.

---

Testing status

Created sample shader graph assets in both HDRP and URP and varified that the correct LOD Fade data is being passed from the new node into the graph.

---

Comments to reviewers

There is a bit of a debate about whether or not this node is actually needed. HDRP has a check box "Support LOD CrossFade" in the graph inspector. With this box checked, LOD cross fading is implemented "under the hood" and no implementation is required in Shader Graph. URP also has this feature on the road map to implement. This means that exposing this data for the Shader Graph would only be useful to those who want to create a custom implementation of the lod cross fading feature. The presence of the node may confuse new users, who, seeing it, might assume that lod cross fading requires the feature to be implemented in Shader Graph rather than just simply checking the box to turn it on.

Here's a video that shows how to implement the feature without this node - using the custom code node instead:
https://www.youtube.com/watch?v=lcHXSELuwXY

Here is Amplify's version of the node:
http://wiki.amplify.pt/index.php?title=Unity_Products:Amplify_Shader_Editor/LOD_Fade

Here's a subgraph I created with an implementation of LOD cross-fading

[github-actions]

Hi! This comment will help you figure out which jobs to run before merging your PR. The suggestions are dynamic based on what files you have changed.
Link to Yamato: https://unity-ci.cds.internal.unity3d.com/project/902/
Search for your PR branch using the search bar at the top, then add the following segment(s) to the end of the URL (you may need multiple tabs depending on how many packages you change)

Shader Graph
/jobDefinition/.yamato%252Fall-shadergraph.yml%2523PR_ShaderGraph_trunk
Depending on your PR, you may also want
/jobDefinition/.yamato%252Fall-shadergraph_builtin_foundation.yml%2523PR_ShaderGraph_BuiltIn_Foundation_trunk
/jobDefinition/.yamato%252Fall-shadergraph_builtin_lighting.yml%2523PR_ShaderGraph_BuiltIn_Lighting_trunk

Depending on the scope of your PR, you may need to run more jobs than what has been suggested. Please speak to your lead or a Graphics SDET (#devs-graphics-automation) if you are unsure.

[esmelusina]

Hey Ben-- were you looking to take this PR out of draft, or were you going to bundle this node with a few others in a bigger PR later?

[bencloward]

I created this before I fully understood how the feature worked. In HDRP, there's a just a check box that enables the LOD fading feature for the material. And URP has a plan to implement it in a similar way. This node exposes the LOD fade values to the graph, but I'm not sure that's going to be useful if people can just turn it on and use it as a feature without requiring graph implementation.

[sebastienlagarde]

If we were willing to support such a node for the CROSS Fade feature, then we should do the following step.

Look at cross fade PR for URP:
#6754

users will need an option to say they want to use the shader graph version. And in the code calling the pattern function :
https://github.com/Unity-Technologies/Graphics/pull/6754/files#diff-58236d12bbbd040a1431ffdcae5f82dddde1c382febdb3dbe5a04f21532d9740R36
then you could return the version generated by the shader graph.

So it imply:

• the node can only be used when LOD Cross fade is active. i.e this variant: LOD_CROSS_FADE is enabled.
  Generated code must be encompass in #ifdef LOD_CROSS_FADE #endif.
• to have an option system (HDRP don't, so HDRP will need to add one if we want this) to select shader graph version or builtin version
• to have a specific input in the master node which is: cross lod pattern. If we don't the users may be quickly confuse. users will need to output the dither pattern in alpha clipping BUT this dithering pattern must be call only when LOD_CROSS_FADE variant is enbabled and it will not prevent our own code to be executed so we will need to handle this as well.

Overall my personal opinion is that we could do proper support by adding a "cross lod pattern" input on master node and restrict this LOD fade node to be used only with it. Add an automatic switch to use shader graph path instead of regular one if we detect there is an input in this field. BUT is it worth it? Do we really want do offer such an option? This could prevent any futher optimization of the LOD cross fade system were we could move it to a uniform stencil pass (like unreal) that don't rely on having individual variant. So from my point of view we should not expose "internal" parameters of the system. My two cents :)

[esmelusina]

Do we know where unity_LODFade is defined? Is it always set/defined for all unity shaders?

[sebastienlagarde]

Unity_LODFade is define in the UnityPerDraw.
This is currently a good question. I guess it is always define in the context of shader graph (even for procedural geometry) as the other values like unity_SHAr. Doesn't mean the content of the value will make sense.

[esmelusina]

We don't have a way to guarantee that this node will handle situations where it isn't present-- but that's a separate problem. LGTM.

[esmelusina]

We don't have a way to guarantee that this node will handle situations where it isn't present-- but that's a separate problem. LGTM.

[bencloward]

I'm going to close this and not add it. My biggest issue with it is that the incoming data is packed in a somewhat non-intuitive way, so it's fairly complex to set up a graph to unpack it correctly to be able to use it. When users can just check a box and get great results, I don't see much point to giving them this and confusing them. I don't think there is a lot of benefit to being able to create custom cross fading effects.

[Dawie3565]

Hi ben
could you share copy of this with me to explore the idea with custom function in ASE

[bencloward]

I can send it to you on slack, but I don't know who you are.

[Dawie3565]

sorry yes i just sent you my contact info to your Unity forum profile :)