[–] FrostKiwi 3 days ago
[–] leecommamichael 3 days ago
[–] yunnpp 2 days ago
[–] mvx64 2 days ago
You can implement in software whatever you want and just handwave specific parts to GL, like rasterization. The rest of the boilerplate code will be minimal.
In new APIs you are bound to write 100s of lines of boilerplate code to get to the point. In the time you should be learning about barycentric coordinates, you are still learning about descriptor sets. And still, you don't learn about rasterization, texture mapping, clipping, face culling, because they are still fixed pipeline.
The only problem with learning with 100% cpu rendering is that you need some patience before seeing beautiful stuff because you need to learn/implement everything up until that point.
[–] dahart 2 days ago
[–] throw23423 2 days ago
Could you recommend any resources for learning that?
[–] yunnpp 2 days ago
If the video format is not for you, I would at least follow the contents, then look up the individual pieces. The black book has a number of them: https://www.jagregory.com/abrash-black-book/
For ray tracing, Ray Tracing from the Ground Up: https://www.amazon.in/Ray-Tracing-Ground-Kevin-Suffern/dp/15...
Then people will jump in to say that the PBRT book (https://www.pbrt.org/) is a better or more comprehensive source, and it is true, but my opinion is that From the Ground Up is easier to get started with.
A fundamental shift in thinking that got me into high performance graphics programming and parallelized image processing, the "Aha" Moment, is being forced to express how to calculate the final pixel independently, without having access to neighboring pixels of the same output buffer, confined to the straight jacket of the fragment shader. OpenGL with it's combination of hand-holding and relative simplicity as compared to Vulkan and limits of a predefined shader pipeline as compared to a pure software implementation is exactly the thing that I needed to get into graphics programming. It's an excellent jump in point I think.