Sign in to follow this  

Bullet / Projectile Motion in 3D Space (Solved It! Thanks)

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey guys, I'm starting a little 3D project and I'm officially lost when it comes to moving objects in 3d space along a trajectory. I want to have a bullet travel in the direction my camera is facing. Can't get it to work, and I've looked all over for information. The best I can come up with is that i need a destination vector from which to subtract my origin vector. However I have no idea how to come up with the destination vector. I thought that simple rotating the projectile to match the camera and then moving it along the z axis would be how to do it, but I can't seem to acomplish this either. Something tells me that isn't how to do it anyway. But really, I'm completely lost. I will appreciate any help I can get. If you would prefer to e-mail the response please do. dockode at gmail dot com [Edited by - CharlieR on February 16, 2008 7:27:31 PM]

Share this post


Link to post
Share on other sites
The bullet is defined in a local co-ordinate frame. E.g. it "points" in the local z direction; its mesh looks so, too, of course. Now, instead of transforming the mesh vertex-by-vertex inside the local frame (what I assume would be the way the OP mentioned as "that isn't how to do it anyway"), the entire frame is transformed. A frame consists of a position and an orientation (scaling isn't needed in this case), and hence could be decribed e.g. by a transformation matrix. However it is represented, one has to alter the parameters of the frame so that it travels along the said trajectory (i.e. the position is forced to a sequence of given locations in space), and its orientation is set to the shooting direction (what normally is done only at the moment of firing as long as one don't want to have a ballistic curve (what is normally neglected for bullets)).

As Vorpy already stated, the orientation can be fetched more or less directly from the camera orientation (as long as the unrotated camera looks into the same local direction into which the bullets points, i.e. the z direction in the eample above; if not, an additional rotation is needed to first point the bullet correctly).

A straight trajectory can be described by a ray equation:
R(k) := R0 + k * v * d, k >= 0
where R0 denotes the start point (e.g. the camera position at the moment of firing), d denotes the direction (e.g. of the camera at the moment of firing), v denotes the speed of the bullet, and k denotes a runtime parameter. Then R(k) is the bullet's position at a given k. Often the velocity vector
v := v * d
is used directly. Looking at the 1st formula above, it is nothing more than a way-time equation.

Now, k isn't continuously given when rendering. Instead, it is the time elapsed since the moment of firing until the current rendering. So one has the need to grep the current time from somewhere (OS dependent, but cross-platform APIs can help here).

Hence, when "firing" the bullet, one has to instantiate a state for the bullet, remembering the current time and setting up the orientation and start position, and resetting k to zero. Whenever the state is to be updated (e.g. once per simulation step), then the difference of the current time and the remembered time gives k, and the formula above computes the current position from it. Together with the rememberd orientation a full transformation is given, allowing the API of choice to render the bullet where needed.


EDIT: Forgotten closing tag added.

[Edited by - haegarr on February 17, 2008 2:36:08 AM]

Share this post


Link to post
Share on other sites
Thank you both for your help, I think I understand what your saying, however I have no idea how to implement it.

I thought I could get the direction of fire by perhaps extracting information from my view matrix and storing in some sort of forwardDirection vector, however then haegarr mentions:

the orientation can be fetched more or less directly from the camera orientation (as long as the unrotated camera looks into the same local direction into which the bullets points, i.e. the z direction in the eample above; if not, an additional rotation is needed to first point the bullet correctly).

And again, I'm lost. I need to make sure I'm doing my translations (displacements) correctly. I'm never sure when it is i'm working in the local coordinate system or when it is that I'm working in world space.

If anyone wants to post code in any api, or C-type (C++, C#, Java, etc.) language i can figure it out.

Share this post


Link to post
Share on other sites
Hooray! I figured it out... sort of. I am sure my implementation is sloppy, it involves some trig and a little elbow grease. It's extremely sloppy. I got the bullet to behave very closely to what I had in mind but now I'm having some other issues along one particular axe. We will leave that for a separate thread though. I want to thank you both for even taking the time to respond to this thread. Especially because it would be a pain to explain something to someone who has little knowledge about this topic to begin with.

Share this post


Link to post
Share on other sites
Quote:
Original post by CharlieR
I thought I could get the direction of fire by perhaps extracting information from my view matrix and storing in some sort of forwardDirection vector, however then haegarr mentions:

the orientation can be fetched more or less directly from the camera orientation (as long as the unrotated camera looks into the same local direction into which the bullets points, i.e. the z direction in the eample above; if not, an additional rotation is needed to first point the bullet correctly).

For the case that it is still of interest: If the view matrix is unrotated, i.e. its rotational sub-matrix is the identity matrix, then the graphics API in use shows you a specific direction of viewing. Let's assume that is global z direction. If your mesh of the bullet is designed so that it points forward into the x direction, and you use the viewing direction for the trajectory, then you'll see not the rear but the side of the bullet moving away from you. That would be obviously wrong looking. To avoid this, you would have to rotate the local frame so that the mesh points forward also in global z direction.

If, on the other hand, the unrotated camera and the (unrotated) mesh both use z as the initial orientation, all is okay w/o any correction. (That's a hint to the model designer ;)) So, my "more or less" was a bit misleading. The viewing direction is useable directly, or else an additional rotation is needed.

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this