Geometrian

But if you know C#, C++ should be cake. The C languages are quite similar.

No. C# may borrow some C syntax (just as many other languages also do), but C++ is chock-full of oddities that make it infinitely more difficult than C# (or Java, which is very similar). Not only does it have countless features neither C# nor C possess, C++ has protracted (but useful) initially nonintuitive behavior that is oriented towards expert programmers. Add to that C's low-level memory management, which C++ inherits, and different runtime mechanism, and it's a whole different game.

Mastering the dangerous tools that are C/C++ . . . implies a competency in the general ability to deal with complex systems. . . . a competency also implies a competency with basic computer architecture.

This. Many, including myself, will also add that knowledge of an assembly language is a further demonstration of competence.

But it would help you, overall, to get your feet wet in C++. Try the google channel "programminghelp.org". It's where I learned, and he's quite descriptive.

Would it be worth it to make a simple game with C++ using an engine/library that's more similar to what I might be expected to use at a professional studio?

I'll be honest. Fewer new games are written in C++ than in any other language. This is partly because C++ is less preferred, but more because C++ is a difficult language to program right. A game you write in C++ will likely end up less featureful, more fragile, and less profitable than the same game if written in any scripting language.

That said, the exercise of (re)learning C++ is worthwhile (for all the above reasons), and a simple game is a perfect way to start. If it were me, in addition to writing in C++, I would try to do as much implementation as possible without a library. This is make your task still harder, and likely the end product still worse, but you'll learn much more. If I were hiring, implementing a simple graphics layer around OpenGL is far more respectable than calling callbacks through Ogre. Und so weiter.

What happen when you move the light behind the surface?

Perturbing the light slightly along z fixes the problem

.

Since the light is located on the surface, any small change may cause the light to move between the two "states" (in front or behind the surface).

Yes, but the diffuse should be ~0.0 in either case, and while specular can jump, the only time it should be visible at all is at an extreme glancing angle (0.0, to be specific, in which case it's edge-on and not visible anyway).

The problem recurred in a shader, but I managed to solve it. It was related to the object's tangents for normalmapping (they weren't being passed in). This doesn't explain why the fixed function pipeline was being drawn incorrectly, however.

To clarify, it has already been redesigned to something completely different. I can design it myself thank you much. I'm just thinking this is an interesting problem, and it's the first solution I thought of.

SiCrane's template hack looks neat. If it were virtual inheritance of FBO2D, then one could override the relevant methods of FBO2D if you just needed it to act like multiple objects without actually duplicating the data.

This just ended up happening accidentally; it seemed like undefined/wrong behavior. I was just trying to achieve basic fixed-function lighting.

When N dot L is 0.0, then R, the reflected light direction is the same no matter which way the normal faces. This is then dotted against the viewing ray to produce a specular term. This is raised to the power of the specular coefficient.

The only thing I can think of is that the driver is optimizing the case where N dot L < 0 and not computing any specular at all, causing variation among different vertices because of floating point precision. This is sorta plausible since even at extremely low angles, specular can still be strong. But it still doesn't explain why the variation can change each frame.

I feel like implementing a GPU (or software) raytracer just to solve OIT is a bad idea. GPU raytracers are extremely powerful, but they have drawbacks as you saw. I would have initially recommended trying to composite together a hybrid approach, but at that point it makes more sense just to jump into a full raytracing solution. You saw the performance figures in those papers; that's a big step for flexibility.

The solutions to OIT are classic and well-known, but more importantly by contrast they are simpler and faster. You're right, on-the-fly sorting is prone to problems, especially with cyclic geometry, and it doesn't scale well. I suggest you reexamine the depth peeling algorithms, in particular.

You can do this in two passes, if you're careful, by using MRT. In the first pass, render opaque fragments normally into buffer 0. For semi-transparent fragments, do single-pass depth peeling, packing premultiplied RGB and depth into RGBA floating point render targets (buffers 1 to n). For the second pass, just blend the color buffers 1 to n onto buffer 0.

Exactly how the alpha channel is stored (premultiplied or not) may be the subject of some consternation, but that general idea would definitely work. Note that for single-pass depth peeling, you'll need shader mutexes. Here's, where I made a GLSL fragment program that does single-pass depth peeling.