#### Archived

This topic is now archived and is closed to further replies.

# 3D maths to 2D screen coordinates

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

## Recommended Posts

I want to draw a ball being thrown into the screen (so it''s going away from the camera) under the influence of gravity. I can do the maths if it was a side-on view but it''s not. I''m doing it for a mobile phone so there are no fancy functions I can use. Can anyone help?

##### Share on other sites
Just do exaclty the same maths using 3 coords (x,y,z) instead of just 2 (x,y). Then when you draw the ball to the screen use the x and y coords to find its position and the z coord to scale the size of the ball to give the impression of perspective. Simple as that. Hope this helps

##### Share on other sites
I can''t see how that would work. Maybe I haven''t explained myself properly. Basically, the camera is positioned behind the person throwing the ball. If he was to throw the ball straight, the x position wouldn''t change and the ball would go up the screen. However, the effect of gravity would mean the ball''s y movement would slow down as the ball got closer to the ground (and speed up again after bouncing off the ground). But the person might throw the ball at an angle to the left or right. He may also throw it towards the ground, so there''s that to think about too.

Am I right in thinking that if I was to calculate the trajectory of the ball viewed from the side (easy enough), I could calculate the position viewed from behind by using a rotation matrix?

##### Share on other sites
Sorry I dont think I understood the question properly. You need to do the calculations in world space and then transform the resulting ball position vector into camera space. This is done easiest by instead transfoming the camera to the world origin so it is pointing down the z axis and moving the ball (and any other game objects) accordingly. First subtract the camera position vector from the ball position vector, effectively putting the camera at the origin. Then multiply the balls position vector by the inverse of the camera''s view matrix, effectively pointing the camera down the z axis. The balls x and y position coords will now correspond to screen coords since the world space and camera view space now coinside. Again the balls z position coord can be used as a size scalar to give the impression of perspective. The only other option is to do a further transformation which flattens the view fustrum into a cube. This reduces the size of objects further away and so makes the image perspective correct. However I think this is a bit beyond mobile phone gaming capabilities. Are you sure a mobile can cope with 3D in general. You might be better just fixing the camera to the world origin and forgetting all this transformation stuff.

##### Share on other sites
The phone should be able to do this without much trouble. All there is on screen is an image of the ground in perspective, two static sprites in the distance and the ball. All that is ever going to move is the ball, going from the bottom of the screen to the distance. The camera position is never going to move. It should be pretty simple but I just don't know how to calculate the ball's screen positions. If I don't do any transformations as you suggested at the end, how would I do it?

[edited by - Billy Lee on June 6, 2004 9:44:14 AM]

[edited by - Billy Lee on June 6, 2004 9:44:58 AM]

##### Share on other sites
If the camera is always fixed at the origin and looking down the z axis then I dont see what your problem is. If you set up the balls initial position and velocity vectors correctly (ie pointing down the z axis) then your math should simply output the balls location, from which you can use the x and y coords as screen coords. If the camera is allowed to rotate then you only have to perform the multiplication with the cameras inverse view matrix to get the correct position coords. I think maybe the problem might be with the maths you are using. If you post them I can take a look

##### Share on other sites
I''m using s = u*t + 0.5*a*t*t, where:

s = displacement
u = initial velocity
a = acceleration (I''ve decided to set this to 0 because the ball will be moving so fast for a short distance that it will be negligible)
t = time between frames

So viewed from the side:
y = ball''s initial position on y axis
theta = angle between the point on the floor that the ball will hit and the ball''s initial position on the y axis
l = length of vector from ball''s initial y position to point on floor that the ball will hit = y/sin(theta)

u(h) = initial horizontal velocity = u*cos(theta)
u(v) = initial vertical velocity = u*sin(theta)

At time t,
s(h) = horizontal displacement = u(h)*t + 0.5*a*t*t = u*cos(theta)*t + 0
s(v) = vertical displacement = u(v)*t + 0.5*a*t*t = u*sin(theta)*t + 0

Therefore, if I was purely viewing it from the side, I would add s(h) to the ball''s x position and s(v) to the ball''s y position. That would be simple. But as I''m viewing it from behind, I don''t know what the x and y coordinates of the ball would be. There is no z axis to speak of.

##### Share on other sites
A-level maths mechanics correct? Did the same stuff myself. These equations are basically just pre-solved calculus for specific situations, hence they can only be used for those specific situations. You need to step it up a notch to basic calculus. Don''t panic, I''ll explain the Euler method of numerically solving differential equations, its really simple and should be sufficient for your game. Imagine at time t=0 you have the balls position vector Pos(x,y,z) and velocity vector Vel(x,y,z). As time progresses gravity (Grav(0, -9.81, 0)) will alter the velocity vector and the velocity vector will alter the position vector. Euler method approximates the solution to these differential equations like so:

Vel(t=1) = Vel(t=0) + dt*Grav

then,

Pos(t=1) = Pos(t=0) + dt*Vel(t=1)

where dt is the time that has passed. Simply set dt to the time between frames and run through these equations once per frame. As long as dt doesn''t get too large this should remain stable. If not then simply run through the equations n time per frame with dt/n. Hope this helps

##### Share on other sites
Yeah, A-level maths! I understand your explaination but there''s still the problem of getting it to screen coordinates. There is no z-axis on my game. Should I implement one first?

##### Share on other sites
I''ve just done some research on the internet that to get 2D screen coordinates from a 3D point, you have to divide by the z value. I guess I do need a z-axis then.

1. 1
2. 2
Rutin
19
3. 3
4. 4
5. 5

• 9
• 9
• 9
• 14
• 12
• ### Forum Statistics

• Total Topics
633298
• Total Posts
3011256
• ### Who's Online (See full list)

There are no registered users currently online

×