Question Depth/Intersect and vertex movement in shader producing strange results

Hey there, i'm trying to create an intersection shader based off a few tutorials, and the implementation works nicely until I bring in some vertex movement ( in my case, for waves in water ).

This is the desired effect :


This is what happens when I implement vertex movement.


This is the shader in question:



Thank you!

 

Yes, I have the same issue in LWRP.
In HDRP this is a non-issue (at least with HDRP Graphs), so I presume it has to do with how these pipelines render the frame... Sadly don't know the solution to this.
Be sure to post the answer, if you'll ever solve it yourself

 

I am also experiencing this issue. Hopefully, this can be resolved soon!

 

I am also experiencing the same issue when I tried to do an intersection shader to achieve a foam effect in the water. When I bring in waves, I have the same undesired effect. I have also went through several tutorials and threads and from what I read, most think that this is an issue with the way Shader Graph works currently.

Is there anyone that knows if this can be resolved somehow, and what direction one would try to take, or is it really a problem with Shader Graph?

 

My 2cts so you don't look for a solution forever.
I can confirm it's a "problem" with ShaderGraph, more precisely with the shader code generated by the master node.
If you know how to read a bit of HLSL, you can right clic on the master node -> show generated code. Then you'll see in the vertex shader that your vertices are being displaced, but then what's being read in the pixel shader (using the Position or Screen position node) is the vertex position before displacement. I haven't seen a node that read the correct, post-displacement position yet.

The problem being in ShaderGraph itself, the only way for you to fix it would be to copy the ShaderGraph (and probably LWRP) package in your asset folder instead of using the package directly, then figure out how it generates the shader in the C# / HLSL files and fix the bug.
If you go this way, then be prepared for a lot of trouble when updating Unity, as you will need to manually port the changes they did in LWRP / ShaderGraph package to your version. It's doable, but a LOT of trouble.

 

Thank you a lot for the informative response, I really appreciate it.

Unfortunately for me that would be way too time-consuming. Time which would be better put elsewhere. I know how to read a bit of HLSL, but if I knew how to write it, I wouldn't even need ShaderGraph. This defeats the purpose of ShaderGraph, which was to easily implement Shaders with the visual graph editor.

I noticed you wrote (problem) in quotation marks, which probably means it is not really a problem but intended to work that way, so that probably means this will not be fixed by Unity, or a proper graph will not be added in the future? I have tried the latest alpha and beta, and I still have the same unwanted visuals there, which means there is no fix for this or the removed "depth" from Clear Flags(Background) and camera stacking in LWRP..

I have been following Unity for a long time, and have been fiddling around with some prototypes, but in the end I got pretty disappointed by it. They market it as something that it is clearly not and by the time you realize that you would have invested a lot of time in it...

Thankfully, I didn't invest that much time in the project I have started building, so an alternative path for me would be to either switch back to the legacy rp and fork out money for Amplify (which is pretty expensive), or just switch to Unreal Engine, which is pretty FREE, and seeing how the Mordhau developers dropped Unity after having issues with it, which issues were resolved just by importing their assets into UE..

It's kind of sad :\ , because I really liked the Workflow which Unity had to offer previously..

Cheers

 

I don't know anything about what Unity devs are working on. I wrote "problem" because when you look at the code, it's clearly working as intended at the moment. It doesn't mean it's necessarily hard to fix or that they will never fix it; only that it's not just a ";" missing somewhere, it just wasn't intended to work this way.

To be honest, I know this much about this specific issue because I've fixed it in an upcoming version of my plugin (ShaderGraph Essentials). I'm actually working on a simple water shader to showcase the problem and that the bug is fixed. I don't have an ETA yet, but it should be soon™. Also even if I wanted I can't give you the code to fix this, as it relies on everything else in the plugin (you have to use my master nodes instead of Unity ...etc).

Cheers,

 

Yeah, alright. Makes sense. I wasn't asking for a missing semicolon or for you to provide me any code, just directions, and yours were helpful for me to understand where the issue lies.

