If you're interested in something that's not strictly real-time a good book is physically based rendering http://www.pbrt.org/ . It uses a literate-programming style which is neat. It's about path-tracing which is similar to ray-tracing but can give an unbiased approximation to the rendering equation (which is a reasonably accurate model of "everyday" optics.) Here is a JS+WebGL (mostly WebGL ;) ) interactive path-tracer: http://madebyevan.com/webgl-path-tracing/
---
Vulkan is pretty boring to be honest. I'm very doubtful that you want to bother with it if you're just starting. Using these APIs is like filling out tax forms, but Vulkan is a lot more effort than OpenGL (but, OpenGL is weird...) Learning shaders in OpenGL will be pretty transferable knowledge. Vulkan uses a lower-level assembly-like language, SPIR-V that doesn't pretend to be C (like GLSL) but there are GLSL to SPIR-V compilers. I can't comment on DX (I haven't used it.)
Here's a tutorial on drawing you first triangle: https://software.intel.com/en-us/articles/api-without-secret... . Note that there is a lottttt of code to do this (this is part 3...) I really think you could learn more about modern graphics with glBegin(GL_TRIANGLES) and writing GLSL shaders than boring yourself with Vulkan.
If you do want to play with Vulkan there is this book (piggy-backing off the rep from the old "OpenGL Bible") https://www.amazon.com/Vulkan-Programming-Guide-Official-Lea... . I can't give it an honest review because I got bored; I plan to pick it up again later...
Yeah, this is one of the downsides of modern graphics.
Taking for example OpenGL, in the old days you could just download a NeHe project to use as a framework to learn from. To render basics you just specified triangles by their vertices with e.g. glBegin(GL_TRIANGLES) as Jacob says. In a small number of days you could have been close to the front tier of graphics development.
But then it became far more complicated as graphics cards added tons of optimisations to improve speed. Instead of just specifying triangles you then had to create lists, indirect lists, bindings etc. Now as per his example, you have to add a ton of extra boilerplate to just render a simple triangle. And if it doesn't just work it's very hard to figure out why.
What you can also do is use an engine like Unity, then just set it up so that you add some direct OpenGL calls in to create and render objects (I use it in this manner for some dynamics things, when I don't want to create GameObjects for Unity to manage). But that's not a very "pure" way of learning graphics development. I guess it also comes down to what you want to do with the knowledge in the end.
> you have to add a ton of extra boilerplate to just render a simple triangle
It's true the modern OpenGL pipeline is a bit more boilerplatey.
But that small amount of extra code means it's vastly more flexible. Rather than programming stuff into a fixed pipeline that can only do a limited set of predetermined things, everything is centred around shaders you write, and they can do anything you want. The boilerplate is just needed to compile the shaders, and feed information to them.
Also, while it's slightly more code you're writing, the amount of code executed on the CPU is less, because mostly you just set up a draw call and let the GPU do the rest. Much more efficient.
And the boilerplate is small, if a little intimidating. This stars effect is 156 lines of JS code (of which only about half is actual WebGL stuff), and 24 lines of GLSL shader code: https://hoshi.noyu.me/
(I should add that I used to feel the same way and really didn't get modern OpenGL, but after a few abortive attempts I finally grokked the basic concepts, and once you have those, it's plain sailing, because most things are just small changes to shaders.)
It reminds me of the progression that I've gone through mentally, regarding 3D graphics.
1. What's all this matrix crap? I can take object and camera coords and calculate out a screen coordinate easily with some simple algebra and trig.
2. Oh, OK. Use matrices properly, and you can get rid of some repeated operations.
3. Classic GL mostly takes care of the matrix operations for me, and leaves me with a simple-ish interface for modifying the state machine (goodness, there's a lot of data to feed into it though).
4. Modern OpenGL: Erghh, boilerplate!
5. Build some utility functions and bootstrap yourself out of there, and the interface is so much more powerful. Sure, you have to explicitly specify some more things. Another way to put that is that you can change things that used to be implicitly defined. It's a wonderful bit of freedom, actually.
I feel your pain, learned with NeHe and then went on to GLES/Android graphics...just to learn that everything is different. Now though, I see why: while the "old" way was to talk to the statemachine with loads of tiny CPU instructions, you now load you data to the GPU in one go, which costs you less cpu if done right, and is generally close to what you actually want in regards to loading models/etc..
In some ways, I find the modern OpenGL with shaders to be simpler than the fixed-function pipelines of old. The important parts, like the projection math, happen in your code. If you understand the math, it's easier to follow than a bunch of API calls to modify global matrix stacks.
It's still like that. Ok, you aren't going to know all of the advanced graphics techniques, but you can render a scene with multiple cubes and a first-person camera in 100 lines of code.
Rendering a triangle to the screen is easy; it takes understanding the unique way these tools work, but at the end of the day it's not complicated stuff.
This is just from fiddling around in my free time and reading a lot of tutorials, but here's a WebGL renderer that will render a 40x40x40 block of semi-randomized cubes. You can clone that and open index.html in a browser. WASD work about as you expect and spacebar locks the mouse.
OpenGL works pretty much the same in very language and so much legwork ends up through matrix math. Once that starts to click that's the heart of a lot of graphics tech, even if it's not state of the art.
---
Vulkan is pretty boring to be honest. I'm very doubtful that you want to bother with it if you're just starting. Using these APIs is like filling out tax forms, but Vulkan is a lot more effort than OpenGL (but, OpenGL is weird...) Learning shaders in OpenGL will be pretty transferable knowledge. Vulkan uses a lower-level assembly-like language, SPIR-V that doesn't pretend to be C (like GLSL) but there are GLSL to SPIR-V compilers. I can't comment on DX (I haven't used it.)
Here's a tutorial on drawing you first triangle: https://software.intel.com/en-us/articles/api-without-secret... . Note that there is a lottttt of code to do this (this is part 3...) I really think you could learn more about modern graphics with glBegin(GL_TRIANGLES) and writing GLSL shaders than boring yourself with Vulkan.
If you do want to play with Vulkan there is this book (piggy-backing off the rep from the old "OpenGL Bible") https://www.amazon.com/Vulkan-Programming-Guide-Official-Lea... . I can't give it an honest review because I got bored; I plan to pick it up again later...