This is for a pinball game, and the rotating lines are the flippers. It's 2d.

The ball can move very very fast, so I can't simply check for an intersection and respond then. If I translate the rotation of the line into additional motion in the ball, the ball gets really really strange non-linear paths that I have no idea how to work with, and they get worse the higher the rotation of the line is (obviously).I've been trying to figure this out for five days now, and it's slowly driving me insane. Help!

That's going to be difficult to solve exactly. Were I to face the same problem, I reckon I'd detect if the ball is passing through the arc that the flipper can swing through, and then just take timeslices and check for intersection as normal. If you find a collision, you can do a binary search over time to find a more exact solution. Calculate the size of the timeslices taking account of the speed of the ball and the speed of the tip of the flipper so there's no chance you miss the collision.

Alternatively, instead of adding the flipper's motion onto the ball, have you tried adding the ball's motion onto the flipper? You'll avoid having to deal with the curved paths, but you'll still have to worry about the rotation. Something to think about anyway.

Time slicing is not the most attractive option, as this has to run really, really fast, both in the verification code in java, and in actionscript for the actual client.And besides, there's no good way of knowing if the ball will hit after some random timeslice, or if it has done so before. Consider the extreme case of a line spinning 360*2 degrees in a single timestep, crossing a ball twice, ending up in the original position.

Had a bit of a think about this, and you might be able to reduce it down to a one-dimensional problem by looking at the angles.

<mind-dump>Assuming that your ball is moving in a straight line, and your flipper is rotating at a fixed speed ( or at least they can be approximated as such over a single timestep ), and taking everything with the pivot of the flipper as the origin:

Calculate the point on the circumference of the ball that is closest to the flipper at the start and end of the timestep. We'll approximate the likely point of impact on the ball as being linearly interpolated between these points over the course of the timestep. Take the angles of these points so that you have an equation parameterised on time for the angle at which a collision can occur.You also have a parametric equation for the angle of the flipper given the time-> Solve to get the time where one equation equals the other. If there's two or more solutions, as in your crazy-whirly-bonkers pinball pathological example, take the earliest.

I can see some problems arising where the ball's center is moving into or out of the flipper's range, but it might be worth a shot.</mind-dump>

There's some assumptions and approximations in there that you might be comfortable with, but I'm crap at maths so it's the best I could come up with

You could also try asking on the Maths & Physics section on Gamedev. They've got some fairly smart cookies there and you can avoid the flood of dilettantes if you're specific enough in your question and make it clear your looking for an exact mathematical solution.

Isn't this problem reducible to the intersection to two lines- the flipper line and the velocity ray of the ball, emanating from the ball? If you have an intersection of the lines, you will also have a collision if the distance sq between the point of intersection & the ball center will be <= the radius sq of the ball, and the collision normal is easy enough to find.

If we are thinking of the same problem, then the time of collision is (dist_from_description_above / speed_of_ball)*frame_time_slice

You can't have two straight lines (in 2d). It doesn't seem to have any simple projection from 3d into 2d either (ie using line/plane intersection).Possibly 4d, but now it's getting complicated.

Aaanyway, I ended up replacing the flippers with a series of spheres. Moving spheres are no problem, as they don't actually rotate, and since the flippers don't move more than some 5 degrees or something per tick, the minor loss of accuracy from the linear interpolation isn't noticeable.It's not perfect, and it's a huge hack, but I need to finish this project sometime this year.

Imagine we have the path for the ball in this timestep defined by a line, and the paddle as a rotating line. Figuring out where the lines will intersect doesn't give you much information, as in that case you're basicly checking for line vs. capped-cilinder, not a moving sphere, so you'd be able to determine *if* the shapes collide, not when (and in which direction to bounce), as relative to the rotating paddle, the (projected) movement of the sphere is not a line.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Imagine we have the path for the ball in this timestep defined by a line, and the paddle as a rotating line. Figuring out where the lines will intersect doesn't give you much information, as in that case you're basicly checking for line vs. capped-cilinder, not a moving sphere, so you'd be able to determine *if* the shapes collide, not when (and in which direction to bounce), as relative to the rotating paddle, the (projected) movement of the sphere is not a line.

That's if the system is continuous, but what I'm talking about is discrete. After finding the position of the second paddle point, it's just a line. Ok, the paddle is a line. check. Now at an instant in time, the sphere is not moving. The sphere is just an origin point and a velocity. Translate the origin point along the velocity vector by the radius to put the origin at the edge of the sphere. Given the new origin point and the terminal point of the sphere velocity, the sphere trajectory is a line. check. Ok, so now we have two lines in a Cartesian plane. If they intersect, we know that the will collide in the next timestep. We know where, we can find at what angle, and therefore the ricochet vector, and we can translate angular velocity for the paddle into linear velocity and add it to the ricochet.

However, this may all be wrong, as it does seem like this is too simplistic a solution when I write it out.

Wow. You're right, that's phenomenally complex. But, I don't see where the *exact* time matters, only that the simulation is believable (i.e., if a collision occurs within the time step, which is usually pretty small, react). So let's cut out the idea of sub-steps. Let's look at each of the first row of cells as if each is a full time step. Assuming a time step <1/30 sec, I think that would be sufficiently close to "exact". Now it's simply as I said, the intersection of two lines. This method also ignores "contacts" where the paddle is technically within the sphere, but the sphere is moving away from the paddle (assuming you move the sphere line segment to the edge of the sphere. This is similar to what bleb was saying, with some simplification

Hm. Well, a rotating line segment won't really do the trick, because those edges of the flippers are offsetted from the rotating point.

Man... my head hurts.

Well, you can always use multi sampling if the ball gets into that area... and if you find a collision you go back/forward stepsize/=2 until you reach some (abs) threshold distance, at which point you resolve the collision.

Shouldn't be that bad... I think. The speed of the tip of the flipper and the speed of the ball give you the minimum step size (if it's bigger it might warp through).