As I was having several other issues in addition to this one, I decided to ditch Unity completely for now and restart my project using Unreal Engine 4, and I have to say, after I imported the assets and applied basic materials, without doing ANYTHING at all, they look freaking amazing, and the performance when I imported my terrain was so much better than Unity's LWRP! My only issue is that I am rusty with C++ as I haven't used it for several years since uni, but It will benefit me more in the long run than spending countless hours trying to modify LWRP/ShaderGraph.

Still, Unity is better than UE4 in some aspects, and it's great for prototyping. I also see what Unity Devs are doing, and I am sure that when HDRP gets a production version and ShaderGraph gets built upon with more features, it will be even more flexible, better documented and just a better platform.

Thank you again for the comprehensives responses, I really appreciate them!

 

Glad I could help, good luck with your projects!

 

Thanks for the discussions all! I've since adopted a new look and feel for my water and will cross my fingers that something comes up in the future. Hoping someone from the Shadergraph team could chime in since many are having this "issue".

 

Just to chime in here, I also had experiences with this issue a few months ago. Every month or so I check back on the forum to see if this absolutely critical issue has been fixed yet, which it doesn't look like it has.

I ended up implementing a node which would simply give me the position within the triangle (represented by 3 weights which would add up to 1). I had to duplicate my vertex displacement to plug into my custom node. This gave me the "real" position of each fragment after vertex displacement, which let me get around this issue.

This issue is worse than just depth detection issues by the way. This mean you can not calculate your own lighting in any shader with vertex displacement. Looking at preview versions of shader graph, it really doesn't look like they're making any progress. Very unfortunate

 

Yeah, I downloaded a bunch of betas and alphas to experiment with that. They simply don't care at this point, because "ItS tHe WaY iTs MeAnT tO WoRk"

Seriously, do yourself a favor and try Unreal Engine 4. The time you spend bashing your head against the wall with issues like this will be rewarded greatly over there. I've learned a ton since I ditched unity and have already ported a couple of materials that work perfectly there : - ). No more waiting for Unity Devs!

P.S. UE4 C++ is a beast

 

Problem persists..

 

Have submitted a bug report for this Case 1184489

 

Here’s a temporary fix, my dudes, courtesy of @Cianilux:
https://twitter.com/romanpapush/status/1172479571108802561?s=21

 

Rather than editing the source code, I'm going to try following these two examples as they seem to have cracked it also
https://answers.unity.com/questions/1587077/how-to-use-scene-depth-node-in-shadergraph.html

 

Actually, your fix was easier! Thankyou

 

Awesome! Thank you for reporting!

 

This is great news, we are now onto the issue of Foveated Rendering not working with UniversalRP on mobile VR headsets - is this also something your team could look into please?

(Case 1184851) UniversalRP - Oculus Quest/Go Fixed Foveated Rendering not working in URP/LWRP

 

Is there an update for how to get this fix? I am having ththe problem of only the top setion of my models are showing the white (like in your example) and nothing below at all. Do I need to update unity? Or something else?

 

We will need to wait for UniversalRP 8.0 to be pushed to the available package manager version, from what I understand the main git repo changes need to be tested and prepared for the packages available for Unity release versions in the package manager. @LandonTownsend may be able to inform us when this will be available?

 

Sounds acceptable to me! Thanks for the quick update

Small question: not sure if I have something else wrong or not in my scene. Just like the images shown above I have the weird planes above my models that are above water, but I do not have anything below the water showing. The picture has both. Is it possible I have something else set up wrong or are other people getting the same bug too? It shows the weirdness on yop of the object, but doesn't show anything on the bottom.

 

I managed to fix the problem of not showing the depth part. Apparently just needed to check a box in the inspector.

Problem I have now is that I can't control the color of anything below the water (and still shows above the water too) does anyone know how to change the color?

 

Thankyou, I have spoken to some of the XR and SRP guys here at Unity Unite Copenhagen today about it too and they are glad.

Not intending to hijack are this thread, other people waiting may be having this issue also. We are waiting for a fix on the Fixed Foveated Rendering for Oculus Quest on URP which is still a total show-stopper for us:

(Case 1184851) UniversalRP - Oculus Quest/Go Fixed Foveated Rendering not working in URP/LWRP

Many thanks for your replies, our voices are being heard.