GRASS RENDERING in OpenGL // Code Review

CHAPTERS
0:00 - Rendering lots of grass in OpenGL
2:55 - Diving into the code
10:12 - Instantiating objects in C++ vs C#/Java
11:35 - Shader class
12:12 - Variable naming conventions
13:25 - Initializing variables
15:03 - Some notes on strings
15:30 - Pass larger types by const reference
16:45 - Using correct types
17:48 - Strings in C++ and std::string_view
20:48 - .obj format
22:38 - Grass mesh
23:44 - Rendering meshes
24:24 - General notes and C++ code style
25:35 - Grass rendering and shaders
26:32 - Handling a time variable for shaders
27:14 - Storage buffers in OpenGL
28:25 - Reduce complexity in hot code paths
29:00 - How grass is actually rendered
29:50 - Grass vertex shader
32:11 - Use mat3 instead of mat4
33:13 - Reduce vertex shader complexity
34:22 - Don't reallocate GPU buffers
35:28 - Inspecting rendering using Nvidia Nsight
37:13 - Set buffer data instead of reallocating
39:36 - Grass fragment shader + improvements
41:46 - Adding variance to grass blade color

This video is sponsored by Brilliant.

#CodeReview

[gwch]

graphics programmers don't touch grass, they would rather generate and render virtual grass and touch the screen.

[squelchedotter]

I really don't like middle star because it makes a lot of type definitions look a lot like multiplications

[Baffi]

16:20 There is a saying in our company, if you want speed, pass by value. Most of the time the compiler (especially with O2) will decide what is fastest and either pass by reference or by move semantics.

[dhoimkf]

32:20
AFAIK, for the GPU, a mat3 is just a mat4 with padded zeroes. GPUs don't have specialized mat3 registers, so a mat3 is just a mat4 which is treated like a mat3 in code.

[mbg]

i really wish you implemented all your suggested changes so that we could see the difference it makes

[Galakyllz]

I really enjoyed this code review. The level of detail was great; I appreciate all of the small points you made, even if you think that you "took too long on those earlier parts", I'm learning something. Please, more of this.

[weirddan]

15:30 It's interesting whether pass by value or reference/pointer is better. Obviously it can differ case by case but I saw a video of Chandler Carruth at cppcon (Google employee, works on Clang and does a lot of talks about optimization). He said pass by value is often better even for semi-large structs. The reason is that compilers don't do optimization as well when they have to deal with memory. If you pass by value, the compiler knows the function has a unique copy of the data and can better optimize. That may be the reason why you said that code at EA performed better when you did so.

[furball_vixie]

I'm sure I'm not the only one who would love to listen to you talking about rendering grass, without you restraining yourself

[JamesTamesGames]

heck yeah more Acerola recognition. Grass enthusiasts should definitely check out his channel.

[evan_game_dev]

I'm with right gang. Asterisk goes with the variable. Another thing, I completely agree that fragmented memory is slow (not really much to agree on, that's just a fact) but to counteract that, I like to allocate a couple gibibytes of memory at the beginning and put all my non stack memory on there

[mehdouchbhk]

Really impressive how such young people are good at programming nowadays, i wrote my first line of code when i was 18 and only now in my early 20s that i started to really taking it seriously on learning programming and computer graphics. Real Props for that dude!

[stburton]

For the SSBO update you may see some speedup if you orphan the data (see: OpenGL buffer orphaning) before the grass positions upload, instead of using glBufferSubData.

As written, with glBufferSubData (or glBufferData without orphaning) it could force a sync between the CPU and GPU as the pending GPU draw commands that read from the buffer must complete before the new buffer upload to ensure that the memory is not stepped on while it's in flight, since all draw commands are sourcing from the same buffer (if I understood the code correctly).

[ctond]

Please do the video on grass rendering, especially talking about LOD! Would love to see that :) Great video!

[StevenMartinGuitar]

Would love to see you make all your changes and upgrade the quality to make the absolute best grass rendering example!

[vasaaviarion]

Sometimed I forget how late I started programming. Im 23 and wrote my first line of code a couple months ago. Its still quite cryptic to me, but I hope to one day make and release my own video game

[zami]

its worth noting that trig functions on GPU specifically, at least for sin, cos and tan, are done on the hardware layer directly and end up being only slightly more expensive than something like multiplication. This is of course vastly different that what would occur if you ran the same calculation on CPU which does not have a dedicated hardware instruction for those.

[ZerFlash]

the grass looked amazing damn, man has made grass in opengl and c++ when i still take 5 days of errors doing it in unreal engine while following tutorials

[chromosundrift]

Great way you handled the idea of program structure for such a small program. As code grows, the benefits of structure grows. I think if you make this point clearly, viewers can see how excess abstraction is problematic and yet tackle the perhaps intended question of how to restructure as the code base grows.

[zxuiji]

39:15 I think a better way to speed it up would be maybe have a single 2048x2048 buffer (perhaps smaller or bigger, not giving heavy thought to this for now) to generate then use for every tile, no re-generating positions of grass blades, just make it dense enough that it difficult to notice it's being reused, as for when the grass should be sparse, still use the same buffer but just min/max blade opacity based on the meshes seed value for rand_r(), if it doesn't have one make it.

[rbaleksandar]

Great video. And through it I discovered the existence of RenderDoc. Thanks a bunch! :D