This video is incredible. I've been using Unreal's shader graph since UE3 and UDK and I'd say I've been doing it at a decently high level. However, I've always had a fascination with HLSL and just never known where to even start with it! Thank you for not only making it easy to understand, but actually showing a great starting point for a workflow to translate between the graph and code. 10/10. Would recommend.
Custom HLSL nodes open up a few things that simply can't be done through standard nodes in the material system. You can also use them to pull off some fun hacky things that you wouldn't think the engine would let you do. I cant wait to see what else you're going to cover :)
That was exactly what I've been trawling youtube for. So many materials tutorials are just joining nodes together with zero explanation. This was such a great and well explained introduction :) I'll be watching all your videos.. And I'll add you to my IOU list once I manage to finally get a job (unemployed right now so I can't join the Patreon just yet).. But I intend to support all the people such as yourself who are making this learning journey possible.. Thanks!
This is awesome! Sine is actually from -1 to 1 for everyone who may have run into issues experimenting. Use a ConstantBiasScale to adjust it to 0 to 1 or add 1 divide by two . Doing that messes with the above results though but just an fyi.
That ConstantBiasScale is a really good tip! I have a correction in the description about the range of sin. But for some reason that correction isn't popping up on the video. When using those values as a mask it usually wont matter if its -1 or 0 vs 1 or 100 it will produce the same output. But It is much more proper to use the ConstantBiasScale as you mentioned or at least throw a Saturate or Clamp node on the sin curve to clamp it between 0-1. Thanks for suggesting this.
You're genuinely a great fucking teacher i appreciate the effort that went into the video it made it so much easier to understand than reading random HLSL tutors lol
The sine node is from -1 to 1. Unfortunately this can be confusing when you just want a value to go from 0 to 1 as the time it takes the sine to come back up to 0 from -1 means that the colour black will be there longer than the colour white. You probably already know this but just incase someone else needs to know: After sine, put an add node with a value of 1 and then connect a divide node with a value of 2. This ensures the pulsating value stays between 0 and 1. What you will then need to do with the step node after subtract is have a value of 0.05 instead. Otherwise the sliding effect will only go 50% of the way with the value of 0.5 as stated in the video. For the custom node I figured out it would be this (I'm still extremely new to this so it took a while to learn where +1 and /2 would go lol) return(step((ceil(uv*10)/ 10)-(sin(t)+1)/2 ,0.05));
Thank you for posting this! that is correct. It is going to -1 to 1, but In this video I incorrectly called it as 0. When plugging the sine into the alpha of a lerp it will get clamped out at 0 (black) so anything lower than that won't make any difference. But this clarification you posted I'm sure is very helpful to others to understand the math correctly.
Good morning Mr @renderbucket , in your example you had Sine with a Period of 3. How would this translate into the Custom Expression? I tried to multiply sine by 3, eg: (3sin(t)) but that clearly is not the answer as it just broke the effect. Then I tried 3*sin and while that does not break the effect it does not have the same effect on the timing as the example with the Sine Period of 3? This probably is not a big deal at all, but my small brain is just trying to follow along as best I can. Thank you for these tutorials.
Great stuff! Thanks for such detailed explanation. One question - is there a way to keep HLSL code as file outside the custom function? Can't find relevant information on that topic.
Awesome video! but there are two thing I didn't quite understand: How does the written function node knows you want to do It on the x axis instead of the y of the UVs? And at 14:23 you altered the sine period value on the node so It fills slower, but I didn't see that being specified on the written counterpart , how did It go at more or less the same speed as the node version?
Great questions!. So for the first thing, the blocks revealing go left to right because when we use the break out float2 components we are only using R (Red/X). So that gives us a gradient in X axis, which then when we subtract a value going from White to Black it reveals and hides values on the X axis going from 0-1 produce the horizontal animation. If we were to use the G (Green/Y) value instead when breaking our float2 components then it would be Up and Down. For the sine period modification, the sine node in Unreal is a bit odd because it defaults with a period of 1.0. When normally its 2 * PI (3.14...) If you are not using a sine node in Unreal and instead HLSL Code and you want to modify the period in HLSL code you will have to achieve a similar result by doing something like sin(x * (1/p) * 2 * 3.14); Where x is what you are connecting the sine node to inputting into the sine node. Where p is your period value (so 1 if you want it to match unreals period default of 1).
A little bit off topic but I would like to see a conversion of something that runs on tick into c++ since in one of the conferences about optimization in the unreal fest they said anything that ticks run 10x times faster when converted into c++, so I think is a must have for everyone, I mean, 10 times is too much performance and there are a ton of things that run on tick.
Not sure exactly what you may be referring to, but generally a tick is a cycle. Often referred to as a frame when people mention stuff like do this every "tick".etc What they might be referring to is certain code/things may run much faster in C++ than through blueprints or alternative ways of doing things. There also may be the case sometimes were its the opposite. I would need a bit more details to fully comment, but generally C++ is a very low level language so its performance is often much higher than other languages like python.etc
Green (U) goes horizontal across the x axis as you can see it starts on the left (and moves across to the right). Red (V for vertical :P ) starts from the top (where you can see it) and fades down the y-axis, vertically. Hope that helps.
@@DRockafella no sir,U is RED and represents the horizontal direction, while V is GREEN and represents the vertical direction. Just component mask out any channel, and you'll see the b/w gradient in 0-1 direction.
Fantastic videos! I wanted to ask since I've become increasingly interested in Shaders. Should I master the Material Editor and all its functions/nodes before I jump into HLSL? Or would it actually help me learn Material Editor better if I already had some HLSL knowledge
Don't wait, if you're interested in HLSL learning even just a bit of it will help you understand how to use nodes in the material editor in any game engine. Remember even with nodes, you are just writing HLSL or shader coding but in a more visual way. Sometimes it's easier, sometimes it's faster, and sometimes writing HLSL is easier and quicker. Any sort of technical shading challenge will benefit greatly from HLSL and various graphics programming techniques. I'll also highly recommend GPU Gems, a book that's old but still very relevant. You can google it and Nvidia has it online for free. Would recommend it as more technical guide on various techniques. Good luck with your learning! And when you make cool stuff please share with us and join the Discord!
@@renderbucket I appreciate you taking the time to write such a helpful and constructive reply! I will definitely begin learning HLSL then! :) Its something I am quite interested in but feel a little intimidated by it. I have basic programming skills (C++ and C#) so hopefully it transfers over well 😅I will definitely be joining the discord to see shader lovers out there. And thanks for the book recommendation, awesome that its free online!
Not really, if you can do the same thing with Nodes. Probably better to do it with Nodes in most cases. Some of the nodes in Unreal are really just using HLSL if you go into them. But there are many things you can do with HLSL that aren't possible in Nodes in Unreal. It also sometimes can be way easier to do things with code than tons of nodes. So its really more of compliment to working with nodes for the basic/intermediate side of things. And on the very advanced end of things you can go as far as creating compute shaders or fully custom materials. HLSL is also not just a Unreal thing it can be used in Unity or any other Game Engine running on DirectX. It is also very similar to GLSL, so learning one or the other you kind of learn both.
In general, does HLSL run more efficiently/use less instructions than implementing the same thing via nodes? I'm sure that's a big ol' "DEPENDS," but I figured I would ask. :)
It does depend. Certain things you can only do in HLSL and not through nodes in an easy way. That's where HLSL is more efficient. A lot of the Unreal nodes also use HLSL inside them in custom nodes. Internally all of the materials in Unreal are HLSL code.
unreal will optimize away "same" shader instructions if the are done in material graph, but it doesn't do that for hlsl. Instead, you need to mark it yourself with things like #LOOP, #BRANCH, etc to tell the engine how to "unroll" the shaders.
There is, but in this case since we are just making t and uv a variable that references to the input of our Custom node. It will just inherit whatever the Time node is (float) and uv (vec2/float2).
Depends what your doing, for simple stuff its probably not much difference. For some things the nodes may be faster due to optimizations in Unreal. But the main thing is that certain things, like for loops you cannot do through Nodes. So your only option is to use HLSL in a Custom node or write a fully custom shader for Unreal. For more complex things eventually we will be referencing in external files instead of always just throwing updated code into our Custom Node.
@@renderbucket Yea, I just did some research as well: The nodes get optimized by the compiler expect for the "custom"-node, so basicly no HLSL optimization. So in that case nodes should almost always be faster depending on what you do of course. Also you could modify the engine to make custom HLSL.
Hello, I am modding a game in a Custom UE 4.13 Is there any chance you can provide me a script for these nodes Step Saturate Bosol and also I wanted to ask if it's possilbe to create our own Material Expression Nodes instead of using the Custom via Visual Studio and UE source
Your style of teaching in this video is beyond valuable for anyone learning this concept for the first time. Excellent work!
This video is incredible.
I've been using Unreal's shader graph since UE3 and UDK and I'd say I've been doing it at a decently high level.
However, I've always had a fascination with HLSL and just never known where to even start with it!
Thank you for not only making it easy to understand, but actually showing a great starting point for a workflow to translate between the graph and code.
10/10. Would recommend.
Custom HLSL nodes open up a few things that simply can't be done through standard nodes in the material system. You can also use them to pull off some fun hacky things that you wouldn't think the engine would let you do. I cant wait to see what else you're going to cover :)
That was exactly what I've been trawling youtube for. So many materials tutorials are just joining nodes together with zero explanation. This was such a great and well explained introduction :) I'll be watching all your videos.. And I'll add you to my IOU list once I manage to finally get a job (unemployed right now so I can't join the Patreon just yet).. But I intend to support all the people such as yourself who are making this learning journey possible.. Thanks!
Nice soft intro to using HLSL in Unreal. Thanks for sharing!
This is awesome! Sine is actually from -1 to 1 for everyone who may have run into issues experimenting. Use a ConstantBiasScale to adjust it to 0 to 1 or add 1 divide by two . Doing that messes with the above results though but just an fyi.
That ConstantBiasScale is a really good tip!
I have a correction in the description about the range of sin. But for some reason that correction isn't popping up on the video. When using those values as a mask it usually wont matter if its -1 or 0 vs 1 or 100 it will produce the same output. But It is much more proper to use the ConstantBiasScale as you mentioned or at least throw a Saturate or Clamp node on the sin curve to clamp it between 0-1.
Thanks for suggesting this.
@@renderbucket Oh cool! Sorry I didn't see it. I just subscribed to your patreon. This content is great!
This topic is finally exactly what I looked for, thank you
You're genuinely a great fucking teacher i appreciate the effort that went into the video it made it so much easier to understand than reading random HLSL tutors lol
You are the best, man! So interesting and clear lesson. Thank you so much!!
Fantastic, I'm going to watch all these videos. Just what I was hoping to learn!
Man you are the great. I was looking for videos like this. Thank you very much buddy .
A really impressive tutorial.
This is the best tutorial about HLSL for Unreal Engine in the WORLD! Khan Academy level, thanks !!
Yes, please more of these videos.
This is right the thing I’ve been searching! Thank you for your work!
Great tutorial mate, easy to follow
Thank you very much for this tutorial!
The sine node is from -1 to 1. Unfortunately this can be confusing when you just want a value to go from 0 to 1 as the time it takes the sine to come back up to 0 from -1 means that the colour black will be there longer than the colour white.
You probably already know this but just incase someone else needs to know: After sine, put an add node with a value of 1 and then connect a divide node with a value of 2. This ensures the pulsating value stays between 0 and 1.
What you will then need to do with the step node after subtract is have a value of 0.05 instead. Otherwise the sliding effect will only go 50% of the way with the value of 0.5 as stated in the video.
For the custom node I figured out it would be this (I'm still extremely new to this so it took a while to learn where +1 and /2 would go lol)
return(step((ceil(uv*10)/ 10)-(sin(t)+1)/2 ,0.05));
Thank you for posting this! that is correct.
It is going to -1 to 1, but In this video I incorrectly called it as 0.
When plugging the sine into the alpha of a lerp it will get clamped out at 0 (black) so anything lower than that won't make any difference. But this clarification you posted I'm sure is very helpful to others to understand the math correctly.
@@renderbucket Ah I didn't know that about the lerp clamping the sine. I should give this a test thank you :)
Is this the reason why in the video the animation always paused for a second when 100% red or 100% blue?
@@zombi1034 Yes
your tutorials are very pleasant to watch, very big thanks to you, i am learning a lot!
Very cool, nice work and thanks for sharing. Stay safe out there.
This is so much helpful! The explanation was very simple to understand
i love you work man !!!
FWIW, in 5.4, it looks like you can adjust the UV tiling on the Texture Coordinate node.
Great video, nice and clear!😍
thanks for the vid! more HLSL pls!
Good morning Mr @renderbucket , in your example you had Sine with a Period of 3. How would this translate into the Custom Expression?
I tried to multiply sine by 3, eg: (3sin(t)) but that clearly is not the answer as it just broke the effect. Then I tried 3*sin and while that does not break the effect it does not have the same effect on the timing as the example with the Sine Period of 3?
This probably is not a big deal at all, but my small brain is just trying to follow along as best I can.
Thank you for these tutorials.
Nice!!! Thanks for excellent and clear tutorial!!!~🤩
Great stuff! Thanks for such detailed explanation. One question - is there a way to keep HLSL code as file outside the custom function? Can't find relevant information on that topic.
thank you
great content
thank you!!!!!
Awesome!
When to use HLSL? What advanteges? I know it can do for loops, but don't know rest.
Awesome video! but there are two thing I didn't quite understand: How does the written function node knows you want to do It on the x axis instead of the y of the UVs? And at 14:23 you altered the sine period value on the node so It fills slower, but I didn't see that being specified on the written counterpart , how did It go at more or less the same speed as the node version?
Great questions!.
So for the first thing, the blocks revealing go left to right because when we use the break out float2 components we are only using R (Red/X). So that gives us a gradient in X axis, which then when we subtract a value going from White to Black it reveals and hides values on the X axis going from 0-1 produce the horizontal animation. If we were to use the G (Green/Y) value instead when breaking our float2 components then it would be Up and Down.
For the sine period modification, the sine node in Unreal is a bit odd because it defaults with a period of 1.0. When normally its 2 * PI (3.14...)
If you are not using a sine node in Unreal and instead HLSL Code and you want to modify the period in HLSL code you will have to achieve a similar result by doing something like
sin(x * (1/p) * 2 * 3.14);
Where x is what you are connecting the sine node to inputting into the sine node.
Where p is your period value (so 1 if you want it to match unreals period default of 1).
A little bit off topic but I would like to see a conversion of something that runs on tick into c++ since in one of the conferences about optimization in the unreal fest they said anything that ticks run 10x times faster when converted into c++, so I think is a must have for everyone, I mean, 10 times is too much performance and there are a ton of things that run on tick.
Not sure exactly what you may be referring to, but generally a tick is a cycle. Often referred to as a frame when people mention stuff like do this every "tick".etc
What they might be referring to is certain code/things may run much faster in C++ than through blueprints or alternative ways of doing things. There also may be the case sometimes were its the opposite. I would need a bit more details to fully comment, but generally C++ is a very low level language so its performance is often much higher than other languages like python.etc
5:58 hey isnt GREEN is vertical 0 to 1 top to down while RED horizontal 0 to 1 left to right?
Green (U) goes horizontal across the x axis as you can see it starts on the left (and moves across to the right). Red (V for vertical :P ) starts from the top (where you can see it) and fades down the y-axis, vertically.
Hope that helps.
@@DRockafella no sir,U is RED and represents the horizontal direction, while V is GREEN and represents the vertical direction. Just component mask out any channel, and you'll see the b/w gradient in 0-1 direction.
@@DRockafella if u look closely, green horizontal only hue is changing not the value.
You're awesome!
Fantastic videos!
I wanted to ask since I've become increasingly interested in Shaders. Should I master the Material Editor and all its functions/nodes before I jump into HLSL? Or would it actually help me learn Material Editor better if I already had some HLSL knowledge
Don't wait, if you're interested in HLSL learning even just a bit of it will help you understand how to use nodes in the material editor in any game engine.
Remember even with nodes, you are just writing HLSL or shader coding but in a more visual way. Sometimes it's easier, sometimes it's faster, and sometimes writing HLSL is easier and quicker.
Any sort of technical shading challenge will benefit greatly from HLSL and various graphics programming techniques. I'll also highly recommend GPU Gems, a book that's old but still very relevant. You can google it and Nvidia has it online for free. Would recommend it as more technical guide on various techniques.
Good luck with your learning! And when you make cool stuff please share with us and join the Discord!
@@renderbucket I appreciate you taking the time to write such a helpful and constructive reply! I will definitely begin learning HLSL then! :) Its something I am quite interested in but feel a little intimidated by it. I have basic programming skills (C++ and C#) so hopefully it transfers over well 😅I will definitely be joining the discord to see shader lovers out there.
And thanks for the book recommendation, awesome that its free online!
Does UE4.26 run these tutorials correctly?
Does HLSL provide performance benefits over nodes?
Not really, if you can do the same thing with Nodes. Probably better to do it with Nodes in most cases. Some of the nodes in Unreal are really just using HLSL if you go into them.
But there are many things you can do with HLSL that aren't possible in Nodes in Unreal.
It also sometimes can be way easier to do things with code than tons of nodes.
So its really more of compliment to working with nodes for the basic/intermediate side of things.
And on the very advanced end of things you can go as far as creating compute shaders or fully custom materials.
HLSL is also not just a Unreal thing it can be used in Unity or any other Game Engine running on DirectX. It is also very similar to GLSL, so learning one or the other you kind of learn both.
Is there something wrong about the direction？ at around 5:45
Nice video, thanks. Shouldn't Sine node output be going -1 to 1, not 0 to 1 ?
ohhhhhhhhhhhhhhhh!
In general, does HLSL run more efficiently/use less instructions than implementing the same thing via nodes? I'm sure that's a big ol' "DEPENDS," but I figured I would ask. :)
It does depend. Certain things you can only do in HLSL and not through nodes in an easy way. That's where HLSL is more efficient. A lot of the Unreal nodes also use HLSL inside them in custom nodes. Internally all of the materials in Unreal are HLSL code.
unreal will optimize away "same" shader instructions if the are done in material graph, but it doesn't do that for hlsl. Instead, you need to mark it yourself with things like #LOOP, #BRANCH, etc to tell the engine how to "unroll" the shaders.
Why not "uv.x" but rather "uv" since we know which of the uv cordinates we need?
So there is no type for variables?i mean uv is 2d vector and t is a float
There is, but in this case since we are just making t and uv a variable that references to the input of our Custom node. It will just inherit whatever the Time node is (float) and uv (vec2/float2).
Does the HLSL code run faster than the Node-based "Code"?
Depends what your doing, for simple stuff its probably not much difference. For some things the nodes may be faster due to optimizations in Unreal. But the main thing is that certain things, like for loops you cannot do through Nodes. So your only option is to use HLSL in a Custom node or write a fully custom shader for Unreal.
For more complex things eventually we will be referencing in external files instead of always just throwing updated code into our Custom Node.
@@renderbucket Yea, I just did some research as well: The nodes get optimized by the compiler expect for the "custom"-node, so basicly no HLSL optimization. So in that case nodes should almost always be faster depending on what you do of course. Also you could modify the engine to make custom HLSL.
Hello, I am modding a game in a Custom UE 4.13
Is there any chance you can provide me a script for these nodes
Step
Saturate
Bosol
and also I wanted to ask if it's possilbe to create our own Material Expression Nodes instead of using the Custom via Visual Studio and UE source