Graphics Programming Weekly
jendrikillner.com
jendrikillner.com
Edit: (If I wouldn't be so poor, I would donate to your cause as well.)
In all seriousness. It sounds like a cool book. Can’t wait til it arrives. Thanks for writing it!
- Write a software rasterizer
- Write a software ray tracer
You can do all that without exiting a programming language's standard library.
I wrote a simple ray tracer (primary rays only) in vanilla C89 in about 30 lines (if you don't count the PPM image library that I made):
https://github.com/d26900/JamaisVu/blob/main/tests.c
Lines 66 - 91.
Screenshot: https://raw.githubusercontent.com/d26900/JamaisVu/main/scree...
Here are great resources:
- https://www.scratchapixel.com/
- https://www.gabrielgambetta.com/computer-graphics-from-scrat...
- https://erkaman.github.io/posts/junior_graphics_programmer_i...?
What kinds of things would you ultimately like to make?
If you're finding that to be the obstacle with shaders, it may be helpful to start with just learning a library like Processing, or general graphics library in whatever programming language you're comfortable with, and then come back to shaders. It will still take changing how you think about things, but then you'll have some solid foundation.
Personally, I've found it the most helpful to have some kind of goal in mind. Some kind of image or style that I want to make, then figure out what techniques I need to learn to get there. Starting from the technical side can work, but then it can be easier to loose interest when things get challenging. When I start with an artistic vision, then I often find myself over my head in the technical things I need to learn, but I feel motivated to push through that to get to the end goal.
But he has 2 more:
https://gamephysicsweekend.github.io/
And you can do a very simple one in much less than 30 lines in C. ;)
Edit: Oops, it was the wrong one... This is the right one:
Sorry!
Or a business card's worth of space:
https://fabiensanglard.net/rayTracing_back_of_business_card/
The other key thing to understand, is that a GPU is across a network (PCI-X network generally) So when you call dispatch, your generally sending a message (encoding a command in a command buffer) to do the work later on on a different device.
> [numthreads(64, 1, 1)] > void main(uint3 threadIdx : SV_DispatchThreadID) {
the dispatch size (x, y, and z) are multiplied by the numthreads components (Some compiler SIMD stuff requires this) And that sum total threads (x * y * z) are launched. the index of the thread this particular invocation is launched on is left in threadIdx, you can then use that index to read and write from other buffers.
This is HLSL, but the same generally applies to most APIs. Then more of this just becomes implicit and behind the scenes for shaders dispatched in other contexts, since more is known implicitly about the context, and more is done by other units of the hardware.
Starting with a software renderer is nuts.
Start with unity, make an unlit shader, start doing basic effects (in colours, then using texture samples) using uv coordinates. (In frag, ignore vertexes to start with). Just remember youre just colouring a pixel, on a bit of a surface.
No, not really. You can write a simplistic ray tracer and rasterizer in about 10 - 50 lines tops:
https://github.com/d26900/JamaisVu/blob/main/tests.c
Lines 66 - 91.
The result/screenshot: https://github.com/d26900/JamaisVu
If this is "nuts", then so be it. Let me be nuts. :P
The OP already cited shaders as one avenue, and shaders are so so easy to get immediate results from; as opposed to making a small mistake in a path tracer and spending hours debugging why your screen just shows one colour.
Need to debug where youve gone wrong with a shader? Return float4(uv,0,1) and its working again.
Try to find a small and unusually talented team doing what you want to learn, and get hired by them. There is no substitute to learning from smart/experienced people.
(This is after learning the basics + the intermediate stuff.)
Shadertoy can be fun and you can learn lots of techniques and lots of math but you aren't learning graphics
Usually I teach the OpenGL pipeline in one session, but students have a lot of things to understand: Vertex shader has its own things to learn and without the fragment shader you do not see what you are doing. In the following lessons I dig into the details of each part independently. This approach works, but it requires a lot of abstraction from the beginnings and a lot of code to have trivial applications. Furthermore, it introduce latency in understanding the whole pipeline, they do not really 'get' why we have this pipeline and what each bloc does inside of it. Only after a few lessons, when they have all the pieces, everything clicks.
This year I tried another approach: I used at the first lesson exclusively ShaderToys with progressive exercices, the students were very happy to be able to create content directly and eagerly digged into the details by themselves. Naturally, as wanted, they felt the issue of not being able to create simple objects like a 3D cube and move in 3D.
The second lesson was then the perfect time to show the whole pipeline and the vertex shader was an almost obvious need!
Another change I made this year was switching from C++ to Javascript, I'm not yet sure which solution is the best. They both have advantages and drawbacks to learn OpenGL/WebGL.