Not entirely related to the subject of OpenGL, but I really like how the author has decided to lay out this project. It's pretty hard to beat the convenience of a single header (or single header/single source) distribution for C libraries, but library development gets progressively harder as the project gets bigger as more code is added to the (usually hard to navigate) header file. Here, the author does their development with multiple files as one normally would, but when a new version is released they run the generate_gl_h[1] script that concatenates everything into a .h file for distribution. Simple yet flexible! This is also how SQLite[2] distributes its builds. It's a pattern that I'm using myself in some unreleased projects.<p>[1] <a href="https://github.com/rswinkle/PortableGL/blob/master/src/generate_gl_h.py" rel="nofollow">https://github.com/rswinkle/PortableGL/blob/master/src/gener...</a>
[2] <a href="https://www.sqlite.org/amalgamation.html" rel="nofollow">https://www.sqlite.org/amalgamation.html</a>
So reading this:<p>> [Vulkan] really is overkill for learning 3D graphics...using modern OpenGL to introduce all the standard concepts, vertices, triangles, textures, shaders, fragments/pixels, the transformation pipeline etc. first is much better than trying to teach them Vulkan and graphics at the same time...<p>...got me wondering. I haven't really kept up with modern graphics programming, but my - possibly incorrect - understanding was that not only is Vulkan lower-level than OpenGL, it was also motivated by lots of questionable design decisions that OpenGL was kind of stuck with. So, with the above quote in mind, is it the case that:<p>* Vulkan is good (?) but too low-level for most users.<p>* OpenGL is a good environment to learn or do nuts & bolts 3D programming in - i.e. it's the right level of abstraction for that - but is kind of a mess.<p>Is that correct? Is there anything that splits the difference? How's Direct3D these days? Metal? Has anyone built a library on top of Vulkan, targeted roughly around the abstraction level of OpenGL, but with a better design?
Fabrice Bellard released an OpenGL 1.x/2.x software renderer 20 years ago [0]. There seems to others who have taken to updating it more recently [1][2]. It is direct mode or immediate mode but this is how we used to do graphics more than 15 years ago. Might help others to read this if you're interested.<p>[0] <a href="https://bellard.org/TinyGL/" rel="nofollow">https://bellard.org/TinyGL/</a><p>[1] <a href="https://github.com/C-Chads/tinygl" rel="nofollow">https://github.com/C-Chads/tinygl</a><p>[2] <a href="https://github.com/ska80/tinygl" rel="nofollow">https://github.com/ska80/tinygl</a>
> I took a 400 level 3D Graphics course in college in fall 2010 months after OpenGL 3.3/4.0 was released. It was taught based on the original Red Book using OpenGL 1.1. Fortunately, the professor let me use OpenGL 3.3 as long as I met the assignment requirements. Sadly, college graphics professors still teach 1.x and 2.x OpenGL today in 2020<p>This one hits home. I did my first (and only) graphics programming in college in 2019 and it was indeed OpenGL 1.1 to make matters even more stupid, it was a course where the opengl part was only half the course, the other half was about image processing using matlab...<p>I dont know what it is about graphics programming, I've tried many times to learn it but its so different to any of the other programming I've done that it feels totally impenetrable.
> Using modern OpenGL to introduce all the standard concepts ... is much better than trying to teach them Vulkan ... and obviously better than teaching OpenGL API's that are decades old.<p>I disagree on teaching old APIs. This is a pet peeve of mine, and I thought the author of a software rasterizer would agree with me.<p>GPU APIs are some of the only APIs where you have to pay to upgrade. Sure, Vulkan has been "out" for 4 years. But I haven't bought any hardware that supports Vulkan. My last purchase was a used laptop with an iGPU. I buy hardware as a last resort when I absolutely need it, I especially don't buy hardware for the APIs when my old hardware has enough GFLOPS.<p>I like that programming is a cheap hobby. I don't see the point in anteing up every few years. Per-core CPU power has plateaued, and I can add more storage to old systems easily. I just don't want to buy new hardware until I see the GPU space settle down for a few years. And when will that happen? Vulkan 2? Vulkan 3?<p>How many more perfectly functional TFLOPS of GPU chips will be branded e-waste before the APIs are stable? I don't like the implication among some gamedevs that your programming skill depends on how much tribute you've paid to NVidia. I don't make bad games because I use GLES 2, I make bad games because I'm a bad gamedev.<p>GLES 2 is a sweet spot in the tradeoff between compatibility and features. It dates to about 2007, so even a kid with a cheap used Android phone could theoretically write GLES 2 code for it. It doesn't have geometry shaders, but with vertex and fragment shaders you can still learn things like environment mapping, gamma-correct per-pixel lighting, hardware skinning, post-processing effects, etc.<p>It just works, almost everywhere, and I don't see the point in writing off old hardware as trash before the end of its natural life.
This is pretty cool, I've looked for libraries like this myself in the past. Sometimes I've needed to render a bunch of simple 3D graphics off-screen, without any real-time or high-throughput requirements (mostly for visualizing 3D stuff in robotics/computer vision). Setting up GPU-based pipelines for this is possible, but can be kind of kludgy and annoying. Mesa3D can do opengl software rasterization, but it's also a nontrivial dependency. I've ended up writing crappy rasterizers in the past just to avoid all that hassle. A single-header solution for this that's more up-to-date than TinyGL is welcome.
Aside about that README file: its laid out better than plenty of research papers I've been reading lately and the professors who ostensibly wrote those papers should know better. Kudos just for that.