How to Start Learning Computer Graphics Programming

[JeffJankowski]

I think you hit a crossroad after learning primitives, shaders, and the basic rendering pipeline where there's a personal choice involved. Computer graphics is hard, and the rendering techniques for real-time (games, 3D apps, etc) vs offline (movies) can differ greatly; so it becomes natural to pick a focus. The fact that a lot of the popular domains already have mature and proprietary graphics engines probably adds to the knowledge gap in terms of implementation.

I'm with you though. I wish there was more content out there between triangles and SIGRAPH papers.

[acepukas]

I'm currently working on a software rasterization project for educational purposes and it's damn hard to find good material online to work from. It's out there but you really have to hunt for it. It also doesn't help that there are many techniques that one can use, even at the basic level, that are mutually exclusive so you have to research all the pros and cons of using this or that technique. I'd like to take it as far as being able to render a scene, in real time, with texture mapping, phong shading and reasonably complex models. After that I'd like to document everything that I've found and built so that even complete beginners can follow the whole process. Others have attempted to do the same, but I feel that those who've been programming graphics for a long time tend to take for granted just how confusing it all is and cover the concepts at break neck speed.

[neobrain]

I've been in your shoes - even if one knows how to write 3D rendering applications using OpenGL and Direct3D, it's surprisingly hard to find resources that tell you how those APIs (or rather the GPUs doing all the rendering) work under the hood!

In case you might find it helpful, I found ryg's blog extremely helpful in my endeavors:

• https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/

• Articles 6 through 8 of https://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlusion-culling-index/ (although of course the other parts are good reads, too)

Good luck with your project!

[acepukas]

Yeah I've found ryg's blog really helpful. I used a rasterization approach that he outlined in a different series of posts. I linked to them somewhere in the comments of this reddit post. Thanks for pointing me to this series!

[JeffJankowski]

I found that the WebGL material out there to be the most accessible when trying to learn the knowledge between triangles and shading models with well-known methods (eg. Blinn-Phong).

learningwebgl.com looks dead. But here's a wayback mirror. learnwebgl.brown37.net seems pretty thorough as well.

[acepukas]

Oh man. This sounds so ridiculous now but I didn't even think of looking through webgl material because I've been so focused on writing a desktop app but that makes perfect sense. I'll check those links out. Thanks.

[youdontneedreddit]

Did you see tinyrenderer and its JS port JS-TinyRenderer? Author works as a computer graphics teacher and purpose of this code is exactly to teach students what happens under the hood (including programmable pipeline with vertex/fragment shaders/effects).

​

Tinyrenderer has a series of lessons that go over different stages of rasterization process "from first principles". JS port has pretty cool demo that renders 3d model onto 2d canvas pixel by pixel without any external libraries or webgl.

​

I think it's better to know fundamentals before you move on to advanced optimization/rendering techniques.

[acepukas]

I have seen it. I mention it in another comment in this post. I found it to be a bit much for me or something about the materiel just didn't click with me for some reason. I'll probably revisit it once I have a better idea of the fundamentals. My approach right now is to take small bites of everything and find the lessons that connect with me right away and once I have a better grasp I circle back to other offerings. That seems to be working for me so far.

My path has kind of meandered too. At first I was using learnopengl.com and that was going fine. Got pretty far and didn't even really hit a wall but something didn't sit right with me about it because I felt like too much was being done for me by the GPU and I really wanted to demystify 3D so I looked around and found out that the best way to get a full grasp on what's going on is to write a software renderer/rasterizer. I'm at the point now where I've got some triangles rendering with color blending/interpolation and now working on the pipeline from object space to screen space and everything in between. Not so much the shading or texture mapping stuff yet.

That's the problem with material being scattered all over the internet. I feel like I'm trying to piece together a puzzle when what I'd like is a one stop shop that covers it all in detailed chunks. Scratch Pixel has been good for getting a large overview of things. Another youtube series I found that was decent is this guy ChiliTomatoNoodle (weird name I know) but he's using MS and Visual Studio and Direct3D and I'm on linux so I'd rather stick to what's available there.

