# moving player model

This topic is 3350 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi there, This is my first post on these forums so hopefully I posted at the right place. I recently started programming with Managed DirectX and its been fun till I got stuck >_> Alright, so I got 2 meshes rendered on (0,0,0). 1 is supposed to be the floor and the other is the player that I want to move around on the floor. Now I've read somewhere that the best way of doing this is to actually rotate and move the floor. So I've got the camera pointed at (0,0,0) which is the location of the player and the floor. First I draw the floor with:
device.Transform.World = Matrix.RotationY(angle) * Matrix.Translation(position);
floor.DrawSubset(0);

And then the player with:
device.Transform.World = Matrix.Translation(0,0,0);
mesh1.DrawSubset(0);

When I press A or D I increment or decrement the angle and use W and Z to move forward and backwards by incremented or decrementing the position's Z value. The problem is that I want the floor to rotate around the player's position, but it always rotates around the origin (0,0,0). I can move the player around, but it's a pain since the rotation of the floor is all wrong somehow. I'm probably doing lots of things wrong. And I'm not sure where to look for a solution. I would just appreciate a push in the right direction. Thanks in advance! [Edited by - RandomCode on December 21, 2008 8:28:04 AM]

##### Share on other sites
Quote:
 Now I've read somewhere that the best way of doing this is to actually rotate and move the floor.
Not really. Where did you read this?

If you want to move the player, move the player. If the floor does not move, just give it a fixed transform. In other words, if the goal is to move the player around on the floor, you should be modifying the player's transform, not the floor's.

Does that help at all?

##### Share on other sites
I don't remember where I read that, but it made sense to me. Because I want the the camera to follow the player at all times. Moving the camera and the player would mean extra calculations I guess :S

##### Share on other sites
I've read that too, though I don't remember where, but in a way it is correct, and at the same time wrong (and confusing). If I got this wrong then please correct me.

When you are representing your world, player and camera you do that in, lets say, world coordinates. However when you render stuff you change the model/view-matrix to transform and rotate the world. So the screen-camera is static but the virtual-camera is moving.

##### Share on other sites
Quote:
 Because I want the the camera to follow the player at all times. Moving the camera and the player would mean extra calculations I guess :S

What if you have 10 entities? You're going to move all of them with respect to the player so you don't have to calculate the transform with respect to the camera?

I don't know where you got the idea from, but it looks new to me.

Best thing (don't know how complex your requirements are) is to make a quick scene graph implementation, which should make traversal much easier.

##### Share on other sites
Quote:
 Original post by RandomCodeI don't remember where I read that, but it made sense to me. Because I want the the camera to follow the player at all times. Moving the camera and the player would mean extra calculations I guess :S
What extra calculations would that require? Can you give an example?

Assuming a standard pipeline (such as that of OpenGL or DirectX), what gets moved, and how, is a conceptual rather than a practical issue. In the end, the geometry is pushed through a pipeline that consists of, among other things, a series of transforms. The transforms are always of the same number and type (AFAIK, at least) regardless of how you set things up on the client side.

In OpenGL, for example, prior to the projection stage all geometry is processed uniformly by the 'modelview' transform. This transform transforms geometry from its own local space into camera space. Whether you think of the world as moving around the camera or the camera as moving in the world is once again purely conceptual; it has no practical bearing on the performance of your application, or on the visual output.

As such, IMO it's best to manage transforms in the way that makes the most intuitive sense, and is most practical from an implementation standpoint. If as far as your simulation is concerned the player is moving in a world that is static, then move the player and let the world be stationary. If the camera is intended to follow the player, then have the camera follow the player. Assuming you manage your transforms correctly (combine them in the right order, invert the camera transform as appropriate, and so on), everything else should take care of itself.

##### Share on other sites
Thanks for the replies guys ^_^

Well I guess I'll just make the camera follow the player then. Still be cool if I manage to make the floor move and rotate the way I want >_>

I'm just trying to rotate the floor around the player's position. But it always rotates around its own center. Isn't there some magic I can do with cos, sin or tan functions? I've only tried to rotate the floor around the new Z position of the player. I haven't thought about using the X position.

Maybe my approach is all wrong and I just need stop being stubborn and let the floor be static. Though that would mean that I have to keep updating the camera and player position.

And in case you guys wondered, I'm just trying to make a simple 3D game and learn how to use Managed DirectX then move on to unmanaged :P Also using it to make 3D simulations for projects at work.

I'm really kinda stuck on this..lol

##### Share on other sites
Quote:
 Maybe my approach is all wrong and I just need stop being stubborn and let the floor be static. Though that would mean that I have to keep updating the camera and player position.

I have a 3rd person camera implementation that I wrote a while ago. I could dig it up if you're interested and post the code here. It was for a different engine, but the math for the positioning and orientation should be the same.
I did use a scene-graph though.

##### Share on other sites
Sure, if its not too much trouble :P

So I should just stick with a 3rd person camera then?