# Projectile constraints when targeting a circle

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

## Recommended Posts

I'm having a little trouble implementing a projectile effect. The basic form of the problem is that I have a starting point and a circle in 3D, the latter of which is parallel to the ground plane (for simplicity's sake, the ground is the XY-plane). I need to generate a series of random trajectories originating at the start point such that all they all pass through this circle (ideally through the top like a basketball, so that they're moving towards the ground when they intersect the circle). The projectiles all have the same initial speed, and let's assume for now that the circle is close enough for there to be at least one solution for the polar launch angles for each projectile. I'm also only launching the projectiles "up" and away from the ground, so each one always has a positive pitch. The naive approach would be to pick a bunch of random points in the circle, and then reverse solve the kinematics equations for pitch. However that solution is a bit expensive, and I would have to perform the calculations several dozen times per frame depending on how many projectiles were created. Definitely not the solution I'm most happy with (but at the very least I have a fall-back if nothing else works). It then occurred to me that instead of picking random points and calculating the angles, I may be able to calculate constraints for the polar angles using the hairy kinematics equations, but then easily generate random trajectories from those bounds using very simple equations, perhaps just the random number generation itself. However this is where I hit a dead-end. I quickly realized that the angular constraints would be heavily dependent, and that calculating a max/min pitch from a given yaw (or vice versa) would probably involve equations at least as bad as the one I was trying to avoid! Another way of wording the problem would be, imagine a hemisphere in 3D, centered at the origin. There are an infinite number of trajectories emanating from the center of this hemisphere, such that their initial velocities are vectors on the surface. Assuming a global, constant acceleration, they form a 3D shape (I'm tempted to say a paraboloid however I'm not 100% sure). Now imagine a circle at some position, aligned with the hemisphere, completely contained within this volume. In essence, I'm trying to map this circle onto the surface of the hemisphere by taking all the trajectories that pass through the circle and finding the surface formed by all their initial velocities. Not only that, but I then need to find a way of expressing the bounds of this surface so I can easily generate a point inside it. I know that's quite a mouthful, but I would appreciate any insight anyone has into this problem. I'm interested in the "parabolic mapping" approach personally, as long as it isn't too expensive [smile] Lastly, I'm well aware of the non-uniformity issues that arise from generating random polar coordinates, however that's not the issue I'm dealing with at the moment :)

##### Share on other sites
I'm usually not big with math, but how about:

Take four points (a,b,c,d) on the circle, forming a square, with two points (c,d) on the line from start_point to circle_center (thus making the square looking like a diamond from start_point's point of view) and then map those onto the hemisphere. Take e = average(a', b') and then r1 = a' - e (= b' - e), r2 = c' - e and r3 = d' - e. May have to abs() the radii them just to be sure.

That (e and r1,r2,r3) should describe a sort of egg-shaped oval that cuts through the hemisphere which you can then sample a vector from (and normalize it to map it back onto the hemisphere edge). I'm not sure if the circle maps exactly onto such an oval, it's more of a hunch I have, but it might be good enough for your purpose.

Just my two cents.

(The non-uniformity issue might be worse now, though)

##### Share on other sites
Picking a random point in the circle and computing the initial velocity vector so the trajectory passes through that point is faster than you think. The most expensive operation is asin, which a quick test says takes around 53 ns on my computer. I wouldn't make it more complicated if I didn't have to.

EDIT: On second thought, I don't think you even need the asin.

##### Share on other sites
Quote:
 Original post by alvaroPicking a random point in the circle and computing the initial velocity vector so the trajectory passes through that point is faster than you think. The most expensive operation is asin, which a quick test says takes around 53 ns on my computer. I wouldn't make it more complicated if I didn't have to.EDIT: On second thought, I don't think you even need the asin.

You're right, I ended up implementing the "long" way and I was pleasantly surprised to find that a lot of expressions inside the equation repeat themselves, so I could calculate them once and reuse them multiple times. I was also able to avoid the asin/atan, but I still need a vector normalize so that the length of the initial velocity vector matches the assumed speed. It's a small price to pay for simplicity and ease of implementation.

##### Share on other sites
Quote:
 Original post by alvaroPicking a random point in the circle and computing the initial velocity vector so the trajectory passes through that point is faster than you think. The most expensive operation is asin

But that formula assumes the target is at the same height as the starting point. And I'm not so sure that's necessarily the case:

Quote:
 Original post by ZipsterI have a starting point and a circle in 3D, the latter of which is parallel to the ground plane (for simplicity's sake, the ground is the XY-plane).

'Parallel to', not 'located at'.

##### Share on other sites
I was using the equation from Game Programming Gems 2, which is:

(gx2)tan2(θ)/(2v2) - tan(θ)x + (gx2)/(2v2) + y = 0

From there I can use the quadratic equation, which boils down to an atan. It really isn't that bad though.

##### Share on other sites
Hey, is this the same Zipster from half-life modding back in the day?

You could precalculate the inverse kinematics for a polygon approximation of the hoop, which will give you a region of the theta/phi plane that launches into the hoop. The good thing about this is that you only have to calculate the inverse kinematics once. Here is a diagram:

1. 1
Rutin
70
2. 2
3. 3
4. 4
5. 5

• 21
• 10
• 33
• 20
• 9
• ### Forum Statistics

• Total Topics
633430
• Total Posts
3011825
• ### Who's Online (See full list)

There are no registered users currently online

×