Thread by @erkaman2

How To become an advanced graphics programmer:
Some general advice and tips from me, an expert graphics programmer
huge thread below.

If you are at the level at which you can comfortably
read e.g. advanced GDC presentations and siggraph papers, and
then implement them by youself in an reasonable amount of time,
I consider you an advanced graphics programmer,

and plenty of game companies would probably be interested in your skills.
How can we acquire this level of skill? I shall tell you how I did it!

Something that I think all beginning graphics programmers should do,
is implement their own little rendering engine. I did this when I was a
beginner, and implemented things like:

* rendering of particle systems
* water rendering, with dynamic reflections
* ambient occlusion'
* deferred rendering
* view frustum culling
* shadow rendering
* anti aliasing.

and so on and so forth. working on a rendering engine and implementing
all kinds of rendering features, is IMO the best way to go from
beginner to intermediate.

* Whenever you implement something suffienctly advanced, make sure to
write a blog post about it. Writing blog posts allows you to deepen your understanding
of what you've implemented, and improves your communication skills, which
is very important in this industry.

and also, sharing your blog posts with people, often results in interesting
discussions with other graphics programmer, and this deepens your understanding
even more.

* Make an active effort to keep up with the latest developements
in the field. Every week, read the latest blog posts, and latest papers that
people post on twitter.

Note that there is not always time to read all the new papers from beginning to end.
in this situation, I think it is enough to skim the paper, and skim until
you understand the main idea behind the paper.

Papers can contain lots of nitty gritty details, but I think these are only
necessary to understand, if you are really gonna sit down and implement the paper
yourself. But if you're pressed for time, understanding the main idea
is more than enough in my opinion.

If you have the main idea of the paper understood, then that is enough when you want to
incorporate the technique into your future projects

IMO the main characteristic of an advanced graphics programmer, is being able to implement an advanced siggraph/eurographics/etc paper within a reasonable amount of time.
How do we implement a paper? Below is my technique.

read the paper from beginning to end a couple of times. The section I usually
spend most of my efforts is often called "method".

from this section, extract a minimum viable prototype. That is, strip away
all possible optimizations, and figure out how to implement the technique
as simple as possible, disregarding things like performance.

once we have a prototype on our hands we can already evaluate a couple of things:
how difficult is it to integrate into our current engine?(very important in the real world)
is the visual quality of this technique good enough for our purposes?

once this has been evaluated, we can start looking into implementing optimizations
and adding the advanced parts of the technique.

* one thing I think is very important when implementing papers, is that we
have a "ground truth" to compare with. e.g., if implementing a real-time
indirect illumination technique,

then you should also implement a path tracer alongside(e.g. with Mitsuba or embree),
so that you have a ground truth you can compare your implementation with.

or if you are implementing a shadow map filtering technique, you should
certainly compare your technique with PCF filtering.

* some papers are very mathematical and abstract, and it can be hard to figure out
exactly how they should be translated to code. Some small tips when
translating math to code:

* An integral is just a big sum, in most cases.
* set notation is oftem just used as a fancy way of showing arrays in a paper.

* minimization problems often occur, and the way you often solve them, is by finding the
point at which the gradient is zero

* PDEs can be converted to code with finite difference schemes, e.g. central differences

* big matrices are NOT scary. they are often just used to combine many small simple equations,
into one big equation. that is, they are just a colletion of many small pieces of information.

* NEVER EVER WRITE YOUR OWN LINEAR SOLVER(for production purposes). use Eigen instead.

* simplify, simplify, simplify. consider how the math formulas would look like,
if the input mesh just consists of a single triangle. walk through the math formulas
for such a single triangle mesh. this often makes it much easier to understand
the math formulas

* examine the two-dimensional, or even one-dimensional case, before even considering the 3D case.

if you still are having trouble understanding the paper, some more tips:

* read the papers in the reference list. they might explain some concepts in an easier way
* people often implement siggraph papers in their master's thesis, and provide many valuable implementation details in their thesis. Try to find such thesis!

* some papers are, frankly speaking, poorly written, and therefore hard to understand. try mailing the authors for clarifications!
* try asking your colleagues, or experts on twitter(like me) for help

Now, some general advice for optimizing your implementations, since this is also
an important part of implementing a paper:

* learn how to use performance profiling tools, such as nvidia nsight.
these tools how you to quickly locate hotspots in your code.

* read this article:
devblogs.nvidia.com/the-peak-perfo…

* use version control, so that you can easily locate changes that caused performance
degradations.

alright! that was all for now. I'll add more, if I come up with it.