
I Am Graphics and So Can You - ingve
https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-and-so-can-you-part-1
======
rf15
Actually disagreeing with the author here: As someone who did a bit of
OpenGL/GLSL in their spare time building a game engine, I think it's not that
arcane. You will have to come across the basic rendering pipeline pretty
quickly if you look around a bit and don't just drone along with the
tutorials, and from then on out it's pretty obvious what you load all those
buffers for and how the shaders work in which order throughout the pipeline.
(that being said, early openGL with separate state machine calls for each
vertex were a little weird, and the current implementation is much closer to
the underlying functionality)

~~~
and0
I started a DirectX (so, HLSL, basically identical from my understanding) and
C++ project about a year ago. I hadn't worked with either, but managed to get
a little window up and running within a weekend. That was mostly thanks to
some templates out on the web.

The reason I think it deserves to be called "arcane" is that, to even reach an
RGB triangle (the shader equivalent of "Hello World"), you have to have dozen
different things working all at once:

\- Writing / compiling the shaders (vertex and pixel/fragment, at least) \-
Loading the shaders \- Describing the vertex data \- Creating vertex data \-
Describing constant buffers \- Creating constant buffers for vertex +
world/view/perspective \- Filling all the buffers with data \- Giving the
right data for view / perspective matrices (the camera, basically) \- Calling
the rendering of a mesh \- Getting the output to draw on the screen \- + a ton
of other drawing descriptions I don't even remember, like raster descriptions

For all of those tasks there is an insane amount of boilerplate that needs to
be written. This is okay in itself, since it's all stuff that's worth tweaking
for various use cases, but it creates a pretty insane barrier to entry. Not
everyone needs to learn all the quirks of setting up vertex buffer
descriptions right up front. I personally wasn't going to read a huge DirectX
bible just to see how to get started.

It's a problem very much deserving of a copy+paste solution, with some clear
instructions on how to tweak for individual needs, but most tutorials (MSDN or
otherwise) concentrated on specific features or were in a series building on
an already opinionated codebase / pipeline. And if any part of it doesn't
work, and you'll be second guessing yourself and asking a ton of questions
with every line of code, you have no real way of knowing what went wrong.

However, once I had a pipeline set up (and then started organizing it in a way
that it managed itself and could host various shader types) I started having a
lot of fun. I'm working on a 3D NES emulator [[http://n3s.io](http://n3s.io)]
and felt super inventive when I found a way to get the models to render using
the NES palette.

~~~
ryandrake
It's interesting: In most areas of software, progress over time means moving
up in the abstractions. A framework or library starts out with the low level
nuts and bolts, requires a lot of boilerplate, large learning curve, harder to
get to "hello world", etc. Then, over time, people add convenience layers,
simplify, abstract away hardware specific bits, etc. and you end up with fewer
lines needed to achieve something that works well.

In the graphics world it's been the other way around. Earlier libraries were
higher level, abstracted away a lot, letting you get to "hello world" very
quickly. In ancient OpenGL 1.x immediate mode, "Hello triangle" is a handful
of lines of code (minus the non-portable window management stuff). As we've
moved to vertex buffers, moved away from the fixed function pipeline, less and
less is abstracted for you and you have to deal with more and more granular
constructs, more and more quirks, and more and more boilerplate. I haven't
even started coding with Vulkan, but from what I know about it, any
application I'd want to move over to it is probably going to quadruple in
terms of line count, complexity, and "things to deal with".

~~~
pandaman
OpenGL is not a general purpose graphics library, it's an API to control the
actual graphics hardware, as such it follows the hardware, not the user
experience. Older GPUs had been very primitive and did not require a lot of
commands to do something. For example, the PS2's GPU, GS, was a kind of GPU
the OpenGL 1.x targeted. It had hardware registers for vertex position, color
and texture coordinate. After every three writes into the position register it
would draw a triangle into the current frame buffer (setup through a couple of
registers with address, dimensions and format). If you enable a texture (a
couple registers), it will draw textured triangles, if not - no big deal. So
the OpenGL's glVertex functions mapped nicely to that hardware.

On a more or less modern GPU you won't find those registers. The GPU reads a
stream of commands instead of polling its registers. And the most primitive
command is DRAW, which means "run the current vertex shader for the given
index range, collect its output, rasterize the primitives made from the output
and run the current pixel shader on the resulting pixels". So in order to draw
anything it's required to have a command stream set up, two shaders set up and
necessary data bound to both shaders. Naturally, there is no place for
glVertex() in this setup.

There are high level libraries, which abstract the hardware but it's not the
purpose of the OpenGL. It's only "abstracting" hardware in the sense that it
works same on different models of GPU but it tries to expose as much of the
hardware as possible in a model-independent manner.

------
Theodores
Outside of the hardcore code required for doing stuff in OpenGL there is more
that can be done in the general realm of graphics for us programmer types to
do. However I find few takers in the programming community once some artistic
ability is needed. My advice for people is to not fear art and design but to
go there with maths and coding skills. In doing so there are rich rewards and
your coding competency has to be so so, not amazing.

A lot of images need preparation and classification, there is a whole world of
fun algorithms for that. If you can handle raw images in code then you can get
that automated. This opens up a whole new world of possibilities that would be
tedious to do in Photoshop style tools. Again with SVG in code editors you can
write code that makes images in a way that is not so easy with Illustrator.
Because you are not constrained to the same possibilities as the classically
trained art guy you can see ways of achieving results that are creative
solutions as seen by the rest of the team. Code therefore can make you
apparently creative. Along the way you can work with the best creative talent
with you becoming an asset rather than a cost on the company ledger.

Given the narrow definition of graphics programming I would urge others to
have a go at 3D in the real world. For instance, 3D for TV might not be what
it was but it is relatively easy to be the 3D guy for a client base of a few
really good producers, to have great fun doing 3D graphics. Entry into that
world is considered hard but isn't if you do have the technical chops. In this
scenario you are gold dust, not one of many but if you go reasonable on the
salary request the job is yours.

At the bottom of the 3D food chain are morally dubious things like fracking,
the opportunity for someone interested in real world application of cool
graphics is a good one with a low bar. There are many other industries where
being able to step out the safe world of tech to embrace a non scientific
discipline is the way ahead in graphics, to cut your own career.

------
atemerev
I can't stand Vulkan for exactly the reason specified: "Vulkan is the
government office telling you, you still don't have all the necessary forms to
proceed." I wonder how anyone can find this description attractive, but
apparently the author does.

If there is a personal hell for me somewhere, this is the definition of it.
Perhaps as a compiler target, it could be usable. But on its own... not a
chance.

~~~
munchbunny
To be fair to Vulkan, it was designed to be used by somebody who knew what
they were doing, under the philosophy that since developers were using all
sorts of hacks to get efficient inner loops in the rendering pipeline anyway,
you might as well make the API explicit about those optimization mechanisms.

In that vein, OpenGL or DirectX is probably a better starting option
specifically because it abstracts more of the sausage-making in a way that is
conceptually cleaner, especially for beginners. It won't take long to get to a
point where you'll appreciate Vulkan, but it's a shallower learning curve that
is still conceptually sound.

~~~
atemerev
Being low-level is fine. However, the hallmark of good API design is to
provide a good ramp-up and sane defaults.

E.g. x86 assembly language is low-level, but I can start learning it quite
easily. Writing "Hello world!" (either in BIOS or with system calls) is easy.
Simple calculations and loops are easy. Assembly is approachable.

On the other hand, Vulkan is as explicit and intimidating as you could imagine
in the worst case, and then some. Two pages of code for drawing a triangle!

~~~
munchbunny
Only two pages? Honestly, that's pretty good. People who haven't done 3d
graphics programming seriously underestimate the number of stages in even a
basic rendering pipeline.

~~~
atemerev
I have successfully rendered a triangle with Vulkan :)

There are also good high-level APIs, like three.js.

What is missing is some middle ground between them.

------
lfowles
Interesting article, I ended up getting the OpenGL SuperBible to take
advantage of yesterday's kindle promotion. I thought about the Vulkan
programming guide, but ended up deciding modern OpenGL would be an easier
starting point. Did anyone else pick up Vulkan as their intro to graphics
programming?

(In a twist of fate, the SuperBible example code only supports OpenGL 4.0+ and
my primary computer is stuck at 3.3)

~~~
malkia
I wanted to learn Vulkan, but as it happened my laptop of choice is Mac, and
there is only a commercial implementation of Vulkan there (or maybe there is
one now that I can use without paying?). It's not the money, it's just the
spending on things just to learn.

~~~
corysama
Vulkan is not a good first-step path to learning graphics. It's maintainers
will tell you to start out by learning OpenGL or DX11.

However, even though its unpopular for many reasons, Metal is a very good
compromise as a starter API. It's design is very close to Vulkan/DX12, but its
complexity is much lower. It can even be said to be less complex than OGL in
the way that memcpy is less complex than glSubBufferData.

~~~
malkia
Thanks, but your message has a bit of an assumption. I'm not graphics pro, but
had my ways through VGA 320x200x256 colors in 0xA0000, then a bit of 3Dfx,
some OpenGL 1.1, and DX3 then quickly DX5, a bit of DreamCast (but very shy),
etc.

No, I'm bit familiar with OpenGL, again not at the level of graphics-pros,
more like overall knowledge, and my DX knowledge goes pretty much to DX8 or
DX9, but instead of learning DX11 or 12, I think Vulkan might be a better
choice.

I've returned my company laptop week ago, as I left it, and now I'm stuck with
my chromebook + crouton, looks like Vulkan is good there (almost).

I certainly don't want to get stuck in Metal.

~~~
corysama
Don't worry about getting stuck with Metal any more than you'd worry that
learning C# will prevent you from learning C++. What you need to learn are the
fundamentals of modern techniques.

I wrote up a recommended path from nothing -> OpenGL -> Vulkan here
[https://www.reddit.com/r/GraphicsProgramming/comments/6hcri4...](https://www.reddit.com/r/GraphicsProgramming/comments/6hcri4/how_to_start_in_2017_need_pro_advice/dixtdt3/)

I honestly haven't worked with Vulkan yet, but I hang out with pros from
different companies who do and they complain about Vulkan a lot. A whole lot.
Part of it is that it is very difficult even for pros to avoid undefined
behavior and timing issues. Another is that the only semi-solid shading
language front-end for SPIR-V is glsl. Lots of people prefer to work in hlsl
and really would like to see Metal's shading language everywhere.

------
dpkonofa
This is frustrating to me as a web developer because I really, really want to
get into graphics programming at some point but the article makes it seem like
it can be really easy if you just stop comparing yourself to others and just
try to improve little by little. The problem is that he casually mentions that
it'll take you 4 months of full-time work to even get to where he is and he
already seems to have more graphics experience than I do. I have a full time
job and a family and other obligations. It would take me 4 years to do this.
It's really _not_ as simple as "stop comparing yourself to others and just
improve little by little". :(

------
sk0g
Despite the weirdly worded title, the actual article is pretty fascinating.
I'm quite interested in graphics programming, and one of these days I'll have
to drop a subject from my SE degree to do a harder graphics subject. One day.

~~~
logfromblammo
The title is likely inspired by the title of a book by Stephen Colbert's _The
Colbert Report_ character, Stephen Colbert: _I Am America, and So Can You_.

------
NotCamelCase
Great article though I also have to disagree with the advice that for a
beginner learning Vulkan could be a good direction, because Vulkan
implementation of anything will require much more code than its OpenGL/D3D11
counterpart which might go wrong and which in turn would cause beginners to
give in, thinking "it's too complicated for me". (That's not to say "use an
engine/framework/X", that'd be my last advice)

~~~
zokier
I think it boils down to "top down" vs "bottom up" schools of learning. One
starts with high-level stuff and then drills downwards on how they are
implemented. Other starts with low-level primitives and builds up more and
more complex stuff. Both are equally valid strategies, and I think it depends
more on the individual which one is more suited.

~~~
gefh
Sometimes you have to start at both ends and hope you meet in the middle.

------
DarkKomunalec
With javascript disabled, the site shows the content for a split second before
hiding it. I don't like the proliferation of such user-hostile pages one bit.

------
Avery3R
Please don't use a sticky footer.

~~~
lgas
I suspect you have little to no hope of changing anyone's behavior by simply
asking them to do something without explaining why.

