Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Resources for Learning Graphics Programming
82 points by dbetteridge 79 days ago | hide | past | favorite | 53 comments
Hey HN

I've predominantly always worked in Web dev but always had an interest in 3D graphics, modelling and games.

What are your best resources for me to go from 0 to being able to write my own (basic) graphics renderer, eventually I'd like to get to the point of rendering scenes but understand that might be a long haul.




I see it's still up after 20+ years: NeHe at https://nehe.gamedev.net/

In 2005-ish I followed what is now called "legacy tutorials" and I just learned a lot about how rendering pipeline works in OpenGL + some basic 3d math and physics. The rope tutorial (https://nehe.gamedev.net/tutorial/rope_physics/17006/) was my favorite.

Also, my highschool math teacher was in awe when I was so familiar with vector math and matrices and it was so easy to grasp the concepts in class because I could visualize everything. This is a nod to a previous post here on HN: https://news.ycombinator.com/item?id=40983734


Sorry, no offence, but this is a terrible resource to start learning graphics. First of all good luck downloading those examples (most of the links are broken), then compile them (many examples were made for Visual C++ 6.0 or some niche IDE from 2000s). I loved NeHe around 2005 as well, learned a lot from it, even though later switched to web development and never used that knowledge. But this days better to choose something like https://learnopengl.com at least. Or better yet any resources on WebGL, since OP is a web dev. Concepts around shaders and modern programmable graphics pipeline still translates well compared to immediate mode OpenGL samples from NeHe.


None taken. Yes, it's not as polished as some of the more modern resources but I still see value in learning about the old ways.

Also, in case you missed it, most lessons have contributions for many languages and platforms. Just scroll all the way to the bottom. You can download the Perl variant of the 1st lesson if you want.


Thank you for this. I am planning to start teaching my 5-year-old mathematics now, just as I began teaching him to read when he was 2 years old. Now, he reads a lot, and his teacher has no difficulty explaining instructions during quizzes because he already knows how to read!


I think the best place to start is by getting your hands dirty with a real deal API. https://learnopengl.com/ is a great place for that. Oh and the best part is that the book is FREE.

You'll need to be comfortable with C++, but even without in-depth knowledge of the language, the tutorial takes you quite far.


https://learnopengl.com/ is a super popular recommendation, but I found it a bit lacking when trying to understand how things work. I tried using a college book instead, Computer Graphics Programming in OpenGL with C++ and found it more approachable.


Hot take: OpenGL is lacking when trying to understand how things work. OpenGL hides a lot of state from the API because it has a lot of cruft from when Graphics cards were ASICs. DirectX 11 and especially 12 and Vulkan are closer to the actual hardware capabilities of the GPU and state is more explicitly passed between stages rather than having a state machine hiding somewhere in the driver


I really liked https://webglfundamentals.org/ for learning the webgl api coming from a web background as well. The state diagram was also useful to understand the complicated api. There is also https://webgpufundamentals.org/ for the newer api.


+1 this is a great resource, and learning graphics with a web browser lowers a lot some barriers of entry.

Learning the lower end of graphics can be fun and a goal of its own, but you can also accomplish a lot and push more interesting things to your screen faster by using some readymade engine. As a web developer you may enjoy this (paid but very polished) ThreeJS course [1].

--

https://threejs-journey.com/


This is the most thorough resource I’ve found: https://www.scratchapixel.com/

Though admittedly it is a bit chaotically organized.

That one combined with the ray tracing in 1 weekend series is a good start.


ScratchPixel's articles are some of the best mathmatical breakdowns of rendering I've seen all these years, along with perfect diagrams, charts, and formula noations. Defiitely worth its weight in gold if you approach topics from a logics/proof standpoint.

But man, I feel I was waiting for that path tracing article for 8 years now? It's not even on their recent roadmap. Treat the unreleased sections as wishlists instead of a "upcoming" section.

>Though admittedly it is a bit chaotically organized.

looks like they completely revamped the website (and their roadmap seemed focused on revamping existing articles over making new ones). The beginners section now seems to make enough sense if you were following a college raytracing course. The other sporadic articles are pushed farther down to prevent confusion.


I like this too. I even found a mistake and the authors were open to correcting it which is always a good sign


These courses always looked fantastic to me:

https://pikuma.com/courses/learn-3d-computer-graphics-progra...


That would be my recommendation as well. this was the first resource that made me really grok 3d graphics in an easy and approacheable way. the course is mostly speaking about cpu rendering but the math foundation is all there and it's nice to also be able to code a simple implementation together.

Good one.


I thought about Pikuma's courses when I read the title. Glad it was already mentioned here!


I took the road the other way around, from being a game and graphics programmer to web development and never been happier.

That said I would start by learning three things in parallel: a game engine like Unreal, Unity, Godot, a graphics API like DirectX or Vulkan and algorithms and math. I quiet stress the last part: learning algorithms is very important to build something, understand how game engines work and being able to improve what you already have.


Ugh I know, I did plenty of linear algebra, matrices and high level maths in uni and then basically lost all knowledge of it once I graduated and started in web-dev.

Time to bust out the khan academy courses I suppose.


Math Academy has been getting pretty good reviews around here lately (no affiliation)


Maybe You'd want to give a try to.

https://courses.edx.org/courses/course-v1:UCSanDiegoX+CSE167...


Even though some people will tell you old school OpenGL fixed function pipeline is bad or out of date or whatever, I still really liked learning from Lighthouse3D (http://www.lighthouse3d.com/tutorials/) and Edward Angel's book OpenGL: A Primer (https://www.pearson.com/en-us/subject-catalog/p/opengl-a-pri...).


I can recommend https://m.youtube.com/playlist?list=PLplnkTzzqsZS3R5DjmCQsqu... for beginners. It's aimed to understand the basics of Rendering at the beginning and ends in some neat advanced topics. I would highly recommend doing the exercises. Just watching this is not enough and will get you to a point where you will feel like you are very capable, but you are probably not.


I'm a little surprised no one has recommended the Frank Luna books. They're great introductory books. I used the DX9/DX10 books during my education when writing my game engines. I haven't read the DX12 book, but DX9/10/11 were basically the same structure only updated for the new APIs.

https://www.amazon.com/Introduction-3D-Game-Programming-Dire...


If textbooks are more your vibe, OP, I’d also look into Real Time Rendering. Solid foundations with later chapters delving into modern techniques. They keep their editions fairly fresh too!


I would also recommend that one. Those two were the foundation for my graphics knowledge when I was learning.


I actually have that one on my shelf already, just finding the time to delve into it!


https://mrdoob.com/projects/htmleditor/

;-)


This is nice and pretty useless at the same time ^^

Running the same code in a stackblitz or codesandbox environment would give you syntax highlighting, auto completion and so on


This suggestion is not a step-by-step education resource, but Jendrik Illner has a great blog page which has a weekly roundup of graphics programming articles.

It can be quite a rabbit hole when you find that he's up to 38 pages of weekly roundup links going back to 2017.

https://www.jendrikillner.com/#posts


Me and a friend build our own Graphics engines based on https://learnopengl.com I can highly recommend this to everyone who gets started with computer graphics. It is a lot of new information but not the most modern Graphics library, but the information will help you understand the field and pickup any other graphics library quicker. Once I had a small project up and running I started looking at https://emscripten.org/ to combine it with some web experiments and more easily share my work with other over the web. I also started looking at https://vulkan-tutorial.com/ and https://webgpufundamentals.org/ to experiment with geometry shaders.

Next to Realtime Graphics you could also dabble into the world of Ray-Tracing. Personally I'm still quite new to this field but my master thesis supervisor also gave lectures at an other university where they recoded a lot of lectures during Covid. Advanced Computer graphics at the UU for example https://ics-websites.science.uu.nl/docs/vakken/magr/2021-202... The course recommends https://raytracing.github.io/ as a resource to students, and I can also recommend this.

As a small note to end with, the website(s) of professors giving computer graphics are a true tressure trove of information: https://jacco.ompf2.com/ https://www.3dgep.com/cpp-fast-track-1-getting-started/


Check out graphicsprogramming sub-reddit, people ask that question there fairly frequently. Writing a real-time renderer basically comes down to learning a graphics API like Direct3D and then implementing various tricks and techniques from books like "Real-time Rendering".


There are raytracing tutorials going back to the early 1990's at least (because there is one in Graham's Ansi Common Lisp).

