@@samuunnTianhe-2A can calculate the collision data of three of your next generation using its 33.86 PETAFLOPS. This is today's tech, I'm sure the gman simulating life got a beefier rig lmao
That looks really good, and I like that you explain the reasoning instead of just telling people what to do. And on top of that we get a fun presentation style. You deserve way more views with this talent.
Very well explained video. However, regarding the performance penalty, a 300x300 field has ~100 times the area of a 32x32 field so if that's what you had to do to get equivalent performance then it means this new method had a performance drop of 99%, not 90%. This just further pushes the importance of the culling method in the later section.
Very nice explanation and overall video👌🏻 Only thing I would like to throw in, is that you should always at least consider using two noises/ sinewaves for the animation of the grass. One for the bigger movement and one that is the kind of detail layer. (With different scroll speeds obviously 😄) This way you don’t have this „on off“ feeling that it does have with only one and gives a way nicer feeling when looking longer at it
An idea that's simpler and typically more performant than the vote+scan thing is to do an arena allocator using atomics. You initialize a global counter to zero, and for every thread that wants to put a grass in you say index = atomicAdd(counter, 1) -- and that's the output index. It does the same operation (well, not exactly since it doesn't preserve thread order). You can optimize this further by using ballot/subgroup-wide scan and only doing one global atomic add per warp/subgroup, and even further by also doing it for multiple elements at a time (so each thread loads and computes the culling for, say, 4 blades, then the subgroup does a scan, local indices are added to the global ones and out comes an index for each blade that wanted one). After all of this it's not really any simpler but it's pretty zoom zoom fast.
A trick you can do to render the same amount of grass as the 300x300 plane is to replace the high quality grass with the lower quality grass at a distance. Because one of the most notable downsides of using png grass is when you look down, only rendering that grass at a distance makes that impossible to do. :)
After seeing this I watched a GDC on ghosts of tsushima wind and grass. It would use bezier curves rather than a defined mesh. I believe this has the fault of the arc length being hard to constrain so the grass would shrink and grow as it swayed in the wind, but subtle enough movements make this hard to notice.
There's a thing called "Perspective Correction" that I've only seen so far in a Unity asset called "Stylized Grass". It stretches/rotates the grass mesh by some amount relative to the camera angle which camouflages the grass mesh quite well, up to a certain point when it's near perpendicular.
There is a great GDC talk on rendering grass in Ghost of Tsushima. That might provide you with some great insights. Also, I think you can get away with optimizing that blade of grass a bit more without losing visual fidelity too much.
I have an idea if you take the grass and create a version that is a single triangle This would be activated from a certain distance depending on the resolution There would be no way for you to realize that it is of worse quality Essentially a LOD system
This approach is so kookee ... no one else does it like this (the video, not the programming). At first I was all WHAT THE ACTUAL??? BUT IT IS AWESOME. I love it. so incredibly unique
Instead of using the scan and compact algorithm to copy the culled grass into a new buffer, it might be easier to just use an Append buffer to append the grass that survives the culling to an empty output buffer each frame. This means no scan or compact, however you do need a buffer the size of the worst case scenario which does have a larger memory impact
Someone else also brought up the append buffer, I'm not sure how I did a month of research and never read about it anywhere. I'm unsure how different the performance would be with an append buffer instead.
@@Acerola_t Same thing happened to me, and I just discovered this short video series after I almost finished my implementation lol. Using an append buffer should improve performance slightly, since you won't need the SAC algorithm to manage culling - just append to your output buffer and pass that to your shader (or however you manage instancing). Append buffers require a fixed size, but use a counter to determine how many indices in that buffer are occupied. So, each frame, you set the counter to 0 and let it fill up again. If you had all the grass in view, then zoomed in so the amount of grass that survives culling is smaller than the last frame, there will be data still in that buffer since it was not overwritten (the buffer's counter is smaller). This is fine, and those extra items are not rendered because the instancing shader will only instance objects up to the counter. So overall, marginally greater performance, and depending on how you implemented the SAC algorithm, slightly higher memory usage
Secondly, by "chunking" and using separate compute buffers for each chunk, you are increasing the amount of draw calls. On a large terrain with lots of chunks, you start to negate the benefits of instancing. Instead of using an append buffer for each chunk, I have a global buffer which holds every object. You can run the culling compute shader on every chunk and append the result into one buffer and send that buffer over to the shader which results in... One draw call :) Of course, with a LOT of objects you can fill the buffer, so it's probably more effective to create a list of buffers depending on how many objects can be rendered. For every X amount of chunks, create a new buffer and every subsequent chunk outputs into that one instead. That should minimize draw calls. Of course, more complex, and I don't know how far you're going with this project lol, but if anyone else is reading this it might help :)
hey dude great video!, i discovered your channel recently with the grass series, even though i'm a unreal engine developer i find all this stuff pretty intresting! cheers from Brasil!
i love that you not only present great info more generically, but also point out how youtube style game dev tutorials completely forget to talk about how its not optimal or even how to even approach optimizing.
Next step would be, instead of grass growing homogenously through the ground, make it so every 5 or so grasses share its position and extends in diferent directions forming a bush. And then add a static perlin texture to determine parts of the ground with more or less vegetation.
The frustum culling is really satisfying to look at in the scene view. Have you tried mesh LODs and fog? Looks like you can incur a ton of overlapping triangles at the sheer angles farther away. Anyway, cool video!
mesh LOD is going to be necessary for sure, just not sure how I want to implement it since I'll need to have an extra buffer for LOD grass positions. I'll be doing fog inevitably but I wanted it to be its own video. Thank you!
What if you use the last video's method as a "LOD" type thing since it will look better at further distances and will not have a large performance cost
Man... I'm fighting this whole week to make a descent grass in my project. It's funny how something like "oh, all the heavy work is done, let's just put grass here" became a quest through gpu buffers and pipeline shaders... (come on I'm just a programmer...). But your video helped me a lot to understand the dimension of the problem that I'm gettin into :') thanks !
Had a project where grass had a centerpiece. Gave up on it so fast because it was just not worth the effort. I'm happy to see that this video just confirms my suspicions back then 🥴
"If you look down on it from above, it's clearly just some squares." -> Finds a new way to render the grass -> Doesn't show the new result Nah I'm just joking, I know it looks ok-ish from the top because that's exaclty what I've done for my game lol. Btw let me know if you ever figure out how to make this grass run even faster. I'm planning to quadruple my map size in my new version, and I don't think It'll hold if I put anymore grass blades on the scene. I'm also starting to hit the memory limit with all these blades.
Haha when I was editing I realized I never showed the top down result, I can assure you it looks like the game Flower now since the base terrain blends with the AO color of the grass. My current plan to get it to run as fast as possible while covering an arbitrary area of terrain is with chunking and LOD, there is going to be a major memory cost to it but I calculated it out and the grass in this project only uses a few megabytes of data, this could also be optimized heavily with bitpacking and moving some calculations over to the shader. The scan buffers can be reused so each individual chunk of grass doesn't need its own scan buffers I think. Either way I'll figure it out by the time the next video comes out a week and a half from now. Thanks for watching!
hey man, i really love that you did this and shared your code to boot. I'm currently busy trying to implement a similar thing within unreal (cause for some reason unreal engine cuts off density of grass using the in-engine available tools at 1000 per 10 m^2. which is not enough to get a similar effect going.) Learning C++ it is. Your code is a really good starting point though, and i'm glad it is there as a reference.
Since you're looking at the grass at about eye height in-game, the further out you go, the more you're looking at the distance at grazing angles (and taking up less overall proportion of the screen space). Because of this, grass becomes increasingly obscured by other grass as it becomes more distant, and therefore in all likelihood you could get away with reducing the density of the grass gradually as it becomes further from the camera with very little noticeable difference but potentially a huge performance boost.
First time I saw your video I thought "WHO IS THIS CLOWN?", but actually it turns out being a video with a funny/oiginal/intentionally cringe format, with very good content. Very nice.
Nice video man! I know I'm a year late but, what about combining both techiques, this one and the one from the previous video? You could define a distance/radius of view, and everything inside this radius (near the camera) is rendered using the complex grass mesh, while everything outside the radius (far from camera) is rendered using the billboard textures. Then, as your player/camera moves the billboard textures get replaced by the meshes. It would work like some kind of custom LOD.
Thank you for an awesome video! But I found a bug about scan prefix calculation. At 8:56s, the scan array should be 0,0,1,2,2. This troubled me for a long time before I realized it was a small mistake in your video.
you could also propagate the index of the visible ones and the total number of visible Blades.Then you could renderer only the visible blades with drawindirect
After looking at a few of your videos about grass in video games, I have to say that I'm deeply impressed by your videos. The delivery and overall presentation works really well, and it makes your videos a really unique watching experience. I'm not surprised to see that this channel is seemingly starting to take off for real, because all it really needs at this point is some luck; the quality of the content is already here.
Subscribe'd. This is the good shit. Actually good, pro level info with no flashy logos or click bait or algo pandering garbage. It's like if Dimitri Martin went into 3d graphics.
Wouldn't this be more useful if we combined both techniques? I mean, you can still use billboards at distance as an LOD to save performance. Generally, I prefer to use only billboards but it comes with a cost. Overdraw I use unreal so the engine does part of the job like the culling by itself. What I generally do is to use a more dense billboard when the camera is close (like 4 to 5 planes with 2 or 3 loopcuts on it so it can bend with the wind) but as it goes further away I reduce the number of planes and loopcuts on the mesh. This way, you can bend the mesh by default on your 3d modelling tool so it doesn't look too straight when looking from above. The only thing that kinda remains a problem in this case is the overdraw as I said. But you can solve it by making a texture that covers most part of the mesh (or the oposite).
Bro literally i just found your channel and i literally learned more in last 30 mins than past few months. I am a developer mainly work on gameplay elements and AI, still completely noob when gomes to graphic programming. I really like the way you teach everythingand i really wanna learn all these things. Is there any chance that you planned for tutorial series completely from scratch for graphic programming.
Probably won't do a tutorial series like that, if you're interested in a good "from scratch" tutorial series for Unity shaders then I really recommend Jasper's tutorial series on rendering which goes over recreating Unity's standard built-in uber shader. catlikecoding.com/unity/tutorials/rendering/
Looking at the source for the scan/compact method, I really like the elegance of the solution, but not sure if I completely understand it, so let me explain it and tell me if I'm wrong, lol: First pass is simple, just create the true/false buffer with 1's and 0's using the GPU, one value for each grass position. Second pass, I think your visual is incorrect. The value of each position should be the sum of the values in the first pass up to that index in the buffer, so with a T/F buffer of: [0, 1, 1, 0, 1] the scan buffer should be: [0, 0, 1, 2, 2] rather than [0, 0, 1, 1, 2], which I think you just took from the notes (for a different input). Each index counts the number of T values in the T/F buffer before the current index. Third pass uses the first and second buffers to determine what values to copy and where, with logic that can be run in parallel thanks to that data, simply: if (tf_buffer[i] == 0) return; else { compact_index = scan_buffer[i]; compact_positions[compact_index] = position[i]; } What I don't quite get still is in step two, is the scan done on the CPU or the GPU? Because it seems like the most efficient way to do it would be to iterate through the T/F array and do something like "scan_buffer[i] = counter; if (tf_buffer[i]) ++counter;" but it _sounds_ like it's trying to do everything on the GPU in parallel, but that would mean that for each calculation in the scan_buffer it would have to iterate from [0 -> n) on the tf_buffer, which would be incredibly slow for later elements, especially with millions of grass blades. But to do the scan on the CPU it would first have to copy the TF buffer into CPU memory, and then the resulting scan buffer back into GPU memory, which maybe isn't really much of a problem? I supposed I could actually look at your code but that would be effort.
You are correct my example output for the scan was wrong. This is all done on the gpu, the vote/scan/compact is all done in parallel with optimal thread groups to distribute up the work accordingly. In order to do the scan on the cpu it would require copying all the memory back to the cpu as you said, which would defeat the point of the compute shader culling. Parallel prefix scan is a tough problem and a lot of work has gone into optimizing it which is funny cause it's extremely trivial to do on the cpu.
@@Acerola_t - where in your code is the prefix scan actually happening? I did end up taking a look but can't find anything that looks like the scan/compact logic in the compute shader code. I'd like to see how it's actually being done because I still don't really see how it's getting calculated in parallel, haha.
@@Acerola_t - Oh, the first file in the directory - I'll maintain that it didn't exist and you snuck it in there, editing git's history :P Thanks for the link! e: wow, this makes very little sense, lol - looks like I'll be taking a look at GPU Gems.
could do a series of lower LOD blades using lower vertices dependent on distance to camera. The reason I say a series of rather than just having the lowest model at a further distance i think it would save comp cost by transitioning to lower details sooner yet more subtly like a gradient if that makes sense.
this might be a waste of time, but since the grass is so uniform (it's pretty much just a grid), you might be able to use the gpu to sort the individual blades in a way to reduce overdraw, and if that's too slow, you could instead rotate each tile of grass (by multiples of 90 degrees) so that the first triangles are always closer to the camera, then pull the actual blade positions from a texture. also, octagedral billboards are cool as fuck. they're like the flat billboards, but 3d
what if you introduced distance based detail culling like you mentioned in the previous grass video, make the closer grass bits these new 3d ones, and the ones beyond the culling range billboard grass?
I would love to see a video where you do Fortnite style grass. Theirs is REALLY fast and all the animation is done in the texture itself based on wind speed. Cool stuff
Is there a way to decrease the amount of grass the further from the camera it is? Is there a way to render simpler grass when it is only a few pixels tall?
I love these vids. Super informative and the whole stand-up and talk thing is legit lit.....but honestly I think like halfway through you should cut out more of the "you" and show more of the task doing.....just constructive criticism but you straight up lit bro...def got my sub ftw.
We just use an AppendStructuredBuffer to only render grass instances that are in view instead of these scan & compact shenanigans - seems overly complicated to me
Vote/Scan/Compact is a very common algorithm so it's not overly complicated at all lol There's surprisingly little information about append structured buffers on the internet, I'll have to try it out on my own and compare the performance. Have you benchmarked it at all?
@@Acerola_t I have not benchmarked it so far, but so far we haven't had any trouble regarding performance. I imagine it could be faster than the Vote/Scan/Compact stuff since it doesn't require multiple passes. Sebastian Lagues video about GPU-based Marching Cubes might provide some info - he also used an AppendBuffer to append vertices to a buffer. In this use case you would just add the instances that should be rendered to an AppendBuffer.
I would totally appreciate for you telling me how those 'marble' like textures at around 5:15 were formed by adding noise to those sin waves. Imho, The swirls are not possible with just the basic random hash function, yes? So something like perlin noise was used by you? Thanks and I love your content, man!!
![Jack Harlow - Hello Miss Johnson [Official Music Video]](http://i.ytimg.com/vi/Q86_nlRoIGw/mqdefault.jpg)
![[#2024MAMA] ROSÉ (로제), Bruno Mars - APT. | Mnet 241122 방송](http://i.ytimg.com/vi/dgGqD28J6aQ/mqdefault.jpg)
Can we just appreciate how the real life world just instantiates infinite grass every frame
touch grass
It runs all of quantum mechanics and relativity too!
@@lih3391relativity is just lag, come on now.
@@cvspvr it would have to calculate the physics and my hand collision (100% accurate) so idk it's too much power
@@samuunnTianhe-2A can calculate the collision data of three of your next generation using its 33.86 PETAFLOPS. This is today's tech, I'm sure the gman simulating life got a beefier rig lmao
The grass in Zelda is actually only 2 tris, also it turns into even simpler 1 sided billboards at a distance around the edge of the camera
wait then how does each grass bend tho if they don't have any vertice to manipulate in between
@@bbuskabuske
I guess they use shaders similar to gta, moves the bushes Using a 2d fisheye filter
@@srqubit9480 - That, or the grass on the billboard is actually procedurally animated within its "texture"?
@@KingBobXVI I was talking about 3d grass
For 2d grass if it can be animated for 3d it requires too many polygons which lags and a lot
May I ask where you got this information? I would really move to read about how Breath of the Wild’s grass works!
I imagine using the billboard technique for far away grass would help get grass to appear far away since you won't notice it being a square.
That looks really good, and I like that you explain the reasoning instead of just telling people what to do. And on top of that we get a fun presentation style. You deserve way more views with this talent.
I have been watching your grass series and never realized you had less than 1,000 subscribers. You are totally underated! Great stuff!
Damn
watching this 2 months after your comment, acerola now has 35.400 subscribers! :)
@@KYL3R64 only a year after sitting at 110k lmao
136k @@TU7OV
@@perelium-x 137!
Very well explained video. However, regarding the performance penalty, a 300x300 field has ~100 times the area of a 32x32 field so if that's what you had to do to get equivalent performance then it means this new method had a performance drop of 99%, not 90%. This just further pushes the importance of the culling method in the later section.
Glad to find a fellow grass enjoyer. Excited to see more grass related content soon!
Very nice explanation and overall video👌🏻
Only thing I would like to throw in, is that you should always at least consider using two noises/ sinewaves for the animation of the grass. One for the bigger movement and one that is the kind of detail layer. (With different scroll speeds obviously 😄) This way you don’t have this „on off“ feeling that it does have with only one and gives a way nicer feeling when looking longer at it
That's a great tip, I'll be sure to do that next time i redo the grass animation
An idea that's simpler and typically more performant than the vote+scan thing is to do an arena allocator using atomics. You initialize a global counter to zero, and for every thread that wants to put a grass in you say index = atomicAdd(counter, 1) -- and that's the output index. It does the same operation (well, not exactly since it doesn't preserve thread order). You can optimize this further by using ballot/subgroup-wide scan and only doing one global atomic add per warp/subgroup, and even further by also doing it for multiple elements at a time (so each thread loads and computes the culling for, say, 4 blades, then the subgroup does a scan, local indices are added to the global ones and out comes an index for each blade that wanted one). After all of this it's not really any simpler but it's pretty zoom zoom fast.
A trick you can do to render the same amount of grass as the 300x300 plane is to replace the high quality grass with the lower quality grass at a distance. Because one of the most notable downsides of using png grass is when you look down, only rendering that grass at a distance makes that impossible to do. :)
This looks really good! and I'm super excited to see more optimization techniques.
Thanks! Going to be testing several solutions in the next week to get proper area coverage without performance loss.
I cannot remember if you did this but to improve performance you could use lower LODs on grass which is further away
I do that in the next vid yeah, it doesnt actually give much of a performance boost surprisingly.
@@Acerola_t yes it does
@@kgaming7599 I literally made it so I know how much of a performance boost it gave
@@Acerola_t skill issue
@@kgaming7599 ratio + lack of female companions + didn't ask + no one cares
I'm surprised this channel doesn't have more subscribers. Great content!
After seeing this I watched a GDC on ghosts of tsushima wind and grass. It would use bezier curves rather than a defined mesh. I believe this has the fault of the arc length being hard to constrain so the grass would shrink and grow as it swayed in the wind, but subtle enough movements make this hard to notice.
I knew a youtuber about video game grass was what I needed.
And now I finally found them.
There's a thing called "Perspective Correction" that I've only seen so far in a Unity asset called "Stylized Grass". It stretches/rotates the grass mesh by some amount relative to the camera angle which camouflages the grass mesh quite well, up to a certain point when it's near perpendicular.
That's called parallax
ok you are so underrated
B)
There is a great GDC talk on rendering grass in Ghost of Tsushima. That might provide you with some great insights. Also, I think you can get away with optimizing that blade of grass a bit more without losing visual fidelity too much.
I have an idea
if you take the grass and create a version that is a single triangle
This would be activated from a certain distance depending on the resolution There would be no way for you to realize that it is of worse quality
Essentially a LOD system
This approach is so kookee ... no one else does it like this (the video, not the programming). At first I was all WHAT THE ACTUAL??? BUT IT IS AWESOME. I love it. so incredibly unique
Instead of using the scan and compact algorithm to copy the culled grass into a new buffer, it might be easier to just use an Append buffer to append the grass that survives the culling to an empty output buffer each frame. This means no scan or compact, however you do need a buffer the size of the worst case scenario which does have a larger memory impact
Someone else also brought up the append buffer, I'm not sure how I did a month of research and never read about it anywhere. I'm unsure how different the performance would be with an append buffer instead.
@@Acerola_t Same thing happened to me, and I just discovered this short video series after I almost finished my implementation lol. Using an append buffer should improve performance slightly, since you won't need the SAC algorithm to manage culling - just append to your output buffer and pass that to your shader (or however you manage instancing).
Append buffers require a fixed size, but use a counter to determine how many indices in that buffer are occupied. So, each frame, you set the counter to 0 and let it fill up again. If you had all the grass in view, then zoomed in so the amount of grass that survives culling is smaller than the last frame, there will be data still in that buffer since it was not overwritten (the buffer's counter is smaller). This is fine, and those extra items are not rendered because the instancing shader will only instance objects up to the counter.
So overall, marginally greater performance, and depending on how you implemented the SAC algorithm, slightly higher memory usage
Secondly, by "chunking" and using separate compute buffers for each chunk, you are increasing the amount of draw calls. On a large terrain with lots of chunks, you start to negate the benefits of instancing.
Instead of using an append buffer for each chunk, I have a global buffer which holds every object. You can run the culling compute shader on every chunk and append the result into one buffer and send that buffer over to the shader which results in... One draw call :)
Of course, with a LOT of objects you can fill the buffer, so it's probably more effective to create a list of buffers depending on how many objects can be rendered. For every X amount of chunks, create a new buffer and every subsequent chunk outputs into that one instead. That should minimize draw calls. Of course, more complex, and I don't know how far you're going with this project lol, but if anyone else is reading this it might help :)
hey dude great video!, i discovered your channel recently with the grass series, even though i'm a unreal engine developer i find all this stuff pretty intresting! cheers from Brasil!
Learning grass programming in games with some John Lennon looking modafoca. Nice 👌
You definetly need more subs, thank you for the work you made!
i love that you not only present great info more generically, but also point out how youtube style game dev tutorials completely forget to talk about how its not optimal or even how to even approach optimizing.
You are phenomenal. I would love some more in depth code explanations
I didn't think I'd be watching John Lennon teach me about video game grass rendering techniques today, but I'm not mad.
Dude your seriously underrated
Keep posting videos I love it a lot
Next step would be, instead of grass growing homogenously through the ground, make it so every 5 or so grasses share its position and extends in diferent directions forming a bush.
And then add a static perlin texture to determine parts of the ground with more or less vegetation.
underrated as hell
Ok now I have to see the complete serie about grass rendering.
I would’ve never expected to see slime in a video about 3d modeling grass but here we are
The frustum culling is really satisfying to look at in the scene view. Have you tried mesh LODs and fog? Looks like you can incur a ton of overlapping triangles at the sheer angles farther away. Anyway, cool video!
mesh LOD is going to be necessary for sure, just not sure how I want to implement it since I'll need to have an extra buffer for LOD grass positions. I'll be doing fog inevitably but I wanted it to be its own video.
Thank you!
What if you use the last video's method as a "LOD" type thing since it will look better at further distances and will not have a large performance cost
Man... I'm fighting this whole week to make a descent grass in my project. It's funny how something like "oh, all the heavy work is done, let's just put grass here" became a quest through gpu buffers and pipeline shaders... (come on I'm just a programmer...). But your video helped me a lot to understand the dimension of the problem that I'm gettin into :') thanks !
foliage is probably top 3 hardest problems in graphics lol
Now that looks sick. Awesome job, nice grass.
Excellent job sir. Unbelievable how complicated these 3d optimisations are
why is he john lennon
I can't get enough of your videos!
Had a project where grass had a centerpiece. Gave up on it so fast because it was just not worth the effort. I'm happy to see that this video just confirms my suspicions back then 🥴
Thanks, I learned a lot in this vid, keep up the good work!
Absolutely rockin those shades man
"If you look down on it from above, it's clearly just some squares."
-> Finds a new way to render the grass
-> Doesn't show the new result
Nah I'm just joking, I know it looks ok-ish from the top because that's exaclty what I've done for my game lol.
Btw let me know if you ever figure out how to make this grass run even faster. I'm planning to quadruple my map size in my new version, and I don't think It'll hold if I put anymore grass blades on the scene. I'm also starting to hit the memory limit with all these blades.
Haha when I was editing I realized I never showed the top down result, I can assure you it looks like the game Flower now since the base terrain blends with the AO color of the grass.
My current plan to get it to run as fast as possible while covering an arbitrary area of terrain is with chunking and LOD, there is going to be a major memory cost to it but I calculated it out and the grass in this project only uses a few megabytes of data, this could also be optimized heavily with bitpacking and moving some calculations over to the shader. The scan buffers can be reused so each individual chunk of grass doesn't need its own scan buffers I think. Either way I'll figure it out by the time the next video comes out a week and a half from now.
Thanks for watching!
@@Acerola_t That's cool, I might be able to implement what you did in my own game if you succeed!
i really cant get enough of the grass ive watched this video like 5 times trying to implement my own
bro, don't know how did i find your channel, but it's great and it will blow up
This content is very high quality.
Monogatari references follow me everywhere, no matter the subject. What a delight
Where
@@HilbertXVI 8:15. Also im pretty sure the channel name (and maybe the intro at 1:07 but that might be stretching)
Acerola is so Brazilian nickname. Love it.
hey man, i really love that you did this and shared your code to boot. I'm currently busy trying to implement a similar thing within unreal (cause for some reason unreal engine cuts off density of grass using the in-engine available tools at 1000 per 10 m^2. which is not enough to get a similar effect going.) Learning C++ it is. Your code is a really good starting point though, and i'm glad it is there as a reference.
The best tradeoff between performance/fidelity would probably be a blend of basic billboard grass with a small radius of the per-blade rendering.
goddamn, that reveal at 6:00 is sick af
Since you're looking at the grass at about eye height in-game, the further out you go, the more you're looking at the distance at grazing angles (and taking up less overall proportion of the screen space).
Because of this, grass becomes increasingly obscured by other grass as it becomes more distant, and therefore in all likelihood you could get away with reducing the density of the grass gradually as it becomes further from the camera with very little noticeable difference but potentially a huge performance boost.
It's hard to do that since the grass positions are pre-computed and not generated in real time.
@@Acerola_t I will say as a 36 year-old 15+ year game dev Old Person, there are a few ways to accomplish this. I believe in you. ;)
I would think the next step is to set up an LOD switch after a few meters where you switch back to rendering the cheaper non-modelled grass.
First time I saw your video I thought "WHO IS THIS CLOWN?", but actually it turns out being a video with a funny/oiginal/intentionally cringe format, with very good content. Very nice.
Nice video man!
I know I'm a year late but, what about combining both techiques, this one and the one from the previous video?
You could define a distance/radius of view, and everything inside this radius (near the camera) is rendered using the complex grass mesh, while everything outside the radius (far from camera) is rendered using the billboard textures.
Then, as your player/camera moves the billboard textures get replaced by the meshes. It would work like some kind of custom LOD.
those wind sound effects you use give me big naustalgia hits from dark cloud
why is john lennon teaching me about graphics processing
Thank you for an awesome video! But I found a bug about scan prefix calculation. At 8:56s, the scan array should be 0,0,1,2,2. This troubled me for a long time before I realized it was a small mistake in your video.
oops! Yeah these older vids i edited in one or two nights so some errors have slipped in.
"maybe i could eat blades of grass"
-bill wurtz
you could also propagate the index of the visible ones and the total number of visible Blades.Then you could renderer only the visible blades with drawindirect
Never thought I'd be lectured on grass by Adrien Brody but here we are
After looking at a few of your videos about grass in video games, I have to say that I'm deeply impressed by your videos. The delivery and overall presentation works really well, and it makes your videos a really unique watching experience. I'm not surprised to see that this channel is seemingly starting to take off for real, because all it really needs at this point is some luck; the quality of the content is already here.
Thanks!
i know nothing about most of what your saying but the video was still dope :)
Thanks!
Persona 3 music. Very nice
you know this guy is sempai when he continually uses persona OST
Subscribe'd. This is the good shit. Actually good, pro level info with no flashy logos or click bait or algo pandering garbage. It's like if Dimitri Martin went into 3d graphics.
awesome stuff
you could use the grass from this video near the player and the grass from the last video as lod.
Wouldn't this be more useful if we combined both techniques? I mean, you can still use billboards at distance as an LOD to save performance. Generally, I prefer to use only billboards but it comes with a cost. Overdraw
I use unreal so the engine does part of the job like the culling by itself. What I generally do is to use a more dense billboard when the camera is close (like 4 to 5 planes with 2 or 3 loopcuts on it so it can bend with the wind) but as it goes further away I reduce the number of planes and loopcuts on the mesh. This way, you can bend the mesh by default on your 3d modelling tool so it doesn't look too straight when looking from above. The only thing that kinda remains a problem in this case is the overdraw as I said. But you can solve it by making a texture that covers most part of the mesh (or the oposite).
I'm surprised frustum culling every single blade of grass on the CPU every frame in one big linear scan didn't actually make it more expensive.
on the GPU not on the CPU lol if I was processing millions of objects on the cpu each frame there would be less than zero frames a second
I actually like the billboard grass better stylistically. The only problem would be figuring out how to get it to work when you face down.
Bro literally i just found your channel and i literally learned more in last 30 mins than past few months. I am a developer mainly work on gameplay elements and AI, still completely noob when gomes to graphic programming. I really like the way you teach everythingand i really wanna learn all these things. Is there any chance that you planned for tutorial series completely from scratch for graphic programming.
Probably won't do a tutorial series like that, if you're interested in a good "from scratch" tutorial series for Unity shaders then I really recommend Jasper's tutorial series on rendering which goes over recreating Unity's standard built-in uber shader.
catlikecoding.com/unity/tutorials/rendering/
@@Acerola_t Thanks for this.
Can you suggest more resources which teach graphic programming from scratch
really nice grass
That vote-totalling culling method clicked like 0.5s after the end of the video, makes me feel like maybe I'm not a total fraud lol
Looking at the source for the scan/compact method, I really like the elegance of the solution, but not sure if I completely understand it, so let me explain it and tell me if I'm wrong, lol:
First pass is simple, just create the true/false buffer with 1's and 0's using the GPU, one value for each grass position.
Second pass, I think your visual is incorrect. The value of each position should be the sum of the values in the first pass up to that index in the buffer, so with a T/F buffer of:
[0, 1, 1, 0, 1] the scan buffer should be:
[0, 0, 1, 2, 2] rather than [0, 0, 1, 1, 2], which I think you just took from the notes (for a different input). Each index counts the number of T values in the T/F buffer before the current index.
Third pass uses the first and second buffers to determine what values to copy and where, with logic that can be run in parallel thanks to that data, simply:
if (tf_buffer[i] == 0) return; else { compact_index = scan_buffer[i]; compact_positions[compact_index] = position[i]; }
What I don't quite get still is in step two, is the scan done on the CPU or the GPU? Because it seems like the most efficient way to do it would be to iterate through the T/F array and do something like "scan_buffer[i] = counter; if (tf_buffer[i]) ++counter;" but it _sounds_ like it's trying to do everything on the GPU in parallel, but that would mean that for each calculation in the scan_buffer it would have to iterate from [0 -> n) on the tf_buffer, which would be incredibly slow for later elements, especially with millions of grass blades. But to do the scan on the CPU it would first have to copy the TF buffer into CPU memory, and then the resulting scan buffer back into GPU memory, which maybe isn't really much of a problem? I supposed I could actually look at your code but that would be effort.
You are correct my example output for the scan was wrong.
This is all done on the gpu, the vote/scan/compact is all done in parallel with optimal thread groups to distribute up the work accordingly. In order to do the scan on the cpu it would require copying all the memory back to the cpu as you said, which would defeat the point of the compute shader culling. Parallel prefix scan is a tough problem and a lot of work has gone into optimizing it which is funny cause it's extremely trivial to do on the cpu.
@@Acerola_t - where in your code is the prefix scan actually happening? I did end up taking a look but can't find anything that looks like the scan/compact logic in the compute shader code. I'd like to see how it's actually being done because I still don't really see how it's getting calculated in parallel, haha.
@@KingBobXVI github.com/GarrettGunnell/Grass/blob/main/Assets/Resources/CullGrass.compute
@@Acerola_t - Oh, the first file in the directory - I'll maintain that it didn't exist and you snuck it in there, editing git's history :P
Thanks for the link!
e: wow, this makes very little sense, lol - looks like I'll be taking a look at GPU Gems.
could do a series of lower LOD blades using lower vertices dependent on distance to camera. The reason I say a series of rather than just having the lowest model at a further distance i think it would save comp cost by transitioning to lower details sooner yet more subtly like a gradient if that makes sense.
Guess I'm gonna go learn like 6 more levels of math then come back here later
The Huniepop soundtrack RULES
this might be a waste of time, but since the grass is so uniform (it's pretty much just a grid), you might be able to use the gpu to sort the individual blades in a way to reduce overdraw, and if that's too slow, you could instead rotate each tile of grass (by multiples of 90 degrees) so that the first triangles are always closer to the camera, then pull the actual blade positions from a texture. also, octagedral billboards are cool as fuck. they're like the flat billboards, but 3d
Peak nerd programmer right there, good content
my brother in Christ looks like AJ Jackson, the band leader of Saint Motel
"How do we fix this, well, with doctor thesis level algorithms of course" sent me 🤣🤣🤣😂😂😂🤣
what if you introduced distance based detail culling like you mentioned in the previous grass video, make the closer grass bits these new 3d ones, and the ones beyond the culling range billboard grass?
Awesome
>So how do we fix this?
By using the expensive method up close and the cheap one farther away?
John lennon is back
🤯
awesome
I would love to see a video where you do Fortnite style grass. Theirs is REALLY fast and all the animation is done in the texture itself based on wind speed. Cool stuff
Is there a way to decrease the amount of grass the further from the camera it is? Is there a way to render simpler grass when it is only a few pixels tall?
Yeah you could do that
@@Acerola_t It would be tricky to implement, but could save on system resources in some scenarios.
I was just wondering why you chose Maya instead of Blender that doesn't require you to fib a little?
Cause Maya is industry standard there's really no other reason. I use blender too when I feel like it.
I love these vids. Super informative and the whole stand-up and talk thing is legit lit.....but honestly I think like halfway through you should cut out more of the "you" and show more of the task doing.....just constructive criticism but you straight up lit bro...def got my sub ftw.
I didnt expect fucking Jhon Lenon to teach me how to render gras real time,
It's still pretty
1:40 Pro tip: B L E N D E R
We just use an AppendStructuredBuffer to only render grass instances that are in view instead of these scan & compact shenanigans - seems overly complicated to me
Vote/Scan/Compact is a very common algorithm so it's not overly complicated at all lol
There's surprisingly little information about append structured buffers on the internet, I'll have to try it out on my own and compare the performance. Have you benchmarked it at all?
@@Acerola_t I have not benchmarked it so far, but so far we haven't had any trouble regarding performance. I imagine it could be faster than the Vote/Scan/Compact stuff since it doesn't require multiple passes. Sebastian Lagues video about GPU-based Marching Cubes might provide some info - he also used an AppendBuffer to append vertices to a buffer. In this use case you would just add the instances that should be rendered to an AppendBuffer.
Acerola Orion Heart Underblade
That is where the name comes from ye
@@Acerola_t W
I would totally appreciate for you telling me how those 'marble' like textures at around 5:15 were formed by adding noise to those sin waves.
Imho, The swirls are not possible with just the basic random hash function, yes? So something like perlin noise was used by you?
Thanks and I love your content, man!!
Nice video, i wish he had more content in shaders and stuff like this. A hint for you, try to not cut your head out of the frame.
Yeah I didnt have the chance to re record so i just went with it lol
I didn't understand shit, but looks smart
pro tip: turn on the closed captioning