Your lighting looks off. I don't know if that's a normal or lighting equation issue but something isn't right. This could be why the transitions between LODs is so odd and inconsistent. I personally would address this issue first and foremost.
ETA: It looks like the lower LODs are the problem but I may be wrong as the issue could be more fundamental.
Oh right, yes, your experience sounds more than adequate to your needs. Calculus is a must for a lot of GI work in my experience but it seems as if you have this base covered. Your best bet would be to check out the Rendering Equation and see if you can make heads nor tails out of it. If not, then I would say you will have your work cut out for you as it will come up in various shapes and forms throughout your research. There's lots of reources online to explain this aspect to you but if you are lacking in the mathematical department then I would advise you brush up on this first. That's not to say you can't research GI without such skills but it will be a handicap for you.
Some topics to get you started:
* Global Illumination (obviously!), very broad topic encompassing many techniques * Radiosity * Virtual Point Lights * Spherical Harmonics * Environment Mapping (this resource is great, check out the whole blog, lots of good info here)
GI is not my field but I did tentatively survey some of the literature a few years back so hopefully this will give you some ideas and maybe some more knowledgeable users can fill in the gaps for you.
Do you have institutional access to online journal resources like ACM, IEEE, Wiley etc? The reason I ask is that the general web isn't really too hot for learning this stuff so the best approach (IMO) is to go straight to the horse's mouth and read the academic papers. But! They are often behind a paywall (hence the institutional access). There are ways around this (try and find a copy of the paper on the author's website, emailing the author, etc.) but this is much more long winded than having access to the journal repositories.
My approach to research is to find a paper that is either seminal or an offshoot off of a seminal piece and track down the references, both forwards (papers that cite that work) and backwards (papers cited by that work). Before long you will have a web of papers covering most of the pertinent works.
That's not to say there aren't any fantastic resources online (there are!) but I would not use them as my primary research vessel as they are far and in between in my experience. Places like this website are great for asking questions to clarify key points but (again, IMO) this is an inefficient means of learning about a topic if your research is intended to be broad and comprehensive.
A lot of beginners get stuck in the trap of trying to anticipate each and every one of their engine's needs without the experience of knowing what is actually needed (leading to paralysis by analysis). My take on the article is to not get stuck in hypothetical land but to have a game as the driving force behind your design. This shifts the focus away from some idealized "perfect" engine design and on to the pragmatic perspective of actually getting sh*t done so you can finish a game. The goals and challenges become much more clearly defined, giving you something tangible to shoot for rather than the vague, ungrounded ideals of what a game engine should be.
Calculating TBN for a heightfield is less "involved" than for an arbitrary mesh as the UV coordinates are basically the vertex positioning equally spaced along the X/Z plane. You could calculate the normal from the heightfield using a cross filter a la Frostbite and from this derive your Tangent and BiNormal vectors for your TBN matrix. Will this be faster? Well, that depends on your hardware and requirements but it would be a lot less geometry to be sending to the GPU as the terrain vector field would consist of just two UV components. Just to clarify in case there's any confusion: normal maps do not replace normals, they are used in conjunction with one and other (except in a few simplistic cases).
You can look into using JSON rather than XML as parsing them in C# is a breeze although to be honest it's probably easier (and faster, if file read/write really is a bottleneck) to serialize and deserialize your level data to some custom binary type. How are you going to be constructing your level files? With some custom tool or hand written? I.e. how important is "human readable" to your format needs?
Direct3D and OpenGL are both low level graphics APIs that, in their modern form, are for all intents and purposes intefaces to the underlying 3D hardware. As such, all this stuff of buffers, pipelines, primitives and so of is very much a reflection of the common theory and practice of 3D rasterization, things that is certainly not a Microsoft or DirectX specific way of doing things.
I think a big mistake beginners make is that they choose to dip their toes into 3D graphics with no real grasp of the underlying concepts, a mistake which is further compounded by choosing possibly the lowest level API that you'll ever use for 3D rendering. This of course results in a big "WTF!?" moment when you decide to take a peek at the docs or online tutorials because suddenly you're bombarded with not only API-specific stuff but also universal rendering concepts thrown in for good measure. I know i was certainly left utterly baffled when I first started out, and this was in the days of the (relatively simpler) fixed function pipeline.
I think you need to have a think about where your interests lie: if you want to learn the low level nuts and bolts of how things appear on the screen then be prepared to do a lot of extra curricular research and learning about the mathematics and concepts of 3D rendering in general as learning the API specifics should really just be housekeeping. If you want to get things up and running as painlessly as possible to make games and the like then IMO a higher level API/engine would be a wiser investment in time as you can add the low level stuff to your repertoire at a later date..
OpenGL and DirectX are (essentially) just APIs for interfacing with the GPU. Leaning one or other is no great challenge in principle, it only really becomes difficult and problematic when people dive in with little or no mathematical understanding of the concepts behind the APIs (in my opinion). "Learning" the DirectX/OpenGL APIs certainly does not equip oneself to use it, when working at such a low level you need to have a good handle on the math to do anything useful without it becoming a frustrating teeth pulling exercise.
So would SDL be a waste of time? Well, it depends on what you know and what you want to learn. Using SDL and DirectX/OpenGL are not mutually exclusive, I haven't used it myself (so take what I say with a pinch of salt) but from my understanding SDL is (amongst other things) a quick and simple means of getting a window up and running for rendering on whatever platforms it supports. DirectX/OpenGL alone do not replace frameworks such as SDL as they are only concerned with interfacing with the GPU, not creating windows, playing sounds, handling networking and so on (I'm not a DirectX user myself but I believe earlier versions did come with a framework to handle a lot of the boiler plate stuff like window creation, resource loading etc. but I'm not sure if that's the case with the latest version).
In my opinion, I'd stick with SDL for the time being and focus on getting stuff done rather than fretting about hypotheticals. There's nothing to say you can't learn SDL and then move onto something else in the future, it certainly won't be "wasted" time if your using it to get valuable game-making experience.
What current experience do you have? Developer experience is certainly a plus but games are a radically different from most developing roles (gross generalization, I know). If you're looking to roll your own, make some really basic games first like Pong and Breakout, that sort of thing. Otherwise, you might be more interested in using an off the shelf engine if you're looking to get things done so you can both get stuck in.
I'm not following what your problem is. Do you have the grid already? If so, you say you move the camera, what is the problem? Translating the camera or grid will achieve the same thing albeit in opposite directions. Or is the problem with rendering the grid?