# World space and model space the dummies version [closed]

I'm by no means a 3d programmer but have recently taken it upon myself to build a Voxel based game and I'm having a little trouble understanding some of the concepts around matrices (what with my limited knowledge of mathematics en all).

So here's my situation ... (assume I've declared other stuff but omitted for simplicity)

I have my camera class in to which I have declared the 3 basic matrices (I think something's wrong here for a start)

class Camera
{
public Matrix World { get; set; }
public Matrix View  { get; set; }
public Matrix Proj  { get; set; }
}


Now I have a few other bits like a BaseModel class, a chunk class and a block class that gives me all the core bits i need for a voxel based modelling system ...

abstract class BaseModel
{
public Chunk[] { get; }
}

class Chunk
{
Block[,,] Blocks { get;set; }
}

class Block
{
public Bool IsActive { get;set; }
public int Type { get;set; }
}

class TerrainModel : BaseModel
{
... terrain specific stuff ...
}

class PlayerModel : BaseModel
{
... Player specific stuff ...
}


This is all good and works well.

So i can do something like (obviously i'm not doing this in my draw method):

TerrainModel terrain = new TerrainModel(heightMap);
terrain.Draw();


In my draw Method I have something like ...

if (updated)
{
// Load the vertex data in to the buffer
buffer.SetData(Vertices);
updated = false;
}

// Send the vertex buffer to the device
GameEngine.GraphicsDevice.SetVertexBuffer(buffer);

cubeEffect.World = GameEngine.Camera.World;
cubeEffect.View = GameEngine.Camera.View;
cubeEffect.Projection = GameEngine.Camera.Projection;

cubeEffect.TextureEnabled = true;
cubeEffect.Texture = cubeTexture;

foreach (EffectPass pass in Effect.CurrentTechnique.Passes)
{
pass.Apply();
GameEngine.GraphicsDevice.DrawPrimitives(PrimitiveType.TriangleList, 0, Vertices.Length / 3);
}


Now here's where I get lost: Assuming when I setup my camera I have done this ...

camera.World = Matrix.CreateTranslation(0,0,0);

... from the cameras point of view the world is based on points starting at that location which should be correct I think.

Now assuming I want to render my terrain model at a different location do I create a new world matrix that represents the translation between the terrain model and the world that my game lives in?

This seems like the logically thing to do and everything I read suggests that maybe the "world matrix" is not a single object but represents the translation from model to world rather than that of all world space like I had previously thought.

When I do this ... (assume i'm only rendering this model for now, I know this has other issues)

camera.World = Matrix.CreateTranslation(10,0,10);


... all is good and everything renders the extra 10 pixels on the x and z axis. The bit I can't seem to figure out is how to move only (for example) my player model taking this approach because when I do this ...

Matrix playerWorld = Matrix.CreateTranslation(PlayerModel.Position);

... I would expect a translation from player model space to world space for each of the verts in question however instead the player object seems to disappear going to who knows where (trust me I looked).

The odd thing being that my camera class is a Third Person Camera and follows the PlayerModel around, pushing the keys I can move the camera but the playerModel stays still.

Have I missed something fundamental about Matrix calculations?

EDIT:

Ok something very odd ... If I tell all models (via the base class) to generate a World matrix and use that in their rendering it all starts working !! ... how peculiar?

That raises the question ... Is world space something that is considered "relative" to each model in the scene and their location in relation to the camera?

I've solved my problem but matrices still remain a scary mystery to me :)

It looks like your attempting a voxel based terrain game built using cubes. Forgive me if I'm wrong, but if so, you are welcome to look at TechCraft, which I coded a few years ago:

http://techcraft.codeplex.com

The simplest form of single threaded xna/c# based code in that project, that demonstrates procedural terrain is found here:

http://techcraft.codeplex.com/SourceControl/changeset/2acaf7e56694 (set the NewTake project as startup)

Incidentally, the project also includes a voxel terrain that is pregenerated, in the TechCraft project.

I hope it helps in you learning about cube based voxel terrain in XNA. It uses matrices, so the code has examples of how to use them also in what you are attempting. Good luck!

• Thanks Jason, never thought I'd actually meet someone who wrote a successful engine out there (i've seen this code about). I have a server based terrain generator for my code which needs updating to spit out 3d heightmaps instead of the current 2d ones but as far as threading and networking is concerned i'm sorted ... its the front end logic that gets me lol. We live and learn :) ... Are you still working on the code at techcraft?
– War
Mar 18 '13 at 15:23
• I kept working on the engine, but not publicly. Youre welcome to contact me on skype if you need further help. Details in my profile here. Mar 18 '13 at 16:45

In any 3D application there are four main coordinate spaces:

1. Model Space: Also known as "Object Space". This is the coordinate system local to any object in your game. If I had a character, then his model space would not change regardless of where the character was or what direction they're facing. The best way to think about model space is "The character always knows what is three units in front of him"

2. World Space: The world space is the relative location of all objects in the world. When a character moves, his position in world space changes (unlike his position in model space). Usually when you need to deal with physics or other game logic, world space coordinates will be the best way to determine relationships between your objects.

3. View Space: Also known as "Camera Space" or "Eye Space". This is the coordinate system relative to the camera. In this space, the camera is at the position (0, 0, 0), and the direction of the camera is the z-axis of the coordinate system. This is the space in which culling takes place. (For example, we don't need to render anything with a negative Z value, since it would be behind the camera).

4. Screen Space: This is the (X, Y) coordinate system of whatever screen you're displaying your graphics on. Your mouse coordinates, for example, are given in this space.

Now, in computer graphics, the transformation from one space to another is encoded using a matrix. So when rendering your full scene, what developers generally do is store:

• A single matrix for each different object in the scene. This corresponds to that object's transformation from Model space into World space.
• One overall matrix for your view. This corresponds to the transformation from World space to View space. Note that you only need one of these, since it's assumed that everything will be in world space before being transformed into view space.
• Finally, another overall matrix known as the Projection Matrix is saved in order to transform objects from View Space into a space that's ready for mapping into Screen Space. This matrix is usually combined with the View Matrix mentioned above.

Now that we have a good understanding of how matrices work, for your problem, you will need to compute a separate Model Space matrix for each block that you want to render. This is usually done "on-the-fly" from the block's position and orientation. Alternatively, you could specify a single Model Space matrix for the entire terrain, but then each block's vertices would have to be specified relative to each other (in "terrain" space).

• This is effectively what I've done in the game class draw method I call foreach (Model m in Models) { m.Draw(gametime) } my issue was understanding why the matrices weren't doing what I expected. The key problem was understanding the difference between world matrix is definitions ... "represents the world" and "represents a transformation between the model parts and the world". Jason's engine code helped me dig out that subtle difference. This is not something I see very well explained anywhere "world" means everything to the common mind but here it means "translates to" for models.
– War
Mar 18 '13 at 16:17