Excellent tutorial, thank you! If anyone else wants to use this effect with an Orthographic camera, I have a solution. I'm pretty new to shaders, so there's probably a better way, but this worked for me. you will want to tweak your Camera's Far value, and maybe its distance from the scene-otherwise you might get some strange clipping. I ended up moving my Camera out to z=100, and setting its Far to 130 (my camera is tilted at 30 degrees but I assume the similarity of these numbers is a coincidence). Experiment with your camera's near, far, and position, and eventually you should find some values where the whole shader mesh and scene are visible.
Thanks for the tutorial, great stuff! I read that it's best to avoid "if" statements inside shaders and instead favor using equivalent mathematical functions. Something about wavefronts in parallel processing. Basically when every fragment executes the same code, then everything can keep running in parallel (as one wavefront). But if some fragments have different conditions, then it slows down the whole parallel schtick (creating new wavefronts)
Interesting, I'd not heard it put that way before but it makes sense to me and I'll keep that in mind for future tutorials/revisit this effect with that in mind. Thanks for the tip! 👍
Hello, this doesn't work when there is semi transparent objects in the scene. Would you mind making a tutorial for passing a viewport texture as a shader parameter to achieve a similar result but also show semi transparent objects ? I'd be eternally grateful :)
Ooh... interesting, I didn't of that. That sounds like a fantastic improvement to the shader, let me add that to the top of my list of topics to look at. Thanks!👍
Okay, so it looks like this will end up being a quite involved project to get it to fully work properly (seemingly due to the way Godot handles rendering transparency? Still looking into that), but I did find in playing around that if you set the render priority to -1 for the post-processing material, it should render the semitransparent objects, but they won't interact with the shader. Hopefully that's enough to get you by for now while I try and find a better solution! 👍
@@wattinteractive Ohhh, nice! That could work for now. I'm doing fog of war post processing shader for my RTS game (video coming out soon) and I have a few semi transparent assets but they all belong to the player so they should all be in the visible area of the fog of war (no need to be affected by the shader) but in the future, enemy units/buildings might have some semi transparent objects that need to be hidden in the fog of war still. I've browsed through the Godot github and found a few changes in the pipeline that allow for post transparency screen capture. Hopefully they are merged soon. Thanks a lot for the brilliant temporary solution :)
Can't understand well the scaled depth variable and how i should tune the zFar and zEnd variable... what is its range? I'm trying to achieve a result similar to the one of the first part of the video, but what I'm looking for is a "color" from 0 to full white, where 0 is everything farther than X (or background) and white means distance 0, and I'd like to have it linear.. Is the formula provided linear? Many thanks
So, I'm having trouble understanding exactly what you're looking for with the effect, but to try and answer your questions: 1. Yes, the formula is linear. It's purpose is just to re-scale the value that is retrieved from the depth buffer into something with more human understandable numbers. 2. In theory, zNear should be the distance away from the camera the effect starts, and zFar is telling the equation how far away the "max" effect should be. My demo scene is very small so I didn't get the chance to fully test it. 3. Now, to get the effect I think you want, you'll need to read the screen texture (like I do in the pulse section) and then mix it with a white color using the scaled depth value. It would be something like: ----- vec4 original = texture(SCREEN_TEXTURE, SCREEN_UV); vec3 white = vec3(1.0); ALBEDO = mix(white, original.rgb, scaled_depth); ----- If I misunderstood what you're looking for let me know what I missed and I'll try and answer again.
@@wattinteractive thank you very much. I've been very busy so I could recheck everything only today. There are 2 issues to me, right now. 1 linear_depth isn't the distance it is negative! I think it is negative in your implementation too, because in your scaled_depth implementation you are multiplying for a negative factor (zNear - zFar). 2, I got the formula "right", since I make it work as intended in the preview, but running the project the shader show it pitch black. Here is my modified shader: shader_type spatial; render_mode unshaded; uniform float zNear = 2.0; uniform float zFar = 30.0; void vertex(){ POSITION = vec4(VERTEX, 1.0); } void fragment(){ vec4 original = texture(SCREEN_TEXTURE, SCREEN_UV); float depth = texture(DEPTH_TEXTURE, SCREEN_UV).x; vec3 ndc = vec3(SCREEN_UV, depth) * 2.0 - 1.0; vec4 view = INV_PROJECTION_MATRIX * vec4(ndc, 1.0); view.xyz /= view.w; float linear_depth = view.z; float scaled_depth = (zFar * zNear) / (zFar + (linear_depth * (zNear - zFar))); ///////////////// up to here it should be identical to yours/////////////// float inverted_depth = -linear_depth; // because I found that linear_depth is negative ///////// limit inverted_depthto b in range [zNear, zFar] if(inverted_depth > zFar) inverted_depth = zFar; else if(inverted_depth < zNear) inverted_depth = zNear; //////// end limiting // zNear < inverted_depth < zFar; if(SCREEN_UV.x < 1.0) ALBEDO = vec3(1.0-((inverted_depth-zNear)/(zFar-zNear))); //the formula I want to work. SINCE zNear < inverted_depth < zFar, IN THEORY SHOULD BE IN RANGE [0,1] if(SCREEN_UV.x < 0.55) ALBEDO = vec3(scaled_depth); // your formula if(SCREEN_UV.x < 0.5) ALBEDO = original.rgb; // original rgb to check that the camera is actually pointing to the right spot } In preview mode, everything looks as they should be, ingame rgb and your formula look the same, my formula output only black pixels
I've given your shader a try and it works for me so unfortunately I don't have any specifics that can help solve the problem you're running into. I would say, as a general piece of troubleshooting, try using "clamp" to make sure values are in the range they're supposed to be, and double check that your "zFar" value is large enough that objects are within range to be seen. Also, you are correct that distance can't be a negative value, I could have been more accurate when talking about linear_depth, apologies for the confusion. In this case it is the z value of the position vector with the origin centered on the camera, and because the camera in godot looks along the -z axis, it results in a -value.
@@wattinteractive thank you for you time. It took A LOT (many hours of tests), but I figured out the problem. The error was outside the shader, a gd-script passed IDIOT numbers to he uniforms (zNear ~= zFar) so that only a silly slice of distance was enabled (and was so near the camera to be always empty).... the reason I saw the correct things in the preview was that it takes the correct values setted in the mesh instance propreties, but then those values were overwritten witn nonsense :( !
Oh, thanks for letting me know! I haven't found time to played around with the 4.0 branch yet, but I'll update the title to reflect the version that I'm using (3.5).
@@wattinteractive Maybe it's just the current alpha-build, or the whole rendering pipeline has changed. Who knows!? Works perfectly in 3.x and was very helpful.
I'm not sure if culling is disabled on quad meshes by default in 3, but the back face is culled by default in 4. If you set the render_mode to include either cull_front or cull_disabled, it should work!
Hey there! I wanted to thank you for making a great tutorial. It was really easy to follow and funny at times, too! I have a question: how do I set it so that the scanner is alway projected from a first person camera. I want it to be as if the player is scanning. So far, I have it set from the camera, but it only resisters from the players starting position. If the player moves, the scan stays at the spawn point and never moves. How to get the scan to attach to the player and move with them? Thank you for your help!
In the script attached to the Quad Mesh, I have it only setting the "start_point" parameter of the shader in the _ready function. If you want it to update to where your player is when it's started, you'll also want to set the "start_point" when the input is detected. I guess you could also keep setting it as the effect is running, but that would change how it looks if the player also moving at the same time. Probably isn't the effect you're looking for, but maybe something to experiment with. And thanks for checking out the video! 😄
@@wattinteractive I was able to get this to work! Thanks again for making this tutorial. I have been looking for a tutorial on this mechanic for a while. Everything you showed maded sense and was easy to follow. I hope you continue making tutorials for Godot!
Very good video..how do i set so that instead of drawing a circle, i draw a rectangle..I was thinking of using your idea but as lights underneath my vehicle
Oh, interesting question that I don't currently know the answer to. My first thought is that it might be easiest to just use lights underneath the vehicle, but I assume you've already tried that and it's not looking how you want it to. My second thought is that there's something called Signed Distance Fields (SDF) that might be what you're looking for. I'll add it to my schedule to look into, but it might be a while before I can get back to you. In the meantime, let me know if you figure it out; I'm curious to know the solution you came up with.
Well I'll let you know when I succeed. Anyway, I also looked everywhere for a color rect shader that blurs around a glowing object but coldnt find one. This shader might as well enhance our gles2 visuals in terms of bloom and emission
If you haven't already come up with another solution, I figured out how to do what I think you were asking for and made a video about it: ruclips.net/video/0BXBXy8zaaI/видео.html I hope it helps!
Yes, you can add variables to pass in the start location of the other pulses (and other timings if you want). You then also need to add another conditional statement for the pulses you want to add. I know they were looking at passing arrays to the shader in Godot 4 which could make this easier, but I haven't followed up on the status of that.
Yes, it is definitely possible to make more rings. You'll just need to do another check of the distance and start point and then mix that in to the albedo as well.
Small note: If youre using godot 4.0 and POSITION = vec4(VERTEX, 1.0); doesn't work, you can use POSITION = vec4(UV*2.0-1.0, 0.0, 1.0);
Oh, thanks for the tip! I'll keep it in mind for future Godot 4 videos👍
@@wattinteractive
POSITION = vec4(VERTEX, 1.0); still works in Godot 4, but 'Flip Faces' needs to be enabled on the QuadMesh
Thank you, I thought I was going crazy
thank you bro
Very enjoyable and informative video, looking forward to more content like this. :)
Thanks! I'm glad you enjoyed it 😄
Excellent tutorial, thank you!
If anyone else wants to use this effect with an Orthographic camera, I have a solution. I'm pretty new to shaders, so there's probably a better way, but this worked for me.
you will want to tweak your Camera's Far value, and maybe its distance from the scene-otherwise you might get some strange clipping.
I ended up moving my Camera out to z=100, and setting its Far to 130 (my camera is tilted at 30 degrees but I assume the similarity of these numbers is a coincidence). Experiment with your camera's near, far, and position, and eventually you should find some values where the whole shader mesh and scene are visible.
You're welcome! And thanks for the tips!
For the second half of the video, if you're in Godot 4, CAMERA_MATRIX is now INV_VIEW_MATRIX.
Thanks for the tutorial, great stuff!
I read that it's best to avoid "if" statements inside shaders and instead favor using equivalent mathematical functions. Something about wavefronts in parallel processing. Basically when every fragment executes the same code, then everything can keep running in parallel (as one wavefront). But if some fragments have different conditions, then it slows down the whole parallel schtick (creating new wavefronts)
Just to clarify, "if is_running" would not slow down parallel processing. But "if d > max_d" for example could be replaced by a function
Interesting, I'd not heard it put that way before but it makes sense to me and I'll keep that in mind for future tutorials/revisit this effect with that in mind. Thanks for the tip! 👍
This is very useful. Thank you!
This would be very useful to make some pre-rendered backgrounds! Thank you for the video
You're very welcome! I'm glad it was helpful 😄
Underrated video
Thanks! 😄
If anyone is looking for this effect in Godot 4, I've updated the GDScript and the Shader code at Godot Shaders. Link in the description ☝️
You just saved my life! I've already spent like 2 hours trying to adjust the old shader to Godot 4 with poor results... Thanks for awesome shader!
You are good ... please keep proceed
Thanks! 😄
that was rly good!
Thanks! I'm glad you enjoyed it 😄
Hello, this doesn't work when there is semi transparent objects in the scene. Would you mind making a tutorial for passing a viewport texture as a shader parameter to achieve a similar result but also show semi transparent objects ? I'd be eternally grateful :)
Ooh... interesting, I didn't of that. That sounds like a fantastic improvement to the shader, let me add that to the top of my list of topics to look at. Thanks!👍
@@wattinteractive Brilliant ! I'll be looking forward to it ! subbed and hit the bell :)
@@my2cents795 Thanks! 😁👍
Okay, so it looks like this will end up being a quite involved project to get it to fully work properly (seemingly due to the way Godot handles rendering transparency? Still looking into that), but I did find in playing around that if you set the render priority to -1 for the post-processing material, it should render the semitransparent objects, but they won't interact with the shader. Hopefully that's enough to get you by for now while I try and find a better solution! 👍
@@wattinteractive Ohhh, nice! That could work for now. I'm doing fog of war post processing shader for my RTS game (video coming out soon) and I have a few semi transparent assets but they all belong to the player so they should all be in the visible area of the fog of war (no need to be affected by the shader) but in the future, enemy units/buildings might have some semi transparent objects that need to be hidden in the fog of war still. I've browsed through the Godot github and found a few changes in the pipeline that allow for post transparency screen capture. Hopefully they are merged soon. Thanks a lot for the brilliant temporary solution :)
Can't understand well the scaled depth variable and how i should tune the zFar and zEnd variable... what is its range? I'm trying to achieve a result similar to the one of the first part of the video, but what I'm looking for is a "color" from 0 to full white, where 0 is everything farther than X (or background) and white means distance 0, and I'd like to have it linear..
Is the formula provided linear? Many thanks
So, I'm having trouble understanding exactly what you're looking for with the effect, but to try and answer your questions:
1. Yes, the formula is linear. It's purpose is just to re-scale the value that is retrieved from the depth buffer into something with more human understandable numbers.
2. In theory, zNear should be the distance away from the camera the effect starts, and zFar is telling the equation how far away the "max" effect should be. My demo scene is very small so I didn't get the chance to fully test it.
3. Now, to get the effect I think you want, you'll need to read the screen texture (like I do in the pulse section) and then mix it with a white color using the scaled depth value. It would be something like:
-----
vec4 original = texture(SCREEN_TEXTURE, SCREEN_UV);
vec3 white = vec3(1.0);
ALBEDO = mix(white, original.rgb, scaled_depth);
-----
If I misunderstood what you're looking for let me know what I missed and I'll try and answer again.
@@wattinteractive thank you very much. I've been very busy so I could recheck everything only today.
There are 2 issues to me, right now. 1 linear_depth isn't the distance it is negative! I think it is negative in your implementation too, because in your scaled_depth implementation you are multiplying for a negative factor (zNear - zFar). 2, I got the formula "right", since I make it work as intended in the preview, but running the project the shader show it pitch black. Here is my modified shader:
shader_type spatial;
render_mode unshaded;
uniform float zNear = 2.0;
uniform float zFar = 30.0;
void vertex(){
POSITION = vec4(VERTEX, 1.0);
}
void fragment(){
vec4 original = texture(SCREEN_TEXTURE, SCREEN_UV);
float depth = texture(DEPTH_TEXTURE, SCREEN_UV).x;
vec3 ndc = vec3(SCREEN_UV, depth) * 2.0 - 1.0;
vec4 view = INV_PROJECTION_MATRIX * vec4(ndc, 1.0);
view.xyz /= view.w;
float linear_depth = view.z;
float scaled_depth = (zFar * zNear) / (zFar + (linear_depth * (zNear - zFar)));
///////////////// up to here it should be identical to yours///////////////
float inverted_depth = -linear_depth; // because I found that linear_depth is negative
///////// limit inverted_depthto b in range [zNear, zFar]
if(inverted_depth > zFar)
inverted_depth = zFar;
else if(inverted_depth < zNear)
inverted_depth = zNear;
//////// end limiting
// zNear < inverted_depth < zFar;
if(SCREEN_UV.x < 1.0)
ALBEDO = vec3(1.0-((inverted_depth-zNear)/(zFar-zNear))); //the formula I want to work. SINCE zNear < inverted_depth < zFar, IN THEORY SHOULD BE IN RANGE [0,1]
if(SCREEN_UV.x < 0.55)
ALBEDO = vec3(scaled_depth); // your formula
if(SCREEN_UV.x < 0.5)
ALBEDO = original.rgb; // original rgb to check that the camera is actually pointing to the right spot
}
In preview mode, everything looks as they should be, ingame rgb and your formula look the same, my formula output only black pixels
I've given your shader a try and it works for me so unfortunately I don't have any specifics that can help solve the problem you're running into. I would say, as a general piece of troubleshooting, try using "clamp" to make sure values are in the range they're supposed to be, and double check that your "zFar" value is large enough that objects are within range to be seen.
Also, you are correct that distance can't be a negative value, I could have been more accurate when talking about linear_depth, apologies for the confusion. In this case it is the z value of the position vector with the origin centered on the camera, and because the camera in godot looks along the -z axis, it results in a -value.
@@wattinteractive thank you for you time. It took A LOT (many hours of tests), but I figured out the problem. The error was outside the shader, a gd-script passed IDIOT numbers to he uniforms (zNear ~= zFar) so that only a silly slice of distance was enabled (and was so near the camera to be always empty).... the reason I saw the correct things in the preview was that it takes the correct values setted in the mesh instance propreties, but then those values were overwritten witn nonsense :( !
Oof, yeah that's a rough one to debug, but I'm glad you were able to solve your issue! 😄
For some reason, the full-screen-quad method doesn't work in Godot 4.0.
Oh, thanks for letting me know! I haven't found time to played around with the 4.0 branch yet, but I'll update the title to reflect the version that I'm using (3.5).
@@wattinteractive Maybe it's just the current alpha-build, or the whole rendering pipeline has changed. Who knows!?
Works perfectly in 3.x and was very helpful.
I'm glad to hear it 😄
I'm not sure if culling is disabled on quad meshes by default in 3, but the back face is culled by default in 4. If you set the render_mode to include either cull_front or cull_disabled, it should work!
@@DevLogLogan It does!
Hey there! I wanted to thank you for making a great tutorial. It was really easy to follow and funny at times, too! I have a question: how do I set it so that the scanner is alway projected from a first person camera. I want it to be as if the player is scanning.
So far, I have it set from the camera, but it only resisters from the players starting position. If the player moves, the scan stays at the spawn point and never moves. How to get the scan to attach to the player and move with them?
Thank you for your help!
In the script attached to the Quad Mesh, I have it only setting the "start_point" parameter of the shader in the _ready function. If you want it to update to where your player is when it's started, you'll also want to set the "start_point" when the input is detected.
I guess you could also keep setting it as the effect is running, but that would change how it looks if the player also moving at the same time. Probably isn't the effect you're looking for, but maybe something to experiment with.
And thanks for checking out the video! 😄
@@wattinteractive I was able to get this to work! Thanks again for making this tutorial. I have been looking for a tutorial on this mechanic for a while. Everything you showed maded sense and was easy to follow. I hope you continue making tutorials for Godot!
Yay! I'm happy to hear it's working now. And yes, I'm certainly planning on making more videos... they just take a while to make 😅
Very good video..how do i set so that instead of drawing a circle, i draw a rectangle..I was thinking of using your idea but as lights underneath my vehicle
Oh, interesting question that I don't currently know the answer to. My first thought is that it might be easiest to just use lights underneath the vehicle, but I assume you've already tried that and it's not looking how you want it to.
My second thought is that there's something called Signed Distance Fields (SDF) that might be what you're looking for. I'll add it to my schedule to look into, but it might be a while before I can get back to you.
In the meantime, let me know if you figure it out; I'm curious to know the solution you came up with.
Well I'll let you know when I succeed.
Anyway, I also looked everywhere for a color rect shader that blurs around a glowing object but coldnt find one. This shader might as well enhance our gles2 visuals in terms of bloom and emission
If you haven't already come up with another solution, I figured out how to do what I think you were asking for and made a video about it: ruclips.net/video/0BXBXy8zaaI/видео.html
I hope it helps!
is it possible to have multiple instances of pulses each at a different place, at the same time?
Yes, you can add variables to pass in the start location of the other pulses (and other timings if you want). You then also need to add another conditional statement for the pulses you want to add. I know they were looking at passing arrays to the shader in Godot 4 which could make this easier, but I haven't followed up on the status of that.
Hi @blankink, were you able to figure this out? I'm looking into the same thing :)
@@adrianhusar I went with a completely different shader I used the cut off shader with a boder to it instead
Any idea why this doesnt work with GLES2?
Not off the top of my head. Let me look into it and I'll try to get back to you with an answer
is it posible to make multiple rings at the same time?
Yes, it is definitely possible to make more rings. You'll just need to do another check of the distance and start point and then mix that in to the albedo as well.
nice 3090