Off-topic, is there any mid-level 3D API that I can plug vertices into directly? Everything that I see is either super-low level (Vulcan, OpenGL) or super-high level (Unity).
Counting the lines of a renderer I have lying around it's 300 lines (including much whitespace). That's very full functioned, it correctly positions the window in the center of the monitor, handles errors properly, takes mouse and keyboard input, sets up the view/projection matrices, uses shaders, etc.
Generally I'd also say stick with 3.x (rather than 4.x) unless you need tesselation shaders.
https://github.com/jleahy/gldemo
That's a full OpenGL setup, with all the fiddly bits taken care of. Obviously it's a bit over the top (you don't need vertex buffer region management for one triangle), you don't need SIMD matmul, but that's the maximum.
You could port that to any language with OpenGL bindings.
Back in January, I discovered this really cool .NET Standard 2.0 library for abstracting Direct3D 11, Vulkan, Metal, OpenGL 3, and OpenGL ES 3 called Veldrid: https://github.com/mellinoe/veldrid
The documentation is pretty good, for its own parts, and it has a fair number of examples for setting up things like different windowing libraries. I was able to put together a set of code for a single demo running in Windows Forms, WPF, and Xamarin Forms fairly easily. It also has support for SDL2.
Currently, I'm going through a Codevember exercise where I teach myself WebGL from scratch.
From what I've learned so far, most of the graphics APIs these days work in very similar ways. And Veldrid polishes over the few differences (esp. in the case of OpenGL). WebGL does, too, in that they present an OpenGL front-end, but the back-end can be implemented in different graphics APIs (for example, on Windows it's actually implemented in D3D 11 through ANGLE).
In general, you need to create a Shader Program--which is a combination of multipe Shaders of different types, e.g. Vertex, Compute, and Fragment--construct one or more Buffers to which you will load data (generally in a big, ol' smash of data), and configure how ranges within those Buffers will map to pointer locations within your Shader Program.
However, I've generally found that there is little documentation anywhere on how to architect a data pipeline to use all of the various GPU resources efficiently. Everyone talks about "use as few draw calls as possible". But they don't really tell you how to achieve that.
My feeling is that a Shader Program is loosely analogous to a Material in something like Three.js or Unity. I'm guessing that the ideal approach is to take all of the Meshes in Three.js, or all of the Renderers in Unity, that have all of the same Materials, and then combining their Geometries into a single block of memory. And that's where Uber Shaders come in, as an attempt to also combine all of the different ways in which you'd want to render different Materials into a single Shader Program.
You should also be careful of monolithic Uber shaders especially if they branch as shader divergence can really kill gpu performance on some hardware. There is no one solution, just the one that best fits your usecase, hardware and coding time budget.
But with dynamic content loading over the 'net and teleconferencing and corporate authentication and general Unity update fuckery, it just got to be too much to manage. A lot of my users can't have Facebook accounts, so I need to support as many other headsets as possible, and Unity's tooling for that is way too constantly-in-an-ever-shifting-landscape-of-broken.
With OpenXR starting to really take off, and upcoming .NET 5 promising much more robust multiplatform support, I might be able to go back to .NET with Veldrid. Though I'd still have the teleconferencing and authentication bits being a lot harder to pull off outside of the browser, and having a native app would mean we would have to deploy through the Oculus store, which I definitely don't want to do.
My goal is to have a framework where I can experiment with different parts of OpenGL by sub-classing something and then override a method or two, and have it "just work" with everything else in the framework (shaders, viewers, animation, user interaction, etc.)