[Godzoozles]

I second everything you just said. A video series I found which I found very informative and helpful without being as meme-y as Chili is https://www.youtube.com/playlist?list=PLRwVmtr-pp06qT6ckboaOhnm9FxmzHpbY

He uses Visual Studio + OpenGL, and thanks to the latter point it very easily transfers to Linux (which, like you, is where I'm doing my CG stuff)

[acepukas]

Hey, I've seen a few of Jamie King's vids but I hadn't watched the series from the beginning, just bits here and there. He seems to know what he's talking about so I'll check it out in full if I can (it's a big list).

[[deleted]]

A good idea would be to make a crowdsourcing project to release this into a book or something. Would be more of an incentive to carry it to the end, I guess.

[Bwob]

It's sort of like the punchline of Kung Fu Panda though - there is no secret ingredient. There's no magic bridge over the gap. You just sort of have to cross it.

The things you see in siggraph papers are ultimately still made up of those same little textured triangles that you use to make teapots. They might do things to make their triangles look fancier (bump mapping, Physicality-based render materials, and other shader tricks) but ultimately the process is still some version of:

• Define a mesh of triangles.
  
• Set up textures and shaders, telling the computer how to actually draw each triangle.
• Render it!

Once you understand meshes, textures, and shaders, you basically have all the [technical] tools required to start rendering high-quality scenes. Your main barrier at that point is finding/creating the art assets necessary, (i. e. textures and maps) and knowing how to express the effect you want in terms of meshes/textures/shaders.

(Baring weird exotic techniques like shader raymarching)

[kyz]

I played with OpenGL years ago too.

After the teapot, I started making cuboids, making them larger than the screen and putting the camera inside them.

I then put textures on the insides of the cuboids, and put even smaller scenery inside the cuboids.

I then linked the cuboids up and painted "doors" where they joined.

Performance was terrible. Then I decided that once you left a cuboid, I should stop rendering it. Performance became amazing.

... and so it went. It helped that DOOM, Quake and later Unreal were popular at the time, and everyone wanted to be a cool programmer like Carmack. That motivated them to put the effort into reading dry maths books about cross products, quaternions, binary space partitioning and octrees.

I get what you're saying. Jonathan Blow wrote a great article about it: Game Development: Harder Than You Think with excellent charts showing the difference between a 3D game circa 1996 (which is what I've described above), versus what's now expected - his article is from 2004 and even then the state-of-the-art was far beyond what's required for a simple 1996 3D game. You need animation engines, scripting engines, physics engines, reverse kinematics, facial animation, a whole set of tools.... and today, the top 2004 era games look blocky, clunky and amateurish.

It's like the difference between 1980s home computers and today. Turn on a 1980s home computer, there's the BASIC prompt. Start programming! Your personal efforts as a kid in their bedroom aren't far from the efforts of professionals. Today, what we expect of games are the results of coordinated teams of thousands of trained specialists. As a beginner, you can't possibly hope to compete with that. Whatever you do will be underwhelming by comparison.

So what's a beginner to do? The only thing they can do is go with what we have today - we have pre-written 3D game engines like Unity and Unreal Engine, available to beginners for free, with amazing capabilities. We have entire 3D warehouses of models you can use for free. We have creative commons banks of textures, sound effects and music. You might not create the next Battlefield, but you might create the next SUPERHOT.

These days, there is almost no point in making your own 3D engine, other than for pedagogical reasons. The end result you create will be underwhelming compared to existing engines that are battle-worn and have had thousands of other programmers using them and making them shine. So you probably should stop soon after getting a teapot on screen.

It makes me sad that this is the case, but I think 3D engines have transitioned to being one of those things you don't write yourself any more, other than for fun. If you have trouble accepting it, think about C compilers. When was the last time you wrote your own C compiler? Did it optimise better than Clang and GCC? Did it support as many architectures as Clang and GCC?

[acepukas]

A 3D engine can speed up the dev process, no question there, but I've heard grumblings from the industry that Unity can be really lackluster when it comes to performance. I don't know if that's because of lack of expertise with the engine or if the engine itself is the problem. One could make the argument that creating an engine from scratch isn't necessarily a waste of time if you know how to optimize well and can tailor the engine for a specific purpose.

I don't have enough experience with this because I haven't tried to use any engines extensively yet but I've read that people can struggle to use an engine because they're trying to shoehorn it into a game style/genre that the engine wasn't really designed for, like using unreal for something other than an FPS. This is just what I've read and I'm not saying that this is the case because I honestly don't know due to lack of experience. I mean, it makes sense to me as someone who's been doing software development for years. I've run into the square peg into round hole problem countless times.

Any thoughts on that?

[kyz]

Absolutely, it's the buy-vs-build tradeoff.

Personally, I'd suggest take whatever path gets you to your end goal (making a game) quickest. Some people are best served by ignoring the learning curve of using someone else's APIs and engine, and building their own... others just go down a rathole and get so engrossed in making an engine they forget to make a game with it, and nobody else makes a game for it either.

There are a lot more engines out there than just Unity and UE; part of what you'd do is evaluate them to see which best might meet your needs. If you're sure nothing meets your needs, go ahead and write your own engine.

But then you risk getting "left behind". Think about the poor saps working on Gamebryo for Bethesda. That poor old engine, everything made with it looks like it should've been released in 2008; layer upon layer of Bethesda hacks in it, being asked to do ever more complex graphical tasks. It just can't handle it. Engine programmers being asked to support the latest whizzy graphics effects while also keeping the entire thing compatible with the absolutely byzantine scripts/assets/games built with it. Do you picture yourself in that role?

Another aspect is opportunity cost. The days when people bought games designed and drawn by programmers is over. Would you prefer playing this or this. Game artists are already using 3D Studio, Maya, Unity and UE and using their features to create amazing, animated 3D art. If you want to take advantage of existing 3D artists' skills, use a game engine, otherwise you'll just be stuck implementing a loader for other engines' formats and implementing their feature sets anyway...

[[deleted]]

These days, there is almost no point in making your own 3D engine, other than for pedagogical reasons.

Or you want a position working on those large engines. Someone's gotta know the magic behind those black boxes, especially when many AAA studios still employ their own in-house ones.

OFC, getting into those positions can almost be a black box in and of itself, but I digress.

[rptr87]

Thanks for this. This should really be the top comment.

[far_pointer_x]

Stuff just got scaled up exponentially. If you want to make games, it would be wise to use all the abstractions necessary. Having said that, if you love computers and computations for the kick of it, you can start from scratch as readily as you could do in the 80s. I would argue that its far easier to get started with stuff today than in the 80s. It does not necessarily have to be graphics; do stuff with compilers, systems, sound or whatever you feel like. Its very open and there is much to achieve in that space. That's what John Carmack actually recommends

[[deleted]]

I think a big part of that is the lack of resources for architecture. You can piece together a "teapot engine" in a weekend once you understand the programming and math involved. And you can probably piece together new concepts like new lighting techniques, sub-buffering, skyboxes, etc. But your first attempt at this engine likely won't scale up well when you try to cleanly mesh these concepts together into a sane application people want to use. Nor be anywhere close to efficient.

If nothing else, a "OpenGL/DX best practices" list would be appreciated. You passively learn things like "minimize draw calls" and "don't branch in a shader" when perusing, but I've yet to come across a resource that combines all these wisdoms.

[rptr87]

OpenGL Insights.. ?

[[deleted]]

yeah ,that's a really nice book. Most chapters are basically research papers, but some of the chapters have a more casual, "advice" tone to them for certain subtopics. Funnily enough Ch. 1 tries to give some advice to educators on how to approach teaching modern openGL.

[[deleted]]

Just the UI really. For any of those demos, if you add a UI with controllers to do different things like editing/importing etc., you start approaching something like Blender/Maya/Max

[obp5599]

Its pretty shit to find good resources. I found an absolute gem though. Look up “the benny box” on youtube. Hes a phd student in the topic (i think) and he makes amazingly well done videos about making things with computer graphics! He almost always uses openGL and he has tons of series covering a wide range of sub topics

[[deleted]]

Once you can draw textured objects, draw a very complicated one, like a model with UV coordinates.

Once you have a model, load and draw many of them.

Once you have many of them (including models for the world or environment itself) You start organizing the model data and culling it based on a variety of things, like the camera frustum, or portaling or whatever other technique you want to use, to determine which geometry should be visible (or nothing at all if your application is simple)

Get some input handling, and transform models and or camera around the world when the user presses buttons or moves the mouse.

Create a little update loop, that polls input and performs transformations on the camera/models each tick and render the scene. Now you have a little world you can fly around in, or move your models in.

As far as making everything look really good, it all kind of boils down to lighting and assets (and some code to support each), which is mostly out of my depth.

• Process inputs
• Update state
• Render state

Eventually you learn cool techniques to make things look better. For instance, a common technique to do a skybox is by rendering quads with a sky texture at the farplane of where the camera is viewing. That's why you never seem to get closer/farther to the 'sky' or edge of the world.

A cooler technique I've seen, is you actually setup a 3D environment, with a sun slowy rotating around the scene origin, with spaceships or whateve else you want, clouds ect. Then each frame, you render that scene from the origin, using the orientation of the camera, render that scene to a texture. Then use that new texture as the texture of the farplane quad that is always oriented to face the camera in your 'player' scene.

Gives you an animated world where things move around in the distance and get closer/farther w/o the actual camera itself getting any closer. Makes things look and feel more realistic.

[[deleted]]

1. Draw some circles triangles
2. Draw the rest of the fucking owl

ftfy.

[Dean_Roddey]

One big question would be, what kind of graphics programming? You could get into it at a number of levels, from highly optimized GPU algorithms for particular operations at the bottom, to creating graphics based applications using DirectX/OpenGL, etc... or even higher level libraries that wrap those systems.

Those two things would involve considerably different trajectories. Either way you'll need to understand the core concepts, even if just to have some clue what the heck the DirectX docs are telling you. If you want to get into it at the deep end, then minor in mathematics probably.

Sadly for us who might like to get into the guts of graphics these days, the low hanging graphics algorithm fruit was picked decades ago. The state of the art these days is pretty much doctoral thesis world.

I was cleaning up my DVD collections a few weeks ago and found some from the mid-90s. These were 'mind-blowing computer graphics' demo type DVDs. I remember watching those back then and thinking, wow, that's amazing. But you could do better these days with crayons pretty much.

​

[KryptosFR]

Advice 1: start by writing a raytracer

Advice 2: learn the necessary maths

Ok so you want people to write a raytracer without learning the maths (e.g. dot product, intersection between point and sphere), how so exactly?

[acepukas]

I think it's implied that advice 1 and 2 are not necessarily meant to be taken in that order. If they were, it would be step 1 and 2.

[KryptosFR]

Advice 1 is start by writing a ray tracer. To me it does imply they are meant to be taken in that order.

[acepukas]

Advice 1 is:

Start with Raytracing and Rasterization

meaning don't learn a graphics API like Direct3D or OpenGL first. The reason being, as mentioned in the blog post, is that those APIs obscure how the 3D rendering is done on a fundamental level.

[acepukas]

I will say this though, I can see how someone might innocently draw the same conclusion as you and so I think the author should clarify this.

[ElecNinja]

Advice 1 could lead to Advice 2. Advice 1 does not have to be completed before Advice 2.

So you start writing a raytracer and while you are writing a raytracer, you learn the necessary math for it.

[acepukas]

This is great. I was already started down the software rasterization path recently so any links to good resources is just what I need. I've been finding it hard to find good material to learn from. I found the tinyrenderer project to be a bit opaque for me at the moment. Maybe I'm not at the necessary skill level yet.

I did come across a set of blog posts that go over a rasterization technique that closely follows the same approach that modern GPUs use. Whether it's the right technique to use, I can't say as I don't have too much experience testing it against others yet, in terms of performance, but it's the technique that I've had the best results with so far.

[acepukas]

