Trojan horse anyone? It's almost as if the PMs in that company are deliberately sabotaging it. Would be awesome to uncover 50 years from now Apple lead such a team into Microsoft to create a cancer

Using up most of your video memory for textures is quite a serious design problem. You have to keep some space for mipmaps, VBOs, shaders, and frame buffers. You might want to sit down and analyze your requirements in more detail and consider scaling back. Set upper limits for yourself like never using more than ½ your video memory for storing textures on any given scene and if you need to exceed that, you should stream data as needed.

Also take a look at texture compression. It won't compress data as much as JPG on disk, but in video memory it will consume up to 8x less space. Reed posted an article about that you can read here. The memory savings are quite huge, so it's worth looking into.

You basically have 3 main categories to focus on.
1. Software design and development
2. Game theories, general algorithms, APIs (DirectX, XNA, OpenGL, OpenAL, whatever)
3. Voxel theories and algorithms

You should be comfortable with the first topic, then the second, and finally the third. If you jump straight into voxel development without fully understanding things like rasterization, polygons, textures, and shaders, then you may waste a lot of time writing a voxel engine that doesn't work the way you intended it. Equally so, if you don't have knowledge of designing software, then you'll find the quality of your code will become poor and a maintenance nightmare.

Where to start? That really depends on how confident you are with the aforementioned topics. If we assume you know enough about writing well designed C# code, then your next step would be to learn XNA (if that's what you want). It's a viable API and Microsoft provides excellent documentation and samples to get you jump started. XNA is essentially a DirectX wrapper, without all the boilerplate code. You will still work with vertex buffer objects (VBO), fragment buffer objects (FBO), texture samplers, shaders (XNA calls them effects), etc. so the experience you gain is transferable. That might be technobabble to you now, but these are things you will pickup on if you want to know a thing or two about game rendering. It might also give you some design experience since XNA is generally well built, albeit inefficient in some areas.

Voxels are perhaps the easiest thing to learn and implement. If you can picture a point cloud in your head, then congrats, you just made a voxel engine in your head Really, that's all there is to it. It's essentially a 3D texture. Width x Length x Height, where a unit of space is called a "voxel". In the 2D world, you would call it a pixel. The tricky part to voxels is how to efficiently store it in memory and then render it. Just a simple 1024^3 voxel space will run you 1 GB of memory. Think about that for a minute, 1024 is NOTHING. It's garbage. You can't store anything of quality in something so tight. So there is a way to compress that so you can get 8x more data. Now 2048^3 voxels can fit within 1024^3 space. This is done by storing voxels as bits rather than bytes. Still garbage in terms of quality, but you're making improvements. Next comes the harder part, streaming data. Working with layers and peeling off only the important parts of the voxel data and storing it into memory. More ideas to contemplate, and data algorithms like spatial partitioning to learn. A bit of a mouthful, but I'm just throwing ideas for you to think about. As far as rendering voxels go, well that's up to you. The Minecraft world just renders them as cubes, like in your screenshot. That's just dead simple. Zero effort. By the time you finish your first XNA tutorial, you'll know how to do this. Other algorithms exist to make voxels much more lush and smooth. Algorithms like Marching Cubes combined with Catmull-Clark subdivision (FYI, Catmull-Clark is partly named after Edwin Catmull, one of the founders of Pixar) and these two produce some really great results. So there's a lot of stuff there, simple cube rendering approach vs more complex smoothing algorithms. Lots of stuff for you to look over and decide what you prefer. The devil is in the details, and that's where you will be spending a chunk of your time.

Blender generally stores all transformations as a matrix internally, so these operations are in fact converting from a matrix to euler, and then back into a matrix again (eww). There are some exceptions, for example when you do keyframe animations you can decide what data format is used. Nevertheless, always fetch the transformation matrices from Blender directly. If you look at Blender's docs for objects, you'll see they have a few matrices for you to use. matrix_basis, matrix_local, matrix_world, etc.

It's a clunky website, but what you want is listed under the data structs located here. If you are familiar with Collada, Blender organizes its data in a similar fashion. The root tree has arrays of stuff (the main library), and then you just work your way inwards. One thing to note is that "objects" are entities in the world that reference something real, like a mesh or a lamp. However, in Blender if you SHIFT-D to make a copy of an object, you are also making a copy of the mesh (or lamp or whatever). Obviously that's not very efficient. You only really need one copy of a mesh, so make sure to use ALT-D instead. This will create a new object, but reference the mesh instead, which will be much more efficient for you to parse and work with.