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.<p>It includes code for 3D model loading, linear algebra, basic (OpenGL) rendering, and UX, and provides stubs for you to implement:<p><pre><code> - 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)
</code></pre>
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!<p>[0] <a href="https://github.com/cmu462/Scotty3D" rel="nofollow">https://github.com/cmu462/Scotty3D</a><p>[1] <a href="http://15462.courses.cs.cmu.edu/fall2018/lectures" rel="nofollow">http://15462.courses.cs.cmu.edu/fall2018/lectures</a><p>[2] <a href="https://github.com/cmu462/Scotty3D/wiki" rel="nofollow">https://github.com/cmu462/Scotty3D/wiki</a>
I think the author of this guide doesn't remember the mindset that a beginner is in when they first start learning graphics programming (or really any subject).<p>Why is someone reading this tutorial in the first place? It's likely because they have some end goal in mind, and are looking to get from 0 to that goal as quickly as possible. For most readers, this is probably making a game. Following the advice of this guide will give the reader a deep understanding of how 3d graphics works, but it won't bring them much closer to making a game than they were when they started.<p>Why am I bothering to point this out? Because countless guides like this exist that confuse neophytes into believing that the subject they wish to learn is difficult and requires learning countless prerequisites before they can get started tangibly moving towards their goal. It's demotivating. A lot of the knowledge in this guide is good to know but ultimately not immediately relevant to someone seeking to achieve some higher level graphics goal. It feels like the equivalent of trying to teach someone programming by starting them at assembly.<p>I personally think that this guide should be directed towards someone who has had experience noodling around with OpenGL or a game engine and wants to reach the next level. In order for any of the lessons this guide wishes to teach to be impactful, the reader needs the necessary context to understand why learning them is relevant to 3d graphics and by extension the reader's end goal. Starting off by making a ray tracer is a cool idea for example, but does the author honestly believe that it's more useful than just learning OpenGL first? It might be more "confusing", but they're going to have to learn OpenGL (or some game engine) at some point whether they want to or not if their goal is to make a game.
Start with WebGL, Shadertoy.com, and jsfiddle.net.<p>No other tooling needed until you've got the basics of vertex buffers and shaders down.<p>(20 year graphics veteran here who's boostrapped some coworkers)
It depends on your motivation but if you really want to learn about graphics programming (as opposed to learning an API) then I think the best way to do so is to remove any API from the picture. There is an absolutely phenomenal book that does just this: Andre LaMothe's 'Tricks of the 3D Game Programming Gurus'. It was published in 2003 but when you remove APIs from the picture it's just as relevant today and will remain so for the foreseeable future.<p>The book starts with little more than plotting a pixel on the screen. By the end you'll have a complete lit, shaded, 3D game engine that you've written entirely from scratch. And in the process you will learn absolutely everything that goes into it.<p>And one thing I'd add is that this might sound somewhat overwhelming but it's really not. The book is extremely well written and clearly was a labor of love. If you get some pleasure out of math and code, you'll have no technical troubles working your way through the book and in the end will be rewarded with an intimate, flexible understanding of graphics development that won't be hamstrung by dependence on a specific API.<p>[1] - <a href="https://www.amazon.com/Tricks-Programming-Gurus-Advanced-Graphics-Rasterization/dp/0672318350" rel="nofollow">https://www.amazon.com/Tricks-Programming-Gurus-Advanced-Gra...</a>
I will highly recommend ray tracing in weekend <a href="http://www.realtimerendering.com/raytracing/Ray%20Tracing%20in%20a%20Weekend.pdf" rel="nofollow">http://www.realtimerendering.com/raytracing/Ray%20Tracing%20...</a>
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.<p>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.<p>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].<p>Side note: macOS (my dev env) is a terrible place to write OpenGL, I've learned. Debugging tools are practically non-existent.<p>[1] <a href="https://google.github.io/filament/Filament.md.html" rel="nofollow">https://google.github.io/filament/Filament.md.html</a>
The most incredible educational experience of my life was this course I did at Columbia University while in High School on game programming. At the end of the course we made our own game with OpenGL, but for the first week or so we'd have basically math classes in the morning on he physics of lighting, and then in the afternoon we'd implement the things we did in C. It was where I was introduced to lots of math concepts, including vector math that I would not see in school for another year or so.<p>At any rate, at the end we built our own raytracer, and say a text file with vertices that was given to us produce an image on the screen from 100% code that we'd written ourselves. It was one of the most empowering, deep intellectual experiences I've ever had.
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.<p>It's free but please consider donating if you find it useful.<p>[1] <a href="https://thebookofshaders.com/" rel="nofollow">https://thebookofshaders.com/</a>
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.<p><a href="https://youtu.be/fNk_zzaMoSs" rel="nofollow">https://youtu.be/fNk_zzaMoSs</a>
I picked up graphics maybe three years ago and have been mostly learnt all the stuff I needed through different sites scattered all over the internet.<p>For ray tracing Peter Shirleys books are very good.<p>OpenGL stuff are usually found at docs.gl, <a href="https://learnopengl.com/About" rel="nofollow">https://learnopengl.com/About</a>.<p>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, <a href="https://blog.selfshadow.com/publications/s2013-shading-course/" rel="nofollow">https://blog.selfshadow.com/publications/s2013-shading-cours...</a>.<p>If you can, go take an elementary linear algebra course or prepare to spend time studying these. It is well worth it.<p>One thing I have found when hacking on my own engine (see here: <a href="https://github.com/Entalpi/MeineKraft" rel="nofollow">https://github.com/Entalpi/MeineKraft</a>) 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.<p>GLHF
Shameless self-promotion:<p>On my YouTube channel, I have over 100 WebGL Tutorial videos, and over 50 3d math related videos.<p><a href="https://www.youtube.com/user/iamdavidwparker" rel="nofollow">https://www.youtube.com/user/iamdavidwparker</a>
The single most helpful thing I discovered for <i>learning</i> android opengl es graphics programming is that it <i>does</i> have error messages, after all! [abbrev code, use to lookup docs]<p><pre><code> int error;
while((error=GLES20.glGetError())!=GLES20.GL_NO_ERROR) {
msg += android.opengl.GLU.gluErrorString(error);
}
</code></pre>
Also, the offical android opengl es 2.0 tutorial is wrong in subtle ways (after the non-subtle wrongnesses were corrected).<p>TIL "advice" can be countable: <a href="https://blog.oxforddictionaries.com/2014/05/30/advise-advice/" rel="nofollow">https://blog.oxforddictionaries.com/2014/05/30/advise-advice...</a><p>> <i>Advice</i> is mainly used with the first meaning, and in this meaning it is a mass noun (that is, it has no plural). The business/legal meaning, however, is a count noun: it has a plural form, <i>advices</i>.
If anyone wants to play around with Computational Geometry and Python, I'd recommend as a great starting point:
<a href="http://blancosilva.github.io/post/2014/10/28/Computational-Geometry-in-Python.html" rel="nofollow">http://blancosilva.github.io/post/2014/10/28/Computational-G...</a><p>Also, Apress has a cool book about Python and graphics with some pretty intense source code found here:
<a href="https://github.com/Apress/python-graphics" rel="nofollow">https://github.com/Apress/python-graphics</a>
Here is my work in progress for intro OpenGL programming<p><a href="http://billsix.github.io/modelviewprojection/" rel="nofollow">http://billsix.github.io/modelviewprojection/</a><p>It in python, doesn’t involve matrices. It really only requires high school math, with the exception of the z axis.<p>Hope it’s helpful!
Jamis Buck has a new-ish book out called "The Ray Tracer Challenge" that I've been slowly working through.<p>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.<p><a href="https://pragprog.com/book/jbtracer/the-ray-tracer-challenge" rel="nofollow">https://pragprog.com/book/jbtracer/the-ray-tracer-challenge</a>
There are so many comments here missing the point saying "why? just use "X" API" or "this is a waste of time when you will need 'X' API anyway" etc. but they miss the point. It's about 'how' graphics work, not building game engines.<p>Computer graphics is more about producing an image on a computer screen and whether it's for image processing or a game engine renderer it's the same process and very useful to know whichever field you want to pursue.
The best way to learn computer graphics programming is to first ask what you want to do with it. Most people interested in this topic have some end goal, be it just writing a game. In that case, writing raytracers and rasterizers may just be a waste of time, when the main interest isn't the interworkings of math, but to put something up the screen. For a reasonably wide range of modern tools, its absolutely not necessary to know any deep math to bring to screen what you want.
Scratchapixel[1] is also a helpful resource for explaining the basic concepts.<p>[1] <a href="http://www.scratchapixel.com/" rel="nofollow">http://www.scratchapixel.com/</a>
I'll plug the materials for the one-weekend class I taught on computer graphics: <a href="https://avik-das.github.io/build-your-own-raytracer/" rel="nofollow">https://avik-das.github.io/build-your-own-raytracer/</a><p>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.
My very first raytracer was <a href="http://canonical.org/~kragen/sw/aspmisc/my-very-first-raytracer.html" rel="nofollow">http://canonical.org/~kragen/sw/aspmisc/my-very-first-raytra...</a> and was quite a bit easier than I expected. My second one was a bit under 1K in Clojure: <a href="http://canonical.org/~kragen/sw/dev3/raytracer1k.clj" rel="nofollow">http://canonical.org/~kragen/sw/dev3/raytracer1k.clj</a> or unobfuscated: <a href="http://canonical.org/~kragen/sw/dev3/circle.clj" rel="nofollow">http://canonical.org/~kragen/sw/dev3/circle.clj</a><p>I was pleasantly surprised by how easy it was to compute the pixels, but getting them on the screen was a huge hassle. So I wrote <a href="https://gitlab.com/kragen/bubbleos/tree/master/yeso" rel="nofollow">https://gitlab.com/kragen/bubbleos/tree/master/yeso</a> to make it trivial. I haven't ported a raytracer to it yet; I'll do that soon!
I think this article, and the comments here, are a splendid example of how deep (and often confusing) 3D graphics can be.<p>One of the things I appreciated about the Glide3D API for the old VooDoo cards back in the day was how basic it was relative to the work of getting the 3D stuff on the screen.<p>There are several ways in which you can "learn" 3D graphics; You can get it by theory, you can get it by API, and you can get it by modelling.<p>If you're someone who is a theory person you should start at the beginning and learn linear algebra and vector arithmetic. You can learn about projections, and camera "views" and project your 3D scene onto a 2D surface whether it is a computer screen or a plotter page. Once you get there you can then do hidden line, and then hidden surface removal. You can learn about the 'Z' plane and the clipping frustrum which lets you not worry about things that won't appear in your projection. With a relatively simple array of coordinates type data structure you can project triangles or NURBs onto your surface and draw pretty pictures. Then you can start learning about light and all the many ways it interacts with materials. At the end of this journey you can take a 3D model and render it in a photorealistic way, one frame at a time.<p>The second way to learn 3D programming is the API path. Here you don't really learn too much of the math, although having that background will help you understand what the functions are doing. You learn an API like Unity or Vulkan. These APIs have taken a lot the basic 3D programming and done it for you, you need to learn how to write shaders which decorate your surfaces in ways that simulate light or water or fog Etc. Generally you construct a scene with calls to set up the frame, and then call 'render' with the appropriate screen resource referenced. Blam! instant 3D scene.<p>The third way you might come at this is modelling things, building models in Maya or some other modelling tool that are built with skeletons, which is simply a data structure that identifies how different parts of the model can move in relation to other parts. You probably don't have to know anything about 3D math, but you have to have a good eye for construction of the models and the area in which those models are placed.<p>There are so many ways to go at this particular quest, each have their own challenges and rewards.
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.
<a href="https://github.com/MickDuprez/go-window" rel="nofollow">https://github.com/MickDuprez/go-window</a>
cheers.
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!<p>[42] <a href="https://shadergif.com/" rel="nofollow">https://shadergif.com/</a>
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.<p><a href="http://nehe.gamedev.net/" rel="nofollow">http://nehe.gamedev.net/</a>
I don't think the hindrance when starting to learn graphics programming is the math or the lack of ideas of what to build. The biggest problem is that the most known APIs (DirectX, OpenGL and especially DirectX 12 and Vulkan) are so badly designed and so poorly documented that it deters anyone trying to start doing anything. All these API are like magic invocation you have to make the calls in just the right order or it doesn't work at all. There is no real specification of what goes underneath and it can't be because the actual implementation is written by different vendors (Nvidia or AMD) which only slightly abides to the specification.
This is the old-line "bottom up" approach.<p>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.
fwiw, pbrt can be read online for free since earlier last year: <a href="http://www.pbr-book.org/" rel="nofollow">http://www.pbr-book.org/</a>
If anyone would like to see ray tracer code, have a look at pov-ray <a href="http://povray.org" rel="nofollow">http://povray.org</a> Its a venerable old ray tracer but has some of the best features around and the code is very readable (once you've got the basics). It's a different way to do things than the vertex/shader style rendering pipeline.
For anybody looking for a minimal cross-plateforme <i>modern</i> OpenGL hello world with a lot of comments: <a href="https://github.com/eliemichel/AugenLight" rel="nofollow">https://github.com/eliemichel/AugenLight</a><p>By <i>modern</i> I mean as in OpenGL 4.5 Core Profile, using future-oriented APIs (e.g. named buffers). Any feedback welcome!
I'm always on the lookout for tutorials that go deeper than just implementing single one off things. Been meaning to go through Handmade Hero.<p><a href="https://www.youtube.com/user/handmadeheroarchive/videos" rel="nofollow">https://www.youtube.com/user/handmadeheroarchive/videos</a>
I'm currently enrolled in an online Computer Graphics course on edX that has been an excellent introduction to the subject: <a href="https://www.edx.org/course/computer-graphics" rel="nofollow">https://www.edx.org/course/computer-graphics</a>
I've found SFML an easy way to get some stuff on the screen in 2D.<p>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.
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.
This sounds good for those who want to learn graphics programming for gaming and / or for animation etc. But where should a beginner start from to learn GUI programming without using existing frameworks or widget toolkits?
The article says "How to start" but it's more like "What to start with".
Anyway, I'll really like to have a reference for good computer graphics lecture videos which I am failing to find
I found myself having to remember how to do matrix calculations. Before I could count to 100 I was going back and back until I was reviewing basic math on the Khan Academy. Embarrassing but that is where to start.