NickUdell

The position in the matrix you mention is what move the vertices when you multiply them by the matrix. In the end, you have to move everything into a unit size cube (z-range differ between OpenGL and Direct3D though) centered at the origin. This cube cannot change so you must move the vertices into the cube, not move the cube to around the vertices. This is why documentation says you move the world and not the viewpoint. The two are conceptually identical though so it is a matter of how you look at it.

Now that makes a lot of sense. I always assumed they were different techniques.

Thanks very much.

For pet projects, voxels can make a lot of sense. They allow you to build a world by simply editing a few noise functions and move on, no hastily-made tools that need to be rebuilt a year later, no mucking around in Blender. For the programmers trying to learn how to make a game with the aim of getting a team together once they have the basic skills, this is ideal. They can leverage procedural content generation to provide them with nice-looking (usually) visuals, without their needing to show of their terrible 3d modelling / design skills. it's also inherently and intuitively deformable and requires that the developer pick up some very useful knowledge on compression, multi-threading, GPU computing and optimization. All of these skills transfer to a more mature project with a real team, as well as typically encompassing the standard skill-set required to code a game.

There's also the allure of games like Minecraft and ID's new tech they're toying with. People are seeing voxel tech more and more and it's intuitively linked to their understanding of matter. They figure it's easier to work with, overall than building the shell of a thing.

My first pet-project was a Minecraft-like infinite terrain generator (actually more infinite than minecraft, as minecraft uses a height limit) using 3D perlin and perfect cubes at 1/4 the size of minecraft's cubes. It ran fairly well on my admittedly high-end machine, even with all the fancy shaders I could muster. I theorize that for marching cubes I had more than enough resolution to produce a realistic terrain with enough detail. You see, these days terrain is still fairly low-poly. Due to normal mapping and tessellation you can get away with a fairly low-res voxel base (perhaps 1 voxel per metre). I got bored before messing around with marching cubes, though so I can't be certain on the performance

I've been working on a game made in SlimDX for the last year or so. I've gotta admit, I'm madly in love with the platform. It emulates the C++ native DirectX functionality so well that 9 times out of ten you can flat out use a C++ DX tutorial and immediately port it to equivalent SlimDX in your head. Very useful stuff, that.

I'd recommend SlimDX over XNA if you want immediate access to D3D11, if not then you're probably going to profit from the sheer quantity of resources available for XNA.

A couple of DX11 sites I used while learning (and I'm still learning) SlimDX Direct3D11:

rastertek for D3D11 and HLSL
RB Whitaker which, despite sounding like a purveyor of fine coffees, has some amazing HLSL tutorials
This blog is not as good as rastertek, which I couldn't recommend more (some site formatting issues notwithstanding), but it also helps cover a few things.

Honestly the best idea is to read through the basic tutorials on rastertek, think about what you want to make, think about how you would make it, and then start googling for techniques and ideas available based on the beginner knowledge you picked up from that first read-through.

Hmm I see your point, I'll do a GPU implementation for now then and when it comes to optimization later I'll write up a CPU implementation and test them side by side.