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.
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
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.
You'll need to be comfortable with C++, but even without in-depth knowledge of the language, the tutorial takes you quite far.
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].
--
Though admittedly it is a bit chaotically organized.
That one combined with the ray tracing in 1 weekend series is a good start.
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.
https://pikuma.com/courses/learn-3d-computer-graphics-progra...
Good one.
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.
Time to bust out the khan academy courses I suppose.
https://courses.edx.org/courses/course-v1:UCSanDiegoX+CSE167...
https://www.amazon.com/Introduction-3D-Game-Programming-Dire...
Running the same code in a stackblitz or codesandbox environment would give you syntax highlighting, auto completion and so on
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.
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/
Here is one in Lisp I googled: http://www.ulisp.com/show?2NWA
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.
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.
[1] https://www.oreilly.com/library/view/ray-tracing-from/978149...
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.
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.
I shall add it to my "To read" pile of shame.
No longer works, sadly. Or is perhaps an incorrect/invalid link.
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
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.
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.