Here is one in Lisp I googled: http://www.ulisp.com/show?2NWA


If I could ask a tangential question within this topic: How's the professional side of graphics programming these days? Maybe not right this moment since nothing in tech is great, but just the vibes and changes over the last decade. I got some 8 years in gaming, but would still like to one day turn my hobbyist toy renderers I do on the side into a chance to dig into some professional grade engines.

My current vibe is that it just seems impossible, with 30 different ways a graphics programming interview can go, and positions are shifting more to Unity/Unreal engine devs over someone who can manage/maintain a shader pipeline or dig deep into optimizing buffer queues and draw calls.


Povray source is available (povray.org), if you'd like to look at the source for a nice ray tracer, or things like ogre 3d (http://www.ogre3d.org) etc have source available.


POVRay is a great source for learning. I haven't looked at it for years, so I don't know how it aged, but it basically taught me C and graphics programming.


huh, so Pov ray is still updating after all these decades. I used that in a college course a decade ago and it felt dated. But it's a small but fully featured tool, so you can't really go wrong with it as a learning jumpstart. Good starting step and you can jump into pbrt later to see how a "middle grade" ray tracer operates.

I'm a bit less sure about Ogre3d. Another very old repository, but it's been through quite a few revisions over the years. I don't know how clean the code would be for a beginner approaching it. But if you learn by reading and changing code, it sure would be the exact challenge you are seeking.


