I always find it strange there's not a tutorial-style book that just implements a 3D game engine from scratch, step by step, e.g., with sample code you can download and run. The obvious game type to do this with is a simple FPS.
The only thing like this I know of is Casey Muratori's Handmade Hero video series https://hero.handmade.network But that's obviously a different format with different goals.
Missing from the graphics API list is WebGPU - which is not really just for the web. I've not used Metal, but from what I've heard, the API resembles Metal a good bit, which is a good thing since it's supposedly the nicest of the low-level graphics APIs (and having used both Vulkan and WebGPU, I definitely agree WebGPU has a way nicer API). The libraries backing WebGPU implementations in the browser can be used standalone (Dawn[1] is written in C++ and wgpu[2] in Rust), which means that they can be used on an otherwise native application that would have used some native graphics API.
Apparently threadreaderapp.com now requires an account now, and twitter shows only the first message without an account. Twitter thread is simply not a good way of spreading information (assuming one wants this info to be read by the most people) - it was never good, and it only got worse unfortunately.
Yeah... I was interested to read this, hit the login requirement, had 10 images of the shitty things Musk has been doing just this last week, and noped right out.
OP if this is your content pls share it somewhere I can engage with it!
How about Bluesky? If you're there, and have this there, I will happily follow.
OpenGL is a good API to start with. There's a lot to learn regardless of which API you use. Once you can do an animated character in a scene with lighting, shadows, particles and basic full-screen post processing, you'll know how to proceed forward on your own from there.
A common mistake I see in beginners that you should definitely NOT do is to try to make completely self-contained classes like `tree.draw();`that attempt to set up and tear down all of the OpenGL state required to draw an object. The code required to make `tree.draw(); mainCharacter.draw(); rock.draw(); dog.draw();` work in random order is not only a very slow way to use GL, it is also extremely error-prone because the state set by an earlier object can accidentally affect a later object in unplanned ways.
Instead, it is much better to have all of the code for actually rendering a depth/shadow/static/animated/particle/UI pass contained in a function that handles 100% of the state setting for it's entire pass in a self-contained way. When you can look at the code all at once it becomes much easier to the straight in your head. It also makes it easier to set up in an efficient way.
[Modern Mobile Rendering @ HypeHype](https://enginearchitecture.org/2023.htm) describes a modern, high-end commercial implementation of the command buffer idea that started back in 2008 with the Order your graphics draw calls around! article. Obviously, you don’t have to be that advanced right out of the gate. But, it demonstrates a goal.
It's not a bad idea to have convenience classes for loading and specifying textures, shaders, meshes, and for packaging them up as a model. But, after loading those classes should not call more OpenGL functions until it is time to unload them.
Bonus points if you can load a large number of meshes into a small number of buffer objects, for loading asynchronously and for using glMultidrawElementsIndirect in your render pass loops.
Another common mistake is to make a scene graph with state modifiers. Like "Everything under this tree node is red plastic. Everything under this tree node is rippling". Horrible idea. Takes a huge amount of effort to semi-optimize.
A layout graph is fine. "The gun is attached to the hand of the character in the jeep on terrain segment 22 in sector[5,5]". With that you just need to figure out how to flatten the transforms quickly.
But, resolving arbitrary state permutations at runtime is fighting against the hardware and the driver.
I always find it strange there's not a tutorial-style book that just implements a 3D game engine from scratch, step by step, e.g., with sample code you can download and run. The obvious game type to do this with is a simple FPS.
The only thing like this I know of is Casey Muratori's Handmade Hero video series https://hero.handmade.network But that's obviously a different format with different goals.
Missing from the graphics API list is WebGPU - which is not really just for the web. I've not used Metal, but from what I've heard, the API resembles Metal a good bit, which is a good thing since it's supposedly the nicest of the low-level graphics APIs (and having used both Vulkan and WebGPU, I definitely agree WebGPU has a way nicer API). The libraries backing WebGPU implementations in the browser can be used standalone (Dawn[1] is written in C++ and wgpu[2] in Rust), which means that they can be used on an otherwise native application that would have used some native graphics API.
[1]: https://dawn.googlesource.com/dawn/+/refs/heads/main/README.... [2]: https://wgpu.rs/
Apparently threadreaderapp.com now requires an account now, and twitter shows only the first message without an account. Twitter thread is simply not a good way of spreading information (assuming one wants this info to be read by the most people) - it was never good, and it only got worse unfortunately.
Awful that this is even required but here it is: https://nitter.poast.org/rainbowpikmin/status/18429670878092...
Yeah... I was interested to read this, hit the login requirement, had 10 images of the shitty things Musk has been doing just this last week, and noped right out.
OP if this is your content pls share it somewhere I can engage with it!
How about Bluesky? If you're there, and have this there, I will happily follow.
Why no love for webgpu?
There are 2 major native implementations being wgpu-rs (which has first party C bindings), and google’s dawn, which both use Vulkan as a backend.
I answer this question over and over on Reddit. So, here’s a wall of text for everyone :)
Here's the list of links I give everyone getting started in graphics programming in general.
The main thing you need to know is https://fgiesen.wordpress.com/2016/02/05/smart/
OpenGL is a good API to start with. There's a lot to learn regardless of which API you use. Once you can do an animated character in a scene with lighting, shadows, particles and basic full-screen post processing, you'll know how to proceed forward on your own from there.
https://learnopengl.com/ https://raytracing.github.io/ https://gamemath.com/book/ https://www.gameenginebook.com/ https://realtimerendering.com/ https://google.github.io/filament/Filament.md.html https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-... https://developer.nvidia.com/nsight-graphics https://renderdoc.org/
A common mistake I see in beginners that you should definitely NOT do is to try to make completely self-contained classes like `tree.draw();`that attempt to set up and tear down all of the OpenGL state required to draw an object. The code required to make `tree.draw(); mainCharacter.draw(); rock.draw(); dog.draw();` work in random order is not only a very slow way to use GL, it is also extremely error-prone because the state set by an earlier object can accidentally affect a later object in unplanned ways.
Instead, it is much better to have all of the code for actually rendering a depth/shadow/static/animated/particle/UI pass contained in a function that handles 100% of the state setting for it's entire pass in a self-contained way. When you can look at the code all at once it becomes much easier to the straight in your head. It also makes it easier to set up in an efficient way.
Use https://realtimecollisiondetection.net/blog/?p=86 as a guide. Sort according to https://community.khronos.org/uploads/default/original/2X/4/... and you'll be doing better than most hobby engines.
[Modern Mobile Rendering @ HypeHype](https://enginearchitecture.org/2023.htm) describes a modern, high-end commercial implementation of the command buffer idea that started back in 2008 with the Order your graphics draw calls around! article. Obviously, you don’t have to be that advanced right out of the gate. But, it demonstrates a goal.
It's not a bad idea to have convenience classes for loading and specifying textures, shaders, meshes, and for packaging them up as a model. But, after loading those classes should not call more OpenGL functions until it is time to unload them.
Bonus points if you can load a large number of meshes into a small number of buffer objects, for loading asynchronously and for using glMultidrawElementsIndirect in your render pass loops.
Another common mistake is to make a scene graph with state modifiers. Like "Everything under this tree node is red plastic. Everything under this tree node is rippling". Horrible idea. Takes a huge amount of effort to semi-optimize.
A layout graph is fine. "The gun is attached to the hand of the character in the jeep on terrain segment 22 in sector[5,5]". With that you just need to figure out how to flatten the transforms quickly.
But, resolving arbitrary state permutations at runtime is fighting against the hardware and the driver.
For more insight into this, check out https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-... , https://www.slideshare.net/slideshow/beyond-porting/30219704 , https://youtu.be/-bCeNzgiJ8I,
For a geometric approach to learning linear algebra for graphics programming I strongly recommend The Dark Art of Linear Algebra[1] by Seth Braver.
[1]: https://www.bravernewmath.com