I'm in the same boat, I've been toying with kaggle recently. They have some guided tutorials done via notebooks with some data that seems to be heading towards playing with the data myself. I recommend it as it's interesting, has me playing with data, and is consumable le, but I don't have enough experience to give an informed opinion on it.
ISLR is a good one—it’s focused on practical theory, but there’s still some unavoidable math. Code exercises are simple (and ugly—stats professor code) but gives you the basics to build on.
Also: this was recommended on HN recently and it’s the best intro to matrix algebra / basic math of ML that I’ve seen. Lots of very practical and relevant exercises that relate to real data science tasks like text and image analysis. Code examples are in Julia.
And one more gold standard for more practical data science (with R) stuff. It introduces a more modern take on R (chaining functions together with the %>% pipe operator, which makes everything clean and terse).
That really depends. If you know graphics concepts, but need to actually learn an API, there is nothing wrong with starting with Vulkan. It's a lot to figure out to make something practical with it, but it's expected.
I'd say, a good way to do it, is first learn theory, and apply it using simple tools that let you just draw on screen (like SDL). Then learn a GPU targeted API.
What about 2D graphics? Sprites? Old school stuff? I keep meaning to fire up DOSBox-X and go through some old tutorials. I really just want to put pixels on the screen and work my way up from there - everything else just seems to get in the way.
Javascript + HTML5 Canvas is an easy start, and if you want to do even older-skool stuff you can treat the canvas as just a block of pixels and write your own 2D renderer on top of it.
Processing is amazing (and what I switched to after I started hitting Flash performance limitations). They have great documentation and tutorials on their website too, and I felt it's little IDE made it really easy for beginners to get started with it.
I know some would say it's a bad language, but back in the day it was incredibly accessible and spawned a lot of shared code and tutorials. If you focus on the techniques and algorithms, treat the language as pseudocode rather than "the right way to do things", you can have a lot of fun and learn quickly things you can translate to whatever your language of choice is.
I think most of those will work on QB64, too. So you could end up end with fast, native executable files on Windows, MacOS, and Linux. That doesn't matter much for those tutorials, but QB64 might be ever so slightly quicker to get up and running than DosBox + QBasic.
Agreed. With SDL you can get a loop that copies a 2D array of pixels from main mem to the screen every frame about as fast as possible in a single page of code. If you want to explore software rendering, that's the way to go.
> I really just want to put pixels on the screen and work my way up from there
That really isn't how modern, accelerated graphics works - even 2D accelerated graphics! "Sprites" are slightly closer to the mark, but it goes far beyond that.
The entire framebuffer can be thought of as a huge sprite. Modern RAMDACs can scan multiple overlapping arbitrarily sized framebuffers (layers) simultaneously, while doing bilinear filtering, merging alpha, colorspace conversion, rotation, LUT, etc.
All that happens on the fly without intermediary frame buffer composition in between. The output goes directly to the display (over HDMI, eDP/displayport, DVI, etc.).
Yeah, and of course mouse cursor is a sprite in the traditional sense. Although on modern HW you could implement mouse cursor as a hardware layer.
I've been dabbling with 2D graphics recently and found PyGame to be well suited for experimentation. You'll need to hold your nose a bit (API is a bit clunky in places and far from Pythonic) but it's relatively trivial to get some pixels on screen.
in my gameswithgo.org video series, when we start on graphics, that is how I do it. we implement putpixel, and do some basic 2d rendering by hand. bilinear filtering, alpha blending, etc.
You can do it with SDL or even just Canvas and JS. Later on you'll converge onto "3d as 2d" as you try to optimize and leverage shaders for high performance effects like color grading, blur, glow, etc.
One other bit of advice - a lot of the tutorials out there start with matrix math and eventually get around to drawing a triangle.
I recommend reversing that - ignore the math and just get a triangle on screen using a trivial shader (takes a few dozen lines of code in WebGL), then learn about how shaders and matrices work by applying them to your triangle.
Absolutely this. I did it the other way because I didn't know better, and it was remarkably boring for the first several days of trying to decipher tutorials. It would've been much more fun if I had just thrown a triangle on the screen and started playing around.
IMO Shadertoy is not a good place to start. The techniques shown on shadertoy are fun to play with but they have almost nothing to do with the techniques used to make shipping products. Drawing an entire forest in a single shader is amazing but it runs at 0.2fps on a machine that can run GTA5 at 30-60fps
I would agree - Shadertoy is really cool, but it fits into the category of "they did it because they could, not because they should." There are techniques used in Shadertoys that are relevant elsewhere, though the learning curve is really steep in terms of comprehending what most Shadertoys are doing.
I second this heavily. I've implemented a 3d scene renderer for 3D CAM software in the past and have been wanting to get back into some 3D things to practice math as I've been feeling a bit behind where I used to be.
I spent a while getting an OpenGL environment setup in VisualStudio and got frustrated with the tooling as I've also been spending much of the last 3 years doing trivial web development. I ran across shadertoy and was able to whip up much of the core of the pathtracer there and very easily move it over to it's own project supper easily utilising REGL (https://github.com/regl-project/regl) in ~100 lines that included a camera, dynamic shader compilation based on a scene, etc...
This is my own limited experience, so I hope an expert also answers. In the Handmade Hero video series/project, he codes a game engine from scratch. I didn't get very far into it, but I followed along coding it myself, using what I learned watching him. He writes it in a way that all the platform-specific code is in its own file, and he does it in DirectX, although other people have ported it to other platforms. Early in the series, he gets it to where you can create a sound buffer of samples and play it out to the speakers. So I played around with simply adding sine waves to generate things such as dial tones, busy signals, and DTMF dialing sounds. I would consider that "ground up" for the Windows platform. It should be pretty simple from there to load audio samples from files, adjust their volume, play them back faster/slower, and mix them together. And/or generate more complicated sythensized music. There is a book about building modular synthesizers, and I was thinking about using that but doing it in software.
The best motivator for me was to start building a Standard MIDI Format sequencer and test its output on MIDI files. The underlying MIDI standard is a well-understood protocol with many resources, while SMF adds some room for creative interpretation since it's meant to work across sample-based synths, FM, etc. I started with a simple square-wave beeper, added polyphony and volume envelopes, and built it up from there. By the end, the architecture I had initially built was melting down, but it was playing Soundfonts to some degree, and I could confidently claim to understand audio coding.
There's a lot of room to do things incorrectly and not notice in audio, which makes it forgiving to learn: e.g. playing a sample at a different pitch can be done badly by adding or removing arbitrary samples, but resampling it with minimal distortion is actually a fairly intensive DSP problem. Or when computing a volume, the linear amplitude usually isn't the parameter you want to work with(see every UI where volume changes imperceptibly until you reach the bottom 10% of the slider), and while there are computations to convert between linear and dB values, you still have to qualify it with one of these various references and suffixes[0]. There's a lot of crossover between audio and electrical signal terminology that can make it hard to follow this material.
So you can spend a lot of time doing simple things well!
I enjoyed going through The Book of Shaders[1] by Patricio Gonzalez Vivo. It comes with an interactive programming environment that's great if you're just getting started.
It's free but please consider donating if you find it useful.
For anyone looking for a great starter codebase that you can poke around in to learn the fundamentals of CG, check out Scotty3D [0], the base code for CMU's computer graphics class 15-462/662 (I am a TA for this class). It is a supplemental codebase to the lecture slides [1], which are all available online. The idea is that Scotty3D is a full 3D modeling suite akin to Blender or Maya, but all of the actual functionality is stripped out, waiting to be implemented by students.
It includes code for 3D model loading, linear algebra, basic (OpenGL) rendering, and UX, and provides stubs for you to implement:
- local geometry operations (ex: edge split,
vertex/edge/face bevel, vertex/edge/face delete, etc)
- global geometry operations (ex: upsampling via catmull
clark subdivision, downsampling using quadric error, etc)
- a path tracer that supports Diffuse/Mirror/Glass
materials with Fresnel reflections and environment
lighting (ex: you can render the cornell box)
- an animation suite that implements skinning, spline
interpolation, and basic simulation (wave sims)
There's a lot of documentation in the wiki [2] to help you get started. A great resource, even if you can't take the class yourself!
Ah, the good old OpenGL fixed function pipeline, deprecated for over 11 years now.
For something a bit more modern, I'd recommend [0], but one might argue that old OpenGL is easier to learn since you don't have to setup your own shaders.
To clarify, the point of Scotty3D is not to teach OpenGL -- the students do not write any OpenGL, DirectX, Vulkan, etc in the class. The OpenGL that is there is simply used to render the 3D models and the UI, so updating that code is pretty low priority.
One of my longer-term goals as a TA for the class is to update Scotty3D to Vulkan or modern OpenGL.
EDIT: I wanted to expand on this point, as this is actually an important part of the philosophy of the design of the course. As the OP argues as well, it more important to learn the fundamentals of CG theory (eg rasterization, the rendering equation, solving ODEs/PDEs) than the specifics of any particular implementation (OGL, DX, etc). After taking 462, many students (including myself!) take the class 15-466 Computer Game Programing [0], which goes deep into more modern OpenGL implementations (admittedly, it's OGL 3.3, but it still covers shaders/VBOs/other important concepts that translate to modern APIs).
I wanted to support what you're saying. I've worked in visual effects for over a decade now. While I've dabbled with OpenGL, I think the only practical application I've had was taking a stab at writing a PyOpenGL widget for viewing Alembic models in a custom PySide asset browser for a studio. This was when Alembic was much less mature and it never ended up getting used. However, I have done a lot of dealing with color spaces, debugging/optimizing scanline and ray casting renderers, computing/storing surface normals, projection and other space transforms, and simulations. I've written toy versions of a lot of those things, but mostly was debugging back box systems written by others or troubleshooting assets generated or consumed by one of these tools.
Even if you're talking about game engines, there's still a whole lot more to learn. This game engine book [1] has one chapter about the rendering engine and 16 more about other topics. Each chapter in there is at least one hefty book to get a good working knowledge of the topic.
It's great you have a resource where people can learn and experiment with these other things without having to learn to write all the code around it.
> Even if you're talking about game engines, there's still a whole lot more to learn. This game engine book [1] has one chapter about the rendering engine and 16 more about other topics. Each chapter in there is at least one hefty book to get a good working knowledge of the topic.
Which is why when people without game industry experience start discussing 3D APIs adoption, they loose on how little the APIs actually influence the whole engine codebase.
There's something charming and engaging about the "legacy" fixed function pipeline that we've lost with our increasing focus on lower and lower level APIs. The ability to have a 10 line hello-world program that draws a colored triangle on the screen is magical, and encouraging to beginners, and that experience can't be replaced by the massive boilerplate and "copy-paste-this-stuff-dont-worry-about-what-it-does-yet" you need to do in order to do graphics the more modern way.
With Apple working to eliminate all traces of OpenGL with Metal, and Microsoft already having abandoned it close to two decades ago, I feel it's close to the end of the road for fixed function OpenGL. It was a wonderful part of graphics development history that, sadly, future beginners will likely not be able to experience.
I hope it's not too off-topic, but I feel this sort of thing has happened before with developing GUI programs in Visual Basic, drawing to the screen with turtle graphics, (or instead whatever routines BASIC tended to have). Curious if others share the sentiment with other examples too.
Oh yeah, totally. Maybe I'm looking at it with rose-colored glasses because I was younger, but the way I remember it personal computing used to be about enabling users. At some point there was this huge attitude shift towards being condescending toward users and treating them like cattle. So now, instead of trying to bridge the gap between computer "user" and computer "programmer", we forcibly drive a giant wedge between them.
The underlying issue is that many novice users don't see the problem with being condescended to, even when this severely inconveniences the more "developer-like" power users we used to enable. That "wedge" is just what the Eternal September of personal computing looks like.
One more instance of how the interests of vendors and the interests of developers are not aligned. Microsoft and Apple don't want you learning portable skills -- they want to limit your future prospects to developing only for their specific platform.
noob here - how come no one is making a cross platform API to abstract away this stuff? whenever i read about opengl or vulkan or metal or whatever w/ the tutorial going "learn this engine to bypass complexities of bare api usage", it's my first thought
Vulkan is supposed to be the cross-platform API, but Apple isn't supporting it (and doing their own thing with Metal, as per usual). From what I've heard, Vulkan was originally "OpenGL 5" so while OpenGL continues to exist Vulkan is effectively its successor. There is MoltenVK, which allows Vulkan applications to run on top of Metal.
SFML (Simple Fast Media Library) and SDL are cross platform and hide most of OpenGL boiler plate. I've used SFML but just to make Shaders and output some text.
I think you're correct that the old GL API made it quick to get stuff working, but the modern GL is much nicer once you get past the overhead of setting up all the VBOs etc. That only needs doing once, and then you're set.
I've recently been following along a vulkan tutorial to get started with that, in the odd evening over the last few weeks. I'm six chapters in, and I've yet to even draw a single triangle. That's still about five chapters away. While I can appreciate that the flexibility of the setup to remove much of the implicit state contained within the GL state machine is good, I can't help but wish for a wrapper to just make it work for a typical scenario, and let me render stuff with a minimum of fuss.
I'm unsure about where Metal will fit in the future. No matter how great it is, it's a vendor-specific proprietary API and I suspect that Vulkan will be the next cross-platform API which will wrap Metal or DX12 when a native Vulkan driver isn't available.
I went to university ~'94, and we were certainly told in no uncertain terms that we were expected to cite anything we copied, code not an exception.
I don't think it means if you call SDL_CreateWindow, if that's what you mean with "on a certain line of code", but if you were to for example implement a window creation function by copying the contents of SDL_CreateWindow and adapting it.
EDIT: Citing everything is extra important when working on projects for courses, because even when its overzealous in terms of what is legal the point of doing the work is to show that you understand the concepts properly, and then its important for whomever going through your code to be able to tell which bits you actually worked on.
Thanks for bringing this to my attention! I've been very interested in the work the "Geometry Collective" is putting out there (discrete exterior calculus and related applications). Nice to see a course covering these fundamentals too. Coming from a different side of the computational world, I might just build a subdivision program from these bones to get thoroughly immersed.
I'd definitely second the ray tracer recommendation, starting from a 2D canvas and building a ray tracer to render a shaded sphere was really an "ah-ha" moment, as the math is quite approachable and you can get a cool result with not much more than some trigonometry.
3Blue1Brown has a great series on Linear Algebra.
His explanations are so clear that by the 2nd or 3rd video you'll already understand how it applies to computer graphics.
I agree. I've had quite a bit of exposure to linear algebra through other textbooks and online courses, and the 3Blue1Brown series explains the intuition better than just about anyone. In particular, the video on determinants really crystallized the concept for me.
I invite everyone to try all of these techniques and math tools in ShaderGif [42]. Hopefully you'll learn and make nice gifs in the process. Learning new math concepts is even better when you create art and share it after!
If you can, go take an elementary linear algebra course or prepare to spend time studying these. It is well worth it.
One thing I have found when hacking on my own engine (see here: https://github.com/Entalpi/MeineKraft) is that graphics APIs (especially OpenGL) can have a lot of hidden meanings or even old names still being used, etc. Try to find out how the API evolved and get the reasoning behind the design decisions. This way it makes more sense and it gets a bit easier to learn.
I've always been a fan of the NeHe GL tutorials. I learned programming starting with these 'back in the day' and really enjoyed it. Its modernized now but still maintained.
I've been learning (mostly 2D) graphics as my side project for a couple years now. I spend a ton of time on this project. I still feel like a beginner. It is one of the more complex topics I've ever delved into.
I've crawled through more topics than I can list here. Many of them were not easy to learn, due to disorganized learning resources and materials.
Documentation and information is scattered, frequently outdated, sometimes sparse, and just downright messy. OpenGL and its many quirks and legacy versions muddy the waters too. I've considered trying to pull this into one big guide, hopefully resulting in something like the Filament docs [1].
Side note: macOS (my dev env) is a terrible place to write OpenGL, I've learned. Debugging tools are practically non-existent.
You'll ultimately become a better dev (e.g. higher quality code, faster, and more maintainable) as you learn more of the underlying stuff. For web dev definitely learn how to do everything in "vanilla" js, html, and css at least a few times.
Some people think better at a lower level and some think better with abstractions. I for one feel more 'at home' at the lower level but can live with higher level abstractions if I know how it's done at a lower level :)
Thanks for the extra links, I'm building a base software rendering engine in Go just for this purpose. It still needs work to get to a good 'base' but it can be used as is to start learning CG from your notes and links.
https://github.com/MickDuprez/go-window
cheers.
Jamis Buck has a new-ish book out called "The Ray Tracer Challenge" that I've been slowly working through.
So far I really like the way it's written: everything is test-based, so you get a problem like: "given matrix X and vector Y, X * Y should be vector Z" and then you implement both the test and the code in whatever language you like.
I didn't assume a particular mathematical background for the students, so I introduced the relevant math in what I hope was a motivated way. Hopefully it can help others as well.
I've found SFML an easy way to get some stuff on the screen in 2D.
As far as true 3D graphics, I made a Minecraft clone using OpenGL... it was a nice project as, surprisingly, you end up using all the basic techniques as you tweak it, particularly when you try to get lighting and shadows working.
128 comments
[ 3.5 ms ] story [ 117 ms ] threadhttps://www.coursera.org/learn/machine-learning
There is a free intro to data science class on Udacity as well:
https://www.udacity.com/course/intro-to-data-science--ud359
Lastly, there's always Kaggle, which has plenty of resources to learn from, and competitions as well:
https://www.kaggle.com/
Book/code: http://www-bcf.usc.edu/~gareth/ISL/
Lectures: https://www.r-bloggers.com/in-depth-introduction-to-machine-...
http://vmls-book.stanford.edu/
And one more gold standard for more practical data science (with R) stuff. It introduces a more modern take on R (chaining functions together with the %>% pipe operator, which makes everything clean and terse).
https://r4ds.had.co.nz/
Data Scientist path - https://www.dataquest.io/path/data-scientist
Some of the projects peppered throughout the track: https://www.dataquest.io/projects
EDIT: Forgot to mention, almost every lesson uses a real dataset!
No other tooling needed until you've got the basics of vertex buffers and shaders down.
(20 year graphics veteran here who's boostrapped some coworkers)
I'd say, a good way to do it, is first learn theory, and apply it using simple tools that let you just draw on screen (like SDL). Then learn a GPU targeted API.
https://www.youtube.com/user/shiffman
I know some would say it's a bad language, but back in the day it was incredibly accessible and spawned a lot of shared code and tutorials. If you focus on the techniques and algorithms, treat the language as pseudocode rather than "the right way to do things", you can have a lot of fun and learn quickly things you can translate to whatever your language of choice is.
That really isn't how modern, accelerated graphics works - even 2D accelerated graphics! "Sprites" are slightly closer to the mark, but it goes far beyond that.
All that happens on the fly without intermediary frame buffer composition in between. The output goes directly to the display (over HDMI, eDP/displayport, DVI, etc.).
Yeah, and of course mouse cursor is a sprite in the traditional sense. Although on modern HW you could implement mouse cursor as a hardware layer.
C64, Amiga, MSX, NES, SNES, Sega Master System, etc. all supported hardware layer sprites back in the eighties.
I recommend reversing that - ignore the math and just get a triangle on screen using a trivial shader (takes a few dozen lines of code in WebGL), then learn about how shaders and matrices work by applying them to your triangle.
I spent a while getting an OpenGL environment setup in VisualStudio and got frustrated with the tooling as I've also been spending much of the last 3 years doing trivial web development. I ran across shadertoy and was able to whip up much of the core of the pathtracer there and very easily move it over to it's own project supper easily utilising REGL (https://github.com/regl-project/regl) in ~100 lines that included a camera, dynamic shader compilation based on a scene, etc...
There's a lot of room to do things incorrectly and not notice in audio, which makes it forgiving to learn: e.g. playing a sample at a different pitch can be done badly by adding or removing arbitrary samples, but resampling it with minimal distortion is actually a fairly intensive DSP problem. Or when computing a volume, the linear amplitude usually isn't the parameter you want to work with(see every UI where volume changes imperceptibly until you reach the bottom 10% of the slider), and while there are computations to convert between linear and dB values, you still have to qualify it with one of these various references and suffixes[0]. There's a lot of crossover between audio and electrical signal terminology that can make it hard to follow this material.
So you can spend a lot of time doing simple things well!
[0] https://en.wikipedia.org/wiki/Decibel#Voltage
https://mitpress.mit.edu/books/audio-programming-book
It's fairly heavy going, but very comprehensive.
It's free but please consider donating if you find it useful.
[1] https://thebookofshaders.com/
It includes code for 3D model loading, linear algebra, basic (OpenGL) rendering, and UX, and provides stubs for you to implement:
There's a lot of documentation in the wiki [2] to help you get started. A great resource, even if you can't take the class yourself![0] https://github.com/cmu462/Scotty3D
[1] http://15462.courses.cs.cmu.edu/fall2018/lectures
[2] https://github.com/cmu462/Scotty3D/wiki
For something a bit more modern, I'd recommend [0], but one might argue that old OpenGL is easier to learn since you don't have to setup your own shaders.
[0] https://learnopengl.com/Introduction
One of my longer-term goals as a TA for the class is to update Scotty3D to Vulkan or modern OpenGL.
EDIT: I wanted to expand on this point, as this is actually an important part of the philosophy of the design of the course. As the OP argues as well, it more important to learn the fundamentals of CG theory (eg rasterization, the rendering equation, solving ODEs/PDEs) than the specifics of any particular implementation (OGL, DX, etc). After taking 462, many students (including myself!) take the class 15-466 Computer Game Programing [0], which goes deep into more modern OpenGL implementations (admittedly, it's OGL 3.3, but it still covers shaders/VBOs/other important concepts that translate to modern APIs).
[0] http://graphics.cs.cmu.edu/courses/15-466-f18/
Even if you're talking about game engines, there's still a whole lot more to learn. This game engine book [1] has one chapter about the rendering engine and 16 more about other topics. Each chapter in there is at least one hefty book to get a good working knowledge of the topic.
It's great you have a resource where people can learn and experiment with these other things without having to learn to write all the code around it.
[1] https://www.gameenginebook.com/toc.html
Which is why when people without game industry experience start discussing 3D APIs adoption, they loose on how little the APIs actually influence the whole engine codebase.
With Apple working to eliminate all traces of OpenGL with Metal, and Microsoft already having abandoned it close to two decades ago, I feel it's close to the end of the road for fixed function OpenGL. It was a wonderful part of graphics development history that, sadly, future beginners will likely not be able to experience.
... but there are hundred of cross-platform APIs to abstract this stuff - unity3d, unreal engine, qt3d, etc...
I've recently been following along a vulkan tutorial to get started with that, in the odd evening over the last few weeks. I'm six chapters in, and I've yet to even draw a single triangle. That's still about five chapters away. While I can appreciate that the flexibility of the setup to remove much of the implicit state contained within the GL state machine is good, I can't help but wish for a wrapper to just make it work for a typical scenario, and let me render stuff with a minimum of fuss.
I'm unsure about where Metal will fit in the future. No matter how great it is, it's a vendor-specific proprietary API and I suspect that Vulkan will be the next cross-platform API which will wrap Metal or DX12 when a native Vulkan driver isn't available.
https://github.com/bartvbl/A-Hitchhikers-Guide-to-OpenGL
The students have to have citations to the docs if they went to help on a certain line of code. I wonder if that is normal these days.
I don't think it means if you call SDL_CreateWindow, if that's what you mean with "on a certain line of code", but if you were to for example implement a window creation function by copying the contents of SDL_CreateWindow and adapting it.
EDIT: Citing everything is extra important when working on projects for courses, because even when its overzealous in terms of what is legal the point of doing the work is to show that you understand the concepts properly, and then its important for whomever going through your code to be able to tell which bits you actually worked on.
http://billsix.github.io/modelviewprojection/
It in python, doesn’t involve matrices. It really only requires high school math, with the exception of the z axis.
Hope it’s helpful!
https://youtu.be/fNk_zzaMoSs
[42] https://shadergif.com/
https://drive.google.com/drive/folders/14yayBb9XiL16lmuhbYhh...
For ray tracing Peter Shirleys books are very good.
OpenGL stuff are usually found at docs.gl, https://learnopengl.com/About.
For Physically Based Rendering (PBR) material checkout the bool Real-time Rendering and all the cool stuff has been coming out of Siggraph these past years, https://blog.selfshadow.com/publications/s2013-shading-cours....
If you can, go take an elementary linear algebra course or prepare to spend time studying these. It is well worth it.
One thing I have found when hacking on my own engine (see here: https://github.com/Entalpi/MeineKraft) is that graphics APIs (especially OpenGL) can have a lot of hidden meanings or even old names still being used, etc. Try to find out how the API evolved and get the reasoning behind the design decisions. This way it makes more sense and it gets a bit easier to learn.
GLHF
http://nehe.gamedev.net/
I've crawled through more topics than I can list here. Many of them were not easy to learn, due to disorganized learning resources and materials.
Documentation and information is scattered, frequently outdated, sometimes sparse, and just downright messy. OpenGL and its many quirks and legacy versions muddy the waters too. I've considered trying to pull this into one big guide, hopefully resulting in something like the Filament docs [1].
Side note: macOS (my dev env) is a terrible place to write OpenGL, I've learned. Debugging tools are practically non-existent.
[1] https://google.github.io/filament/Filament.md.html
It might be more appropriate today to work top down. Install Unreal Engine, build a simple demo, and look at the code it generated and you can modify.
I'm a web guy, so all I know is frameworks (Angular, React, etc.).
[1] http://www.scratchapixel.com/
Also, Apress has a cool book about Python and graphics with some pretty intense source code found here: https://github.com/Apress/python-graphics
So far I really like the way it's written: everything is test-based, so you get a problem like: "given matrix X and vector Y, X * Y should be vector Z" and then you implement both the test and the code in whatever language you like.
https://pragprog.com/book/jbtracer/the-ray-tracer-challenge
I didn't assume a particular mathematical background for the students, so I introduced the relevant math in what I hope was a motivated way. Hopefully it can help others as well.
As far as true 3D graphics, I made a Minecraft clone using OpenGL... it was a nice project as, surprisingly, you end up using all the basic techniques as you tweak it, particularly when you try to get lighting and shadows working.
On my YouTube channel, I have over 100 WebGL Tutorial videos, and over 50 3d math related videos.
https://www.youtube.com/user/iamdavidwparker