If you want a deep-dive into the mathematics as well, I really liked Ray Tracing from the Ground Up by Kevin Suffern [1]. The book focuses on the theory and mathematics of ray tracing, and uses C++ to build a ray tracer. The code however is simple and explained really well so you could adapt it to the programming language of your choice.

[1] https://www.oreilly.com/library/view/ray-tracing-from/978149...


I found this one to be useful. OpenGL GUI based demos: http://www.songho.ca/opengl/


If you're interested in understanding the graphics algorithms and implementing them yourself, as opposed to using an engine or a library, check out https://gabrielgambetta.com/computer-graphics-from-scratch It guides you through writing a software rasterizer and a raytracer, and most of what you learn can be applied to GPU programming.


From a common lisp learner's perspective, I've had

https://github.com/vydd/sketch for 2d https://github.com/kaveh808/kons-9 for 3d

on my to-play-with list for a little moment now, waiting for a chance.


The graphics programming discord is the nicest community I've ever been a part of. Huge recommendation to hang out there.


Would recommend the Pikuma 3D graphics course


that is also my suggestion as theres absolutely nothing like it! really well explained, good review of the gfx maths, and both teacher and students inside the platform are really approachable as well.


I can recommend Cem Yuksel's youtube videos about interactive computer graphics - https://www.youtube.com/watch?v=UVCuWQV_-Es&list=PLplnkTzzqs...


Thanks everyone that mentioned pikuma.com. Just keep in mind that our 3D Programming lectures cover mostly software rendering and math intuition behind it, and not so much advanced GPU stuff.


Tiny code Christmas was a lot of fun the last couple of years. That covers a lot of the basics in a beginner friendly way.

https://tcc.lovebyte.party/


I'm writing lecture notes about graphics programming, mostly focused on the math behind, if you like this kind of material, they should be ready by December ;)


I answer this question over and over on Reddit. So, here’s a wall of text for you :)

Here's the list of links I give everyone getting started in graphics programming in general.

The main thing you need to know is https://fgiesen.wordpress.com/2016/02/05/smart/

OpenGL is a good API to start with. There's a lot to learn regardless of which API you use. Once you can do an animated character in a scene with lighting, shadows, particles and basic full-screen post processing, you'll know how to proceed forward on your own from there.

https://learnopengl.com/ https://raytracing.github.io/ https://gamemath.com/book/ https://www.gameenginebook.com/ https://realtimerendering.com/ https://google.github.io/filament/Filament.md.html https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-... https://developer.nvidia.com/nsight-graphics https://renderdoc.org/

A common mistake I see in beginners that you should definitely NOT do is to try to make completely self-contained classes like `tree.draw();`that attempt to set up and tear down all of the OpenGL state required to draw an object. The code required to make `tree.draw(); mainCharacter.draw(); rock.draw(); dog.draw();` work in random order is not only a very slow way to use GL, it is also extremely error-prone because the state set by an earlier object can accidentally affect a later object in unplanned ways.

Instead, it is much better to have all of the code for actually rendering a depth/shadow/static/animated/particle/UI pass contained in a function that handles 100% of the state setting for it's entire pass in a self-contained way. When you can look at the code all at once it becomes much easier to the straight in your head. It also makes it easier to set up in an efficient way.

Use https://realtimecollisiondetection.net/blog/?p=86 as a guide. Sort according to https://i.stack.imgur.com/JgrSc.jpg and you'll be doing better than most hobby engines.

[Modern Mobile Rendering @ HypeHype](https://enginearchitecture.org/2023.htm) describes a modern, high-end commercial implementation of the command buffer idea that started back in 2008 with the Order your graphics draw calls around! article. Obviously, you don’t have to be that advanced right out of the gate. But, it demonstrates a goal.

It's not a bad idea to have convenience classes for loading and specifying textures, shaders, meshes, and for packaging them up as a model. But, after loading those classes should not call more OpenGL functions until it is time to unload them.

Bonus points if you can load a large number of meshes into a small number of buffer objects, for loading asynchronously and for using glMultidrawElementsIndirect in your render pass loops.

Another common mistake is to make a scene graph with state modifiers. Like "Everything under this tree node is red plastic. Everything under this tree node is rippling". Horrible idea. Takes a huge amount of effort to semi-optimize.

A layout graph is fine. "The gun is attached to the hand of the character in the jeep on terrain segment 22 in sector[5,5]". With that you just need to figure out how to flatten the transforms quickly.

But, resolving arbitrary state permutations at runtime is fighting against the hardware and the driver.

Read through https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-... for more insight under the hood.


minor error: https://i.stack.imgur.com/JgrSc.jpg

No longer works, sadly. Or is perhaps an incorrect/invalid link.


Odd. Works for me my phone, but not my desktop

Here’s an alternate link https://community.khronos.org/uploads/default/original/2X/4/...

It’s from https://www.slideshare.net/slideshow/beyond-porting/30219704

https://youtu.be/-bCeNzgiJ8I


I appreciate the wall!

I shall add it to my "To read" pile of shame.


https://raytracing.github.io/


There are multiple skills here that you are inadvertently and confusingly asking for.

1. Do you mean graphics algorithms? Like how to turn concepts into pixels? Offline rendering for film is nearly the same as realtime video game rendering from a math perspective... just the techniques / estimations to simulating light must be way faster for video games and GPU coded.

Offline rendering for movies can take hours per frame. That's why 3d movie scenes look so much better.

2. Do you mean GPU programming specifically? Whether you render realtime like in a video game, or offline for hours, GPU programming is a specialized skill set. GPUs are faster at many parallel programming tasks that show up in rendering.

3. Do you want a toy? An offline, simple renderer can be built in under 100 lines of code. https://www.kevinbeason.com/smallpt/

4. Do you want to handle other objects (ex: triangles?) Features that video game programmers care about? (Ex: Uber Shaders?). Features movie producers care about? (Unbiased rendering??). These are all specialized skills above and beyond the basic concepts.

-----------

Rasterization, even today on 2024, remains the bulk of rendering for realtime video games even as modern GPUs and Programmers have added a little bit of raytracing.

Rasterization conceptually is related to the painters algorithm but a bit more optimized. Draw things furthest away from the camera: then draw nearer things 'over' the old stuff until you've drawn everything.

It's pretty easy to draw just one object in the screen given its relative position, and it's alleged color (or textures: which define what sequence of colors it has on its surface). And a BSRF (a mathematical definition of how light interacts with that object). You will likely start with an easy Phrong shader/BSRF but Phrong shading is just for beginners to get started. More realistic and more convenient algorithms (ex: the Uber Shader) are known today that are used in practice. But it's all just simulating light and how it scatters on a surface. Studying new BSRF functions and figuring out which ones to use in different circumstances is a lot of the practice today, but is mainly the artists job and not the programmers job anymore.

Repeatedly drawing a million such things from back to front (or: through the use of a depth buffer to determine which objects were in front in O(n time)) is also relatively simple.

---------

Raytracing is the opposite. You start with the light that 'should have entered the screen's, then you reverse that light and trace the rays backwards, simulating where the light could have come from. When light reaches a point, you calculate where it could have bounced from and then you keep doing that until all light in the scene is accounted for.

Both these techniques are simpler than they sound (!!!!). The difficult part is always the implementation details: making these techniques fast enough for modern use.


That's exactly the problem for a newcomer. Graphics is a wide and complicated field and the newcomer does not even know what ask.

I've had the same problem for 10 years or so. But there have always been full-time jobs completely unrelated to graphics, so I have never spent significant time to attack the issue.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: