Hi, I just want to say, thank you so much, for explaining such things, I seriously hate when people do these but don't explain the concepts behind what they do and how it works. I have been trying to find someone to explain things that are conceptually interesting for a long time. So thank you
So...between you and this guy (ua-cam.com/video/gfQNjC69PCM/v-deo.html), you're my grass-guru's... I like the derived normals in your model, the vein in the middle REALLY helps sell the 'blade' of grass. However, I like the bend, and at the very least, the conservation of the length of the mesh during the bend in Visual Tech Art's video. Is there a way to conserve the length of the mesh given your method of using the curve-math you do? Between the two of you, there seems to be the potential to have an 'ultimate open-source' grass shader for unreal, where we can get a physically-accurate/conservative bend, as well as some detail in derive-normals. The normals which would help with being-wet, covered with snow/dust, etc. The application as a 'basic' grass blade would be enormous if we could marry the two techniques... Your method also has the advantage of having texture-samples run in the vertex-shader vs the pixel-shader. And just to say, thanks for all the knowledge-bombs dropped on us, I really do appreciate.
The advantage of the bezier curve is it allows for far more control over the shape of the blade, and even more detail could be added with an additional control point, allowing for S shapes, or less even curves. The disadvantage is that it is surprisingly difficult and computationally expensive to accurately determine the length. Controlling the length is a challenge as well. I have found a formula for estimating the length, and have an untested idea of how that could hopefully be used to prevent the grass from noticeably changing length but at best it's an approximation, if it even works. In Ghost of Tsushima, they just made sure to keep the grass animation relatively restrained in hopes no one would notice the blades do change length slightly.
I've completed a blade length consistency system. It seems to work pretty well although it can definitely be broken. I think it should work well for the range of shapes we expect to see with the grass although The basic idea behind it is that we know that a bezier curve can't be longer than the distance between p0 and p1 + p1 and p2 (aka the polygon length). It can't be shorter than the distance between p0 and p2 either (aka the chord length) - so this gives us a domain we can estimate within and restrain the length to.
Yeah, I'll show per blade randomization soon. Either the next vid or the one after. In Ghost of Tsushima, they made their short grass by modifying the one long grass blade into two blades by making the center point the base and both ends a tip. This allowed them to get short grass that was twice as dense for the same number of tris and instances as the long grass. Short grass will perform better than long grass. Nanite started having issues with more than 2 million blades of grass with the default configuration. We'll be scaling up to a small scene with a few hundred thousand blades of grass in the next video and probably to a large field after that.
How would you structure the shader for view dependent thickening if you were to instead use a mesh of grass blade. I designed a mesh of grass blade myself, and I am trying to achieve what you achieved with vertex colors instead, it is not working correctly though. You used texture coordinate to calculate the left edge (t) and I am doing the same with vertex colors, and that seems to be working just fine. The part where you multiply the rest of the nodes with your normal is where my version has a problem, I assume. Since my normal is rounded (blue gradient), I am not exactly sure how I could make it work. And by no means I am experienced with writing shaders, so I am interested what your approach to this would be.
its mostly a matter of deciding what direction you want to shift the vertex positions. In Ghost of Tsushima, they simply shifted them down in view space. I am shifting them in the downward facing vertex normal direction, but you could shift them in any direction you want and have a means to define. The downward local z normal would be another decent choice. The reason I went with the approach I did is that neither the view space or local z shift thickens the blade evenly regardless of the triangles orientation. You could also nullify part of your normal, and multiply by that. For example, say we only want to shift the verts in the Z and X direction. We can just eliminate the Y axis and then the roundness of the blade in that direction wont interfere.
@@TechArtAlex Interesting, I will mess with this myself more. I have kind of got it working by multiplying XZ vector and skipping the normal. Funny thing is the X pushes the verts towards -X instead of +X lol. But yeah, love your work. Thanks!
@@TechArtAlex will this be the cpu/gpu sample-able noise as discussed in the paper? I've also been watching this: ua-cam.com/video/bp7REZBV4P4/v-deo.html
I plan on showing a pretty basic implementation for the wind, mostly to show how you should approach altering the grass blade to get the most out of the bezier. It will be perlin noise texture based - so the CPU could certainly read the texture but I'm not looking to streamline that further for now. Ultimately you could swap it for many different approaches as long as you stick to the core idea - which is to move the control points, not the verts directly.
Yes. The blade could be rotated using the rotate about axis node. You can also use a 3D bezier curve instead of a 2D curve. However, unless you need the rotation to change at runtime, it would be cheaper to handle rotation at build time such as by using PCG to set the desired transform based on whatever rules you want.
Hi, I just want to say, thank you so much, for explaining such things, I seriously hate when people do these but don't explain the concepts behind what they do and how it works. I have been trying to find someone to explain things that are conceptually interesting for a long time. So thank you
Thank you! I agree, knowing why is as important as knowing how.
So...between you and this guy (ua-cam.com/video/gfQNjC69PCM/v-deo.html), you're my grass-guru's...
I like the derived normals in your model, the vein in the middle REALLY helps sell the 'blade' of grass. However, I like the bend, and at the very least, the conservation of the length of the mesh during the bend in Visual Tech Art's video.
Is there a way to conserve the length of the mesh given your method of using the curve-math you do?
Between the two of you, there seems to be the potential to have an 'ultimate open-source' grass shader for unreal, where we can get a physically-accurate/conservative bend, as well as some detail in derive-normals. The normals which would help with being-wet, covered with snow/dust, etc. The application as a 'basic' grass blade would be enormous if we could marry the two techniques...
Your method also has the advantage of having texture-samples run in the vertex-shader vs the pixel-shader.
And just to say, thanks for all the knowledge-bombs dropped on us, I really do appreciate.
The advantage of the bezier curve is it allows for far more control over the shape of the blade, and even more detail could be added with an additional control point, allowing for S shapes, or less even curves.
The disadvantage is that it is surprisingly difficult and computationally expensive to accurately determine the length. Controlling the length is a challenge as well.
I have found a formula for estimating the length, and have an untested idea of how that could hopefully be used to prevent the grass from noticeably changing length but at best it's an approximation, if it even works.
In Ghost of Tsushima, they just made sure to keep the grass animation relatively restrained in hopes no one would notice the blades do change length slightly.
I've completed a blade length consistency system. It seems to work pretty well although it can definitely be broken. I think it should work well for the range of shapes we expect to see with the grass although
The basic idea behind it is that we know that a bezier curve can't be longer than the distance between p0 and p1 + p1 and p2 (aka the polygon length). It can't be shorter than the distance between p0 and p2 either (aka the chord length) - so this gives us a domain we can estimate within and restrain the length to.
Great work, would like to see different bends on different blades? also shorter grass in a big field performance
Yeah, I'll show per blade randomization soon. Either the next vid or the one after.
In Ghost of Tsushima, they made their short grass by modifying the one long grass blade into two blades by making the center point the base and both ends a tip. This allowed them to get short grass that was twice as dense for the same number of tris and instances as the long grass.
Short grass will perform better than long grass. Nanite started having issues with more than 2 million blades of grass with the default configuration. We'll be scaling up to a small scene with a few hundred thousand blades of grass in the next video and probably to a large field after that.
How would you structure the shader for view dependent thickening if you were to instead use a mesh of grass blade. I designed a mesh of grass blade myself, and I am trying to achieve what you achieved with vertex colors instead, it is not working correctly though. You used texture coordinate to calculate the left edge (t) and I am doing the same with vertex colors, and that seems to be working just fine. The part where you multiply the rest of the nodes with your normal is where my version has a problem, I assume. Since my normal is rounded (blue gradient), I am not exactly sure how I could make it work.
And by no means I am experienced with writing shaders, so I am interested what your approach to this would be.
its mostly a matter of deciding what direction you want to shift the vertex positions. In Ghost of Tsushima, they simply shifted them down in view space. I am shifting them in the downward facing vertex normal direction, but you could shift them in any direction you want and have a means to define. The downward local z normal would be another decent choice. The reason I went with the approach I did is that neither the view space or local z shift thickens the blade evenly regardless of the triangles orientation. You could also nullify part of your normal, and multiply by that. For example, say we only want to shift the verts in the Z and X direction. We can just eliminate the Y axis and then the roundness of the blade in that direction wont interfere.
@@TechArtAlex Interesting, I will mess with this myself more. I have kind of got it working by multiplying XZ vector and skipping the normal. Funny thing is the X pushes the verts towards -X instead of +X lol.
But yeah, love your work. Thanks!
@@TechArtAlex Okay, final update. I got it working, I made changes to my mesh, and now it is working almost perfectly. Thanks!
Very nice! Could you add a wind effect such as Perlin noise to the top
Definitely. I intend to show a way to handle wind in the next video.
Can you turn up your application scale in the editor preferences. Even on full screen everything looks tiny
Cool technology, I hope to see them move in the end!
Thanks! Wind will be added very soon.
@@TechArtAlex will this be the cpu/gpu sample-able noise as discussed in the paper?
I've also been watching this: ua-cam.com/video/bp7REZBV4P4/v-deo.html
I plan on showing a pretty basic implementation for the wind, mostly to show how you should approach altering the grass blade to get the most out of the bezier. It will be perlin noise texture based - so the CPU could certainly read the texture but I'm not looking to streamline that further for now. Ultimately you could swap it for many different approaches as long as you stick to the core idea - which is to move the control points, not the verts directly.
Hey can i buy this grass project,please!
Is it possible to rotate the blades? It woud be cool to make flow paterns and stuf
Yes. The blade could be rotated using the rotate about axis node. You can also use a 3D bezier curve instead of a 2D curve. However, unless you need the rotation to change at runtime, it would be cheaper to handle rotation at build time such as by using PCG to set the desired transform based on whatever rules you want.
Bruh
nice!
Thanks!
keep em coming
Sure thing!