Supreme Commander – Graphics Study

This is mentioned in the linked article but a lot of the rendering work is done in the Level of Detail system that is standard in most game engines now. As the player camera moves further from an object, lower resolution versions of the 3D model replace the default high resolution model. Supcom takes this a step further, and at the furthest zoom levels, switches to a 2D sprite (a single quad with texture applied) for unit meshes.

Other games have implemented this sort of thing now, like Planetary Annihilation, which was created by some of the original SupCom developers (warning: don't buy PA unless it's at a severe discount however as it's buggy, has poor game balance, no good single player campaign and a tiny multiplayer community).

The Kerbal Space Program game's devblog also contains some interesting writeups regarding this kind of thing, like this one:

http://kerbalspace.tumblr.com/post/9056986834/on-quadtrees-a...

Both. You can find existing references for each one of those techniques, and even for the architectural concepts behind an engine. But you have to figure out which techniques are the right choice (you may need to invent some), and how they fit together, for the needs of your particular game / style / style.

Nothing to do with years. Graphics programming is a specialism

It's not that mindblowing, although it does require a chunk of maths. It's only really the shadows that are complicated. And yes, it's a stack of established methods which have been built up over decades. SIGGRAPH is a good place to start, and there are open source 3D engines (including the ID software ones) to refer to.

"Mindblowing" are the demoscene people who fit this (or something more complex with procedural generation) into 64k or 4k binaries.

I finished an MSc course in Games Engineering and we covered 90% of things in this article. For the final project we had demos with pretty much everything covered there + post process shaders + deferred lighting + DX11 tessalation shaders + ambient occlusion.

So yeah, I think you can find very good uni courses which cover those things, but they are not very common - I know I can certainly recommended mine, I got a job in the games industry straight away after it.

Not exactly years of programming. But years of studying computer graphics, as applied to games.

I bet I could show this article to myself back when I started CompSci and be able to comprehend most of it. But I was a Gamedev.Net addict, tried my hand at competitions and tried to write my own 3d engine. At some point, my mathematical knowledge became the bottleneck.

There are a lot of established methods, you can pick a lot by reading SIGGRAPH, but that's too heavy early on. If you are truly interested, you should start by learning how to put simple 3d geometry on screen. Then, when trying to figure out how to make things look better, you'll naturally gravitate to learning what you need.

Nowadays, it is much easier to start, since we have WebGL and all you need is a browser and javascript. On the other hand, shaders are now a mandatory part of the rendering pipeline, so you need to learn those.

When trying to apply these techniques in real games, there's indeed lots of experimentation. And many times game developers come up with novel techniques. See papers by Valve, for instance.

Agreed. It's a shame the sequel was such a step back in every respect.

For me, some 2d games are mindblowing. It is a major pain to have a 2d isometric game with overhangs. I'd rather do it with a 3d engine.

Makes me feel a bit guilty that I play it in the 2D view.

I took linear algebra, performed adequately, and the only time I ever found it useful was when I was trying to get a grip on OpenGL. After hanging around a lot of indie developers I discovered that having knowledge of low level graphics programming is not as useful as say, being artistically capable. A lot of devs rely on content creation engines like Unity so being proficient at low level graphics programming isn't exactly an asset.