Thank you chunks :)

my mans out here sharing the secrets of AAA grass like it's no big deal. great work man, you're clearly very knowledgeable.

Some things you can do to further optimize this,Instead of having a single blade per unit of grass have multiple, This means you have significantly fewer objects to render. Also over distance start randomly calling The shorter blades, they are very unlikely to be seen so you can just remove those. This removes the harsh edge as well because we are slowly fading in the grass instead of there being a harsh line all of a sudden. Also put most of your detail at the top of the blade and less at the bottom, we’re not very likely to see the bottom of the blade because of the blades in front of it. Greets someone who spent too much time on game foliage.

Have you thought about replacing far-away grass clumps with the first method (quad+texture)? This would probably work way better with the GPU instance positions being relative to the camera. Great vids btw :)

You can use a division structure(think 1 chunk has 4 sub chunks that each have 4 sub chunks) then frustum cull the chunks instead of individual blades for way faster culling.

You actually don’t even need the whole mesh past a few meters. Instead of swapping it out for an entire lower mesh count model, you can just plug in the grass tops, on top of this past a certain distance you don’t even have to apply a skew, as you can only see the tips just revert back to a simple lateral translation.

A thought occurred to me when culling and chunks were mentioned. Would it be possible to further optimize by reducing the number of grass blades relative to distance each chunk is from the camera? While this may not reduce overall GPU load considering the extra calculations it could at the very least extend the range of which grass is visible, while simultaneously allowing for a gradient fall-off, which eliminates the need for a fog that could obstruct distant objects like mountains or buildings.

Thank you chunks! I have no idea how hard it would slow things down but one subtle thing that makes grass look like grass is that it is not just darker at the bottom than the top, but also darker in the middle than at the edge and darker on one side than the other. You definitely don't see this shading nearly as often as the kind you did, but I have no idea whether it's too slow, or if it's just not something people think about.

This is similar-ish to what I did several years ago on a shipped game. I used a precomputed quadtree rather than chunks because the area of coverage was known and the frustum test was just iterating over the blades of the visible nodes and copying them to the final instance buffer (no scan and compact, just directly from one to the other). It populated an indirect draw structure at the same time so the whole thing was essentially two calls (compute dispatch + indirect draw). Another way of hiding the end of the grass is to reduce the height of the blades in the vertex shader as they approach the far distance. If your grass is a similar color to the terrain you can't see where it ends and then you also don't need fog. A decent memory savings was also only place one tile of grass blades and treat the chunks as an instance of that base tile and then expand things out in the visibility pass.

Great video. I see that other people have already mentioned using billboards at distance, but there are some other, intermediate optimizations that I think you could use as well. Just as a thought experiment, I know you're no longer working on this. - The GDC talk on the grass in Ghost of Tsuhsima widens the grass at further distances while drawing fewer blades. They make the blades twice as wide for half as many blades. While they generate their grass blades in the geometry shader, this should still be possible with the 3d models you are using in the vertex shader. - The same GDC talk mentions how they use a grass model that forms a V, which gives them more coverage with fewer blades. It will make the grass look different, though. I read through the shader code for the grass and there's a number of smaller optimizations that could be employed. I don't know if they would actually do any good, and the compiler may even do them for you, but they could be worth trying out just to see. - You use "v.uv.y * v.uv.y" three times in the vertex shader, twice in "_Scale * v.uv.y * v.uv.y". If you put them into a temporary variable the GPU would keep them in a register rather than computing them every time they're needed. - RotateAroundXInDegrees and RotateAroundYInDegrees are fairly expensive functions, but much of that stuff can either be pre-computed or computed once (per vertex). RotateAroundXInDegrees is only called once, with a constant value passed into "Degrees". You can store 'm' as a constant since it never, ever changes. RotateAroundYInDegrees is similar, the m for idHash * 180.0 only needs to be computed once per vertex. - You can inline the RotateAround_InDegrees functions to avoid the overhead from function calls. - floating point arithmetic is non-associative, which means optimizations that may be obvious won't be performed by the compiler because you won't get exactly the same answer. UNITY_PI / 180.0 should just be a constant, but in order to tell the compiler that you have to put it in parathesis, or just #define a constant. - If you put positionBuffer[instanceID].displacement into a temporary variable, you'll be telling the compiler to load the value into a register rather than reading from cache, or worse, vram, every time it needs it. - There are likely some code motion optimizations to be made, particularly in concert with the above, but I don't know enough about the hardware or compiler to really give many good recommendations for it. I will say that putting all of the positionBuffer[instanceID] calls next to each-other improves temporal locality and may have an effect on performance. As I mentioned, a lot of this stuff may not even help. It's all very much "try it and see". The compiler may already do most/all of this already and so the end result is just making your code impossible to maintain to get an extra 3 fps. There's also Amdahl's law. I may be focusing all of this attention on some parts of the procedure that take up 1/10 of the actual execution time.

awesome demo, in breath of the wild, the "high poly" grass is only two triangles, in an elongated diamond shape and it still looks good, I wonder how much of a performance boost that would give your version?

With all this new knowledge on video game grass (which is not something I expected life to bring to me but I'm not mad) I feel the urge to make an open world that's just a grassy field. A really really nice grassy field.

This is great because you're optimising the grass based on the worst case scenario. I think the point you made at 7:35 is important, your actual game world is probably never going to have a scene with that much grass in a single frame. Come to think of it, the only area of BotW with that level of grass density is Hyrule field, but its important to note that there is almost nothing else populating Hyrule field.

I was looking into how to make grass and I did *not* expect to get a full video series on it. Thanks for this super handy resource!

I found your channel recently and all I can say is, it's so knowledgeably chill. Thanks

i genuinely love how much i learn from these videos and how entertaining and casual they are

Was just about the make some sexy grass for my game. Thanks for the tips and have a great day!

Thank you chunks (: These videos are genuinely fascinating

Really good video! This has made me really interested in learning compute shaders. I can't wait to see what topic you cover next.

This is cool, you could probably optimize it further by combining your billboard grass with meshed grass and using the billboard ones at longer distances.

Nice video, it looks amazing 💙

your videos are so good, it blew the power to my house. but i'm back and digging on the smooth sounds.

Is there a way to make this grass interact with physics objects? Like leaving a tire trail with a car.

This was a very nice 45 minute journey through grass. I love that you still respond to comments on nearly 2 year old videos.

I doubt it matters to say this at this point, but I think another option for covering up the fact that you're culling the far-away grass is to simply color the ground the same as the grass. At that distance, I doubt you would even notice that the grass stopped existing. If the animation of the grass changes the color of it enough to give it away, you might also consider applying an animation to the ground itself to match the change. I say this because although fog is very common is games, it makes sense to strongly consider other options before using it given how it destroys any hope of viewing landmarks or terrain in the distance. Standing on top of a hill and looking out to the surrounding terrain and having it fill you with a sense of awe and wonder is very desirable effect, and cutting corners elsewhere to achieve this effect is often worth it. Good video and I'll look forward to any new content.

Awesome videos!

I have never been so invested into a story in my life. This is better then any show out there.

Hi! I've been subscribed for a couple of days, and I'm loving your tutorials. You give just the right amount of detail needed to make it both fun to watch, easy to understand and follow along, I think you'd be a great teacher :) I'd like to ask something though, if you don't mind. What technologies/programs/ides do you use in your videos? You inspired me, and I want to start developing a game, just for fun and to see what happens! :D

I'm very happy I found this channel. Others are only really entertaining and fun I guess, but the real genius of game development is far more interesting. It also helps that your presentation is witty and concise. As a casual gamer and professional procrastinator I find this all super cool. :)

You could probably save a lot of that memory by having the grass procedurally generated, so the memory would only be used for a brief period of time, but then the procedural generation would have to be extremely fast in order to not hinder the rendering performance if calculated per-frame. Nice explanation of how it all comes together to make grass like this possible.

amazing video bro keep it up

Worked! What an absolute genius mad lad! Was so easy

Thanks for the video. In case it helps anyone, I was able to triple the framerate for the geometry grass shader simply by pulling in keijiro's latest noise include and using the 2D simplex version instead of the 3D snoise which is overkill since the Y isn't required.

Great series! I learned a lot. Could you save space by rendering multiple blades per position? For example, one position could have 3-4 off shoots. Also, not sure if this will make a difference, depending on hilly-ness your maps, the grass could skip rendering on the downslope side of the hill.

Would be cool to see another intermediate LOD where it goes back to the textured quad approach for anything more than ~10m away. Would be near indistinguishable since it only looks bad when viewed from directly above, and unless you have an ortho camera that spot would be covered by the better grass. Might eliminate the need for fog.

This might have been the best video I've seen on anything shaders related.

No doubt someone has already said this, but you might be able to use a mesh with more blades of grass and decrease the density. Sure, each mesh would have more polygons, but you'd be keeping a track of way less meshes, no doubt making it cheaper on the GPU's VRAM. You could also put less blades of grass into the lower LOD meshes to make a smoother transition between the grassed and grassless areas. Oh and you could use billboards at a distance too. Not like anyone would notice.

thank you chunks! what a kind fellow

Thank you chunks!!!

I kept expecting at some point that you'd have a radius around the camera outside of which there weren't individual blades of grass, but just like a blob disguised as grass. Kinda like you did where you stopped drawing the grass altogether at a certain radius, but colored the same color as the grass rather than brown.

Thank you chuncks!!

You're like Dani, but actually enjoyable to watch

Hi. I love your videos! I downloaded this grass project to play around with it a bit and understand everything in more detail. The grass culling is quite expensive. If I only cull every 5th frame, the FPS increases from ~270 to ~440, and if I don't cull at all, I can get to around ~480. At those frame rates I've found it's very difficult to see the lack of culling for 4 frames unless the camera moves/rotates extremely fast. If we can link the camera to the grass and only cull every second or third frame while the camera view is changing, we can actually get a considerable FPS boost.

Hoping you follow this up by adding ghost of tsushimas grass stuff, rounded normal for the grass blades to hide that it's 2D, varying height, shorter glass blades are converted into 2 blades to to make use of the vertices and add density

you can actually put a bit of sampling in the pixel shader, a bit like parallax occlusion mapping (Look it up, its a common method ppl employ) and u can actually develop a shadow from it, instead of the displacement map, and it will shadow it all into the distance! would definitely make it look cooler. Parallel occlusion mapping actually is the first raytracing type method ppl did on the gpu. Realtime.

I know you said you wanted to be done with the grass, but I'm curious: is it possible to have objects (players and NPCs) effect the grass movement in a performant way? (flattening or making it shake as it's moved through) I've seen other tutorials on this for snow and grass using a displacement texture but I'd be curious to know if it works with this grass technique

I wonder if some of the optimizations used to render hair could also be used to render grass. Or if people working on grass optimization also used those to render better hair, fur, etc., because they're similar problems of "render a lot of this thing protruding from this other thing" except with hair the "other thing" may be moving.

wow thx man

Perlin noise texture input for grash splat map and you have one helluva grass shader ^-^ Basically no real scene needs that much grass everywhere so yeah this is pretty great!

Optimization is my favorite topic you cover

Thank you chunks!

damn bruh. Thats exactly the type of nerdy computer graphics stuff i dig. Im in no way close to coding my render engine, but i work in Houdini and instancing grass here is pain in the ass too.

This would be very useful for a mysterious, serene, foggy field in an experimental indie horror game which appears in two scenes for no apparent reason, and then places you back in the game, just to make you question whether what you're experiencing is *supposed* to be coherent or not.

You can also look which grass is covered more than 3/5 and exchange it with the middle class model or if it is a bit further away even use the lowest model. And also gras which can't be seen because other grass blocks the view can be taken off alltogether but for this you have to take the hight and position into account.

Thank you, chunks! :)

underrated videos

Didnt realize a video about John Lenon talking about the grass could be so fun and educational. But I honestly didn't think you'd Reincarnate till Yoko was gone.

Thank you chunks! Could you reduce the memory cost if you store only the Ids for referencing the blades from the first buffer inside the second buffer?

I NEED MORE GRASS VIDEOS

Thank u chunks

YOur channel got boosted by youtube, and I'm lucky enough to see it here! Anyways, for grass that far, I'd probably just clump a few sprites on that plane altogether with some noise, maybe that owuld save some precious memory :)

Great content. Question for your brave soul: have you yet traversed the depths of hell known as optimizing for standalone VR devices?

very cool grass

Since the grass is now stored in chunks (I also saw someone suggesting using quadtrees for better, more fine-grained culling), you maybe don't need to store as much data on the leaves' positions. Let the chunk itself store its world coordinates; let the leaves' positions be defined relative to the chunk. That way, you might be able to store what's currently floats it as a 1-byte integer or something. I saw this technique used in a video about a voxel-based game engine, but I'm thinking that it could work in any scenario with a well-defined world grid of some sort being used.

thank you chunks :)

THANK YOU CHUNKS!!!!!🎉🎉🎉

What have you done to me ? Im obsessed with grass now.. Im supposed to be a gamer not some kind of.. real life human thing who goes outside or whatever that is.. Anyways great video lol, Im wondering about how you could fix the camera issue you were talking about using the original method tho

In the far off distance, all the grass blurs together. Is it possible to instead have a single surface that replaces the grass at some distance and have the texture be some function of color calculated by how much the grass should be bending in that region (from the effect of either wind, something in the field, length, etc etc)?

I think I found the perfect grass

Chunks are a blessing for both end-user and in-editor performance, and thank you for remembering that this thing called LOD exists, I was rendering entire scenes from far away off a city that didn't downscale the buildings and car models, first it wasn't a problem because there wasn't too much models or effects on the scene, but after sometime I was getting 30 fps in game and 50-60 in editor. I will try to implement LOD. Many thanks.

thanks, chunks

チャンクスさん、ありがとう。

bring back the grass saga !!!

nice video

What if you used this chunking method and still, after a set distance, transitioned to the GPU instanced grass from the first video for your LOD grass? Would that help performance gains? Would there be a noticeable line at the cut off and, if so, could it be mitigated?

Next time instead of sending a buffer in, procedurally distribute hardcoded triangles along the terrain mesh and cull inside the shader from camera frustrum data.

im morbidly curious how much its possible to optimize this. please do a follow up video just for the hell of it. X'D

How feasible would it be to use a geometry shader to generate the positions of the grass as well based on what's visible in the frustum in the first place rather than sending the initial position buffer to the GPU. Like for each chunk you'd generate N positions for grass blades (pseudo-randomly but deterministic so it's the same every frame) using the height map displacement of the ground to get the base position, and from there generating the actual grass geometry. You'd cut about half the memory usage, but at the cost of more processing. Also now I'm wondering if it would be possible to do this as a separate pass entirely using deferred rendering somehow, with a masking pass to mark where grass blades are supposed to go (probably wouldn't work because obviously some grass has to start off screen, though extended buffers might fix that? I don't know, I'm completely spitballing here)

i could tell this guy really liked grass off the glasses alone

I was entertained, and you will never know for sure (because you cant see me) but I was razzle dazzled.

Id recommend swapping 3D grass for 2D billboards when the grass is a certain distance from the camera aswel

You are a fucking genius, and me still trying to implement a grass shader in godot

What if you gave the ground after the cutoff distance the same color as the actual grass, and applied the same noise on top of it to make it look darker as if there is grass moving there too?

Came for the grass, stayed for the Persona 3 music

Considering the number of grass increases exponentially with distance from the camera, you really want to cut down on the number you render at a distance as well. If you had a narrow band of low poly grass, then filled the following chucks with 2d decals you could probably save even more vram. Render every third point of grass with one decal with three grass straws could give a final performance boost.

He's back. Nice sunglasses.

Did you take any inspiration from the Sucker Punch GDC talk perhaps? They have pretty similar solutions for their grass rendering in Ghost of Tsushima.

Regarding the memory efficiency, I believe UV and perhaps even displacement are unnecessary. UV should just be the same as Position.xz (unless Position is in camera space, in which case you could at worst introduce a camera pos uniform) and for the vertical displacement, it should be a solution to take like VertexID % 7 and use that to index the height in a constant array. (This is assuming that you have 7 vertices on a grass blade, you could insert a different number)

the area of the square at 1:50 is 300 squared metres squared, not 300 metres squared.

Acerola: "Everyone has 16 GB of ram now a days" Me: "4 GB is best I can offer"

What does the displacement from the ground do? Isnt a position enough ?

Could you try it with half-precision floats?

So in conclusion, this is very doable, but you need to keep that final cost in mind and weigh whether or not it's applicable to the project you're working on. Dualy noted. I was considering using this for a VRC world where the only other performance heavy things are 1, people's avatars, and 2, a video player. I'll have to see how much of an impact it will have with other level geometry loaded in.

What about blocks? Cant you create an array of grass blocks and then randomize their orientation to get more variation. Create a simply and complex form of each block. Render everything in the simpler form first and prioritize in order of compelxity and distance. Also love to see a video about shaders.

This is great. But any chance you could tell us how to make it work with HDRP?

May I call you "Acerola-Orion Heart-Under-Grass-Blade", please?

Thank you for the video! Sorry that I sound like a bot...

Can you please cover ui features which are kinda wonky with advanced features

man I wish more games had better grass!

any reason for not reducing the density with increasing distance, as well as moving away from low-vertex single blades of grass to even lower-vertex multiple blades of grass (at LoD distances)