{"id":1745,"date":"2024-01-01T17:19:51","date_gmt":"2024-01-01T17:19:51","guid":{"rendered":"https:\/\/timallanwheeler.com\/blog\/?p=1745"},"modified":"2024-07-20T03:22:48","modified_gmt":"2024-07-20T03:22:48","slug":"rendering-with-opengl","status":"publish","type":"post","link":"https:\/\/timallanwheeler.com\/blog\/2024\/01\/01\/rendering-with-opengl\/","title":{"rendered":"Rendering with OpenGL"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

In the previous post I introduced a new side scroller project, and laid out some of the things I wanted to accomplish with it. One of those points was to render with the graphics card. I had never worked directly with 3D assets and graphics cards before. Unless some high-level API was doing rendering for me under the hood, I wasn’t harnessing the power of modern graphics pipelines.<\/p>\n\n\n\n

For TOOM<\/a> I was not using the graphics card. In fact, the whole point of TOOM was to write a software renderer<\/em>, which only uses the CPU for graphics. That was a great learning experience, but there is a reason that graphics cards exist, and that reason pretty much is that software renderers spend a lot of time rendering pixels when it’d be a lot nicer to hand that work off to something that can churn through it more efficiently.<\/p>\n\n\n\n

Before starting, I thought that learning to render with the graphics card would more-or-less boil down to calling render(mesh)<\/code>. I assumed the bulk of the benefit would be faster calls. What I did not anticipate was learning how rich render pipelines can be, with customized shaders and data formats opening up a whole world of neat possibilities. I love it when building a basic understanding of something suddenly causes all sorts of other things to click. For example, CUDA used to be an abstract, scary performance thing that only super smart programmers would do. Now that I know a few things, I can conceptualize how it works. It is a pretty nice feeling.<\/p>\n\n\n\n

Learning OpenGL<\/h1>\n\n\n\n

I learned OpenGL the way many people do. I went to learnopengl.com<\/a> and followed their wonderful tutorials. It took some doing, and it was somewhat onerous, but it was well worth it. The chapters are well laid out and gradually build up concepts.<\/p>\n\n\n\n

This process had me install a few additional libraries. First off, I learned that one does not commonly directly use OpenGL. It involves a bunch of function pointers corresponding to various OpenGL versions, and getting the right function pointers from the graphics driver can be rather tedious. Thus, one uses a service like GLAD<\/a> to generate the necessary code for you. <\/p>\n\n\n\n

As recommended by the tutorials, I am using stb_image<\/a> by the legendary Sean Barrett for loading images for textures, and assimp<\/a> for loading 3D asset files. I still find it hilarious that they can get away with basically calling that last one Butt Devil. Lastly, I’m using the OpenGL mathematics library<\/a> (glm) for math types compatible with OpenGL. I am still using SDL2 but switched to the imgui_impl_opengl3 backend. These were all pretty easy to use and install — the tutorials go a long way and the rest is pretty self-explanatory.<\/p>\n\n\n\n

I did run into an issue with OpenGL where I didn’t have a graphics driver new enough to support the version that learnopengl was using (3.3). I ended up being able to resolve it by updating my OS to Ubuntu 22.04. I had not upgraded in about 4 years on account of relying on this machine to compile the<\/a> textbooks<\/a>, but given that they’re out I felt I didn’t have to be so paranoid anymore.<\/p>\n\n\n\n

In the end, updating to Jammy Jellyfish was pretty easy, except it broke all of my screen capture software<\/em>. I previously used Shutter<\/a> and Peek<\/a> to take screenshots and capture GIFs. Apparently that all went away with Wayland<\/a>, and now I need to give Flameshot<\/a> permission every time I take a screenshot and I didn’t have any solution for GIF recordings, even if login with Xorg. <\/p>\n\n\n\n

In writing this post I buckled down and tried Kooha again, which tries to record but then hangs forever on save (like Peek). I ended up installing OBS Studio<\/a>, recording a .mp4, and then converting that to a GIF in the terminal via ffmpeg:<\/p>\n\n\n\n

ffmpeg -ss 1 -i input.mp4 \\\n  -vf \"fps=30,scale=320:-1:flags=lanczos,split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse\" \\\n   -loop 0 2d_to_3d.gif<\/code><\/pre>\n\n\n\n
This was only possible because of this excellent stack overflow answer<\/a> and this OBS blog post<\/a>. The resulting quality is actually a lot better than Peek, and I’m finding I have to adjust some settings to make the file size reasonable. I suppose its nice to be in control, but I really liked Peek’s convenience.<\/p>\n\n\n\n
Moving to 3D<\/h1>\n\n\n\n
The side scroller logic was all done in a 2D space, but now rendering can happen in 3D. The side scroller game logic will largely remain 2D – the player entities will continue to move around 2D world geometry:<\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n\n
but that 2D world geometry all exists at depth \\(z=0\\) with respect to a perspective-enabled camera:<\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n\n
Conceptually, this is actually somewhat more complicated than simply calling DrawLine for each edge, which is what I was doing before via SDL2:<\/p>\n\n\n\n
for edge in mesh\n    DrawLine(edge)<\/code><\/pre>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n\n
Rendering in 3D requires:<\/p>\n\n\n\n