And then you either step all the way through that area and no collision happens. Or you step a few times and you get a collision... in which case you go back half the step size, then forward or back depending on the penetration depth (stepsize halved again) etc.

As soon as you found a time where the distance is <1px you can stop. Resolve the collision and advance the simulation by the remaining time (if you drop this little bit of remaining time, it will feel slower and less real/solid - it's a very subtle thing, but it does make a bit difference).

Well, for the most part there should be only like a dozen passes at most, which should be even fast enough with action script. (Unless there is multiball it's the only thing happening this frame... so it should be alright, I think.)

I am at work now, so I can't check this and I am not much of a mathematician at all, so bear with me, but shouldn't you be able to calculate the intersection by using the balls velocity ray, an assumed intersection point (projecting a rectangular line l from the velocity ray through the origin of your rotating line) and solving t in

1

t*vb=tan(va*(t-t0))/l

where vb is the balls velocity, va the angle velocity of your rotating line and t0 is the time the rotating line needs from rotating from it's start point to the assumed intersection.

EDIT: @Markus_Persson: I know the ball flies through. That's why you use the lines and not the ball itself. Given oNyx' wikipedia reference, I've been describing an a priori method whereby you see if a collision will occur in the time step, and where it will occur. Then you place the ball at the position of line intersection (not quite of course, since the intersection is the on the edge of the ball) and give it a new velocity which is the mirror of the current velocity around the perpendicular to the paddle line.

steps:

1. (time step begins) calculate line that represents paddle, given current paddle orientation2. fire ball velocity ray, get list of collisions, take the first one3. if it intersects the paddle line (or any line technically, but the paddle line is special) place the ball at the intersection point, set new velocity, add paddle angular velocity to ball linear velocity4. else update ball position by ball velocity 5. (time step ends)

And what do you mean pretending won't work? The entire thing is about pretending!

Interesting topic. Can't say that I have completely understood everything that has been written so far... I assume that you are just trying to detect collision and not necessarily at what exact time between two frame updates, right? I don't think a player will detect a 1/50th of a sec error

If so, couldn't you represent the flipper as one sphere at the pivoting axle, and one smaller sphere at the tip (if you want a rounded end of the flipper) and then two line segments connecting the tangents of the spheres. Calculate a ball movement line segment from balls previous position to balls new position.Then you can just do:an intersection test between the ball and the flipper line segments (in case it currently is colliding)intersections test between ball movement line segment and flipper line segments (in case it is "moving through" the flipper)intersection test between flipper spheres (one at a time) and the ball movement line segment, but add ball radius to the flipper sphere. (in case it hits one of the ends)

You probably have to move flipper, do tests, move ball, do tests, to be sure to not miss any collisions.

You will naturally have to move the ball out of the flipper and then bounce ball and add the speed generated by the flipper. If you don't add the speed generated by the flipper, then you might get multiple collisions with one flipper press, and that would give very weird bouncing as result.

Hmmm really difficult to explain it without writing it on paper But it is a quite straight forward.

Let us know how you solve it in the end, and get the game ready soon. Getting eager to test it now

This is hard without a drawing (so my first post was actually wrong, but it might be the right direction), so recall the previous image of the process:

Let's start with the rightmost figure and assume the angle between the projected ray (in the direction of the balls movement) and paddle is rectangular. You can find the intersection point between the ray and the paddle by using some vector math (I have no book at hand, so...) regarding rectangular aligned vector equations.

Now the ball needs some time to travel (at it's known speed) to this intersection point. Also the paddle needs some time to rotate (at it's known angle speed) to it's position rectangular to the ray. In an ideal situation this times are equal, meaning that the ball hits the paddle while it is rectangular to the balls directional vector (the ray).

Unfortunately this might be the less likely situation, so the other figures come into play. At any given time (exept the ideal above) there is a distance between the ball and the projected intersection. This distance is minimized by the ball moving towards the paddle and the paddle rotating towards the ball. If you take our assumed rectangular intersection as a subsidiary line you can form a rectangular triangle between this line and the paddle. Now you can use the trigonometrical function

1

tan(angle)=o/a (a:adjacent/o:oppositeleg)

You know the angle speed (va) the paddle is rotating, you can use this like

1

tan(va*t)=o/a

Since you need to know the distance the projected intersection point "travels" on the balls ray, you need to calculate the opposite leg o, which is

1

o=tan(va*t)*a

So we have one part of the equation. Remember: a is the distance between the assumed rectangular intersection and the origin.

The other part of the equation is the distance the ball is travelling in a given time, which is easy:

1

d=vb*t (vbisthespeedoftheball)

To determine where the ball and the paddle meet, you have to calculate the distance between the ball and the projected paddle line at time 0 (using vector math); lets call it d0. Now this distance has to be equal to the distance travelled by the intersection point on the paddle and the distance travelled by the ball:

1

d0-(tan(va*t)*a)-vb*t=0

You have to solve this to t, which should be the time, when the ball and the paddle meet. Afterwards you can use t inserted in vb*t to get the accurate intersection point.

Keep in mind, that I may have made errors and that it assumes a paddle of infinite length (you have to test if the intersection point is on the finite paddle afterwards). Also you might need some case differentiation, since tan is not a continious function.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org