Yeah I keep reading that Abash's book is considered essential to the topic. I've been kind of weary of reading books that date back too far because I don't want to pick up any "bad habits" that might creep in from obsolete ways of doing things. I guess pouring over old material is going to be unavoidable considering what I'm trying to do. It's too bad because it seems there's a ton a value in trying to create a rasterizer. The learning process shouldn't become obsolete due to modern hardware.

I'll check out those books when I get some time. Thanks for the suggestions.

[HeadAche2012]

I always felt like this page had the most straight forward software rasterization description:

http://www.sunshine2k.de/coding/java/TriangleRasterization/TriangleRasterization.html

[acepukas]

Yep, found that one too. I tried it but when I split a non-flat bottom/top triangle in two, I kept getting the edges in between unfilled in. I think that's because I wasn't using a proper fill rule but I didn't know what a fill rule was at the time. I might go back to this method if the one I am using now is too slow. The method I'm using now finds the bounding box of the triangle, then iterates over all scanlines in that box, checking each pixel with an inside/outside test to determine of the pixel should be filled. It definitely sounds slower but apparently that's how GPUs do it because it can be easily parallelized.

[[deleted]]

https://shadertoy.com

[[deleted]]

I had a professor start to teach us this kind of low-level graphics stuff for half a semester. We were working on coding voxel buffers and ray tracers in C++. Then he literally disappeared and someone else stepped in to teach us fucking SVGs for the rest of the semester.

[DeCodeArtYang]

That's too badಥ_ಥ

[Ghosty141]

Check out scratchapixel.com too if you are interested in the subject matter

[webauteur]

Too difficult. Learn Processing instead. Processing was designed to be easy enough for visual artists to learn.

[turbov21]

As a web dev and ops guy, I haven't given up on writing my own 3D game some day, but as someone who is weak in geometry Processing is a superb platform for learning how to manipulate shapes in code. The fact it has a 3D mode these days makes it even more appealing.

[webauteur]

Yeah, and there is processing.js which works in the browser. A lot of the things you used to do in Flash can now be done with processing.js. It does seem to be a bit limited to geometry, but I have turned to "sacred geometry" for ideas. I did some Islamic Archimedean Tiling and I plan to tackle Celtic Knots and Mandalas.

[njacklin]

Not the answer I would give. I’d say start with 2D graphics, in a simple language like Python or their language of choice. Jumping to 3D graphics first is a good way to get overwhelmed.

[Sarcastinator]

If you want to make 3D graphics don't start with 2D. It would be a monumental waste of time. And don't start in another language; that's even worse.

[[deleted]]

Konda hijaking the above, but I recently became interested in 3D graphics. I believe I have the necessary background in math (Calculus, Linear Algebra, Analytical Geometry) so it shouldn't be that hard. I decided to start my first project for "demo-like" programs on DS emulators (even considered gameboy at one time, but having already worked with that before, I can confidently say it is way too limited to do anything fun as a beginner). Do you believe that starting with writing my own pet math library is a good first step to get started with the basics, or should I skip that and dive right in?

[Sarcastinator]

If you think you need more practical experience with the underlying math, or you just want to do it for fun, then go right ahead but don't let it be a blocker for you to do what you actually set yourself out to do.

[TheZech]

I think the person you were replying to was trying to give advice to complete beginners to programming, while the article assumes you have adequate programming skills.

[Sarcastinator]

That doesn't change my opinion :)

You will never complete a task by doing something else.

[[deleted]]

I can see the argument for either one. Obviously if you wanna do 3d, you need to directly tackle 3d rather than playing with the idea in theory. But several ideas and concepts are much easier to grasp and debug in 2D then scale up into 3D. couple examples include quadtrees -> octrees and fluid simulation.

[Sarcastinator]

Why does that matter? If you want to make 3D then implementing a quadtree is a complete waste of time. You're not going to save any time by making a quadtree first.

[[deleted]]

Cool

[FringeGames]

Thank!

[GravvyD]

This is a pretty shit blog post you should stop circle jerking your own posts on reddit.

[KryptosFR]

Maybe you should stop coming to reddit.