Bug LOD shader to reduce popping doesn't fully works (Documentation bug)

Heyo

I've created a subgraph to manage my LOD's like so

Plugged it in to Alpha and Clip threshold respectively which with combination with the LOD group component setup with a "Cross Fade" fade mode and fade transition of 0.2 for each LOD like so

It works.. well half works..
The issue is that while the LOD objects fade out nicely, they still pops in without fade.
Like in this demonstration:

As you can see, as soon as LOD0 starts to fade out, LOD1 immediately pops in without fading.
Which doesn't reflect what's the manual says

https://docs.unity3d.com/Manual/cla...for the next LOD level:,-Cross-fading between

If there is something I did wrong, it's probably in the shader.. someone knows and can help?
Thanks

 

Bug case 1408617

 

Maybe try to test it in play mode. The editor view doesn't really reflect trutly the LOD transition from my experience. But I'm not entirely sure about it.

 

Thanks!
Actually the GIF above was made in play mode.
I have also created a fresh new URP project, same results.. it is also how it behave in builds.
Also build that project in 2021.2.8, same results.

 

I think I had similar issues before. It was a long time ago tho. My solution was to use cross-fade with animated cross-fade mode on. That will make the cross fade stick at a 2s interval. The interval can be changed I believe.

 

I think the issue is beyond that.
In animated cross-fade mode the "next" LOD still pops..

 

Try using the CopySign function, this handles the issue you're seeing and is also used in the SpeedTree shaders. Oddly enough, not needed in the Built-in RP.

This is a snippet from the function I'm using for LOD crossfading:

Code (CSharp):

1. #if LOD_FADE_CROSSFADE
2.     float hash = GenerateHashedRandomFloat(screenPos.xy * _ScreenParams.xy);
3.     float sign = CopySign(hash, unity_LODFade.x);
4.    
5.     clip(unity_LODFade.x - sign);
6.     #endif

 

Thanks looks like a nice workaround but I got it!
The documentation for LOD's is not intuitive at all. By reading this portion it was clear to me that the x component can only be 0-1. (with the assumption that it may corelates to alpha)

But after lot more digging I found this post

(and also your suggestion of using the sign of x) and got it to work as intended!

So looks like it is a documentation bug.
And I did done things wrong but only because I followed it.

I moved the code to a file and attached it.