Nice sharing! That being said, you need to be careful if working with nanite, the vertex interpolators are being evaluated three times per vertices for barycentrics, it can actually affect negatively nanite's basepass; there's that, plus the fact that often when working with nanite, you end up with much more tris in a single pixel, also adding to the evaluation cost that ordinarily would have been just a single block of 4x4 pixels.
This is true and false at the same time. With nanite, there is 2 rasterization path possible, the one you are talking about is if the shader is using Programmable Rasterisation, which happens whenever you use any deforming property of a shader. Otherwise, if you are using an opaque shader with no WPO, it doesn't run 3 times per vertex. This talk from unreal fest explains all of it really well! th-cam.com/video/Cb63bHkWkwk/w-d-xo.html
Thank you for your tutorial, Ben. I can't wait for holidays to try to measure the difference between Vertex Shader UV scrolling and Pixel Shader UV scrolling using what I've learnt in your Shader Performance Measurement Part 2 tutorial.
About packing the UVs into fewer interpolators, if you select the custom interpolator in the vertex block you can change their type to vector2. Btw as far as I know Unity does pack the interpolators as tightly as possible so using a bunch of smaller interpolators should not incur any additional cost. There is one thing I am missing in the video which be a bit very advanced though. Memory is slow, instructions are fast, gpu memory is precious at what point could it be worth NOT moving calculations to the vertex shader because passing them through the interpolator struct is actually more costly in terms of packing operations and memory bandwidth than just doing the instructions in the pixel shader directly (uv scrolling is typically just a single multiply and addition with time).
Could you start making tutorials about the custom node? despite it is standard hlsl there is also some unreal engine magic in it, like sampling textures or the scene texure... also another idea is what you can achieve with render targets in addition to materials (eg. draw some material onto a render target to reuse the render target in other materials). eg calculating a blur mask and normal map for screen rain etc. pp. good video as always
Good approach :) Please bake the animation into the texture. And the transition between baked animations for Unity. I'm trying to do animation blending, it's a pain :(
While you could bake the water ripples into a texture and treat it like a flipbook per se, there isn't any major advantage of doing so in this case, panning the the texture coords is just easier and more flexible without any real detriment to performance.
No, I'm not talking about water. The water shader in this video is amazing. I'm talking about Vertex Animation Texture (VAT). This is a series of lessons about the vertex shader. I would like to see a lesson about VAT in this series. Mixing two textures scares me :(@@soulshard7229
Very much enjoyed this video. Do you know offhand, if adding customized UV pins to a UE4/5 material and piping uv manipulation for, say, the water textures into those, does that default to the vertex shader or do you still need to add a vertex interpolator there? One thing I've done as well for multi-platform development is to put vertex interpolators behind platform switches, so on mobile shading models more logic will be pushed to the vertex shader than on SM5.
I am pretty sure that using the Vertex Interpolator is exactly the same as turning on custom UVs and rerouting via texcoords. Much nicer to see in the editor; I used to route everything through customUV for mobile platforms and it made my brain explode on some of the more complex materials. Huge performance gains though. One thing to be careful about is Time; on mobile platforms Time only goes so high and will stop working at a certain point lol
Hi Ben, love your videos. However, I have some questions about this one. I've recently read that, while what you said was true in the past and still is on some mobile hardware, the performance costs of moving data from the vert to the frag stage are rarely worth the save in computational instructions on modern PCs and consoles. From what I've read this is because memory bandwidth improvements continue to lag behind raw computation speed on modern GPUs. Do you perhaps know more about this?
You make a really good point. There is a cost to passing the data from the vertex shader to the pixel shader, so in order for the math savings to make a difference in performance, the savings of the math you do in the vertex shader has to be more than the cost of moving it. Where that balance is will be different on every platform. The only way to know for sure is to test it on your hardware and see.
the triangles are usually bigger than a single pixel in nanite, but adding a vertex interpolator is such a tiny change that I would probably do it anyway
Thank you Ben. Your optimization tutorials are my favorite tutorials. Please do more.
Nice sharing! That being said, you need to be careful if working with nanite, the vertex interpolators are being evaluated three times per vertices for barycentrics, it can actually affect negatively nanite's basepass; there's that, plus the fact that often when working with nanite, you end up with much more tris in a single pixel, also adding to the evaluation cost that ordinarily would have been just a single block of 4x4 pixels.
So we need at least 3x less vertices than pixels on screen per pixel to make it worthwhile?
This is true and false at the same time. With nanite, there is 2 rasterization path possible, the one you are talking about is if the shader is using Programmable Rasterisation, which happens whenever you use any deforming property of a shader. Otherwise, if you are using an opaque shader with no WPO, it doesn't run 3 times per vertex. This talk from unreal fest explains all of it really well! th-cam.com/video/Cb63bHkWkwk/w-d-xo.html
Love the quick lighting tutorial that didn't last 14m. Thanks for not dragging that out.
Thank you for your tutorial, Ben.
I can't wait for holidays to try to measure the difference between Vertex Shader UV scrolling and Pixel Shader UV scrolling using what I've learnt in your Shader Performance Measurement Part 2 tutorial.
Thank you for sharing Ben. Your knowledge sharing is helping me create some beautiful VR game environments. I can't wait to show them to you someday.
Very nice tutorial! Informative. If you're doing something more retro style in Unreal like recreating a PS1 or PS2 look, would you use this method?
About packing the UVs into fewer interpolators, if you select the custom interpolator in the vertex block you can change their type to vector2.
Btw as far as I know Unity does pack the interpolators as tightly as possible so using a bunch of smaller interpolators should not incur any additional cost.
There is one thing I am missing in the video which be a bit very advanced though. Memory is slow, instructions are fast, gpu memory is precious at what point could it be worth NOT moving calculations to the vertex shader because passing them through the interpolator struct is actually more costly in terms of packing operations and memory bandwidth than just doing the instructions in the pixel shader directly (uv scrolling is typically just a single multiply and addition with time).
Could you start making tutorials about the custom node? despite it is standard hlsl there is also some unreal engine magic in it, like sampling textures or the scene texure...
also another idea is what you can achieve with render targets in addition to materials (eg. draw some material onto a render target to reuse the render target in other materials). eg calculating a blur mask and normal map for screen rain etc. pp. good video as always
Thank you for all you have done for art
Good approach :) Please bake the animation into the texture. And the transition between baked animations for Unity. I'm trying to do animation blending, it's a pain :(
While you could bake the water ripples into a texture and treat it like a flipbook per se, there isn't any major advantage of doing so in this case, panning the the texture coords is just easier and more flexible without any real detriment to performance.
No, I'm not talking about water. The water shader in this video is amazing. I'm talking about Vertex Animation Texture (VAT). This is a series of lessons about the vertex shader. I would like to see a lesson about VAT in this series. Mixing two textures scares me :(@@soulshard7229
Thanks for the suggestion! Several people have asked for this as well.
Great video, interesting stuff :)
Oh wow this function is very hidden in Unity, very helpful
Very much enjoyed this video. Do you know offhand, if adding customized UV pins to a UE4/5 material and piping uv manipulation for, say, the water textures into those, does that default to the vertex shader or do you still need to add a vertex interpolator there?
One thing I've done as well for multi-platform development is to put vertex interpolators behind platform switches, so on mobile shading models more logic will be pushed to the vertex shader than on SM5.
I am pretty sure that using the Vertex Interpolator is exactly the same as turning on custom UVs and rerouting via texcoords. Much nicer to see in the editor; I used to route everything through customUV for mobile platforms and it made my brain explode on some of the more complex materials. Huge performance gains though.
One thing to be careful about is Time; on mobile platforms Time only goes so high and will stop working at a certain point lol
woah @@CorporalDanLives
Hello Ben. Your tutorials are awesome!!!
Could you please make some tutorial about Six-way lighting sprite shader?
Hi Ben, love your videos. However, I have some questions about this one.
I've recently read that, while what you said was true in the past and still is on some mobile hardware,
the performance costs of moving data from the vert to the frag stage are rarely worth the save in computational instructions on modern PCs and consoles.
From what I've read this is because memory bandwidth improvements continue to lag behind raw computation speed on modern GPUs.
Do you perhaps know more about this?
You make a really good point. There is a cost to passing the data from the vertex shader to the pixel shader, so in order for the math savings to make a difference in performance, the savings of the math you do in the vertex shader has to be more than the cost of moving it. Where that balance is will be different on every platform. The only way to know for sure is to test it on your hardware and see.
Is this even relevant when using nanite? with dense enough meshes you still do the operation at 1x pixel on screen right?
the triangles are usually bigger than a single pixel in nanite, but adding a vertex interpolator is such a tiny change that I would probably do it anyway
Wait, when did we start making custom shading models? Please expand, I want to learn about phong and such to nail a unique style :(
Heheh - I just kinda snuck that in there, didn't I? I'll put it on my list as something to cover later. It's kind of a complex topic.