As mentioned in a previous thread of mine, I'm currently working on a pinball physics system, and I'm afraid that I've again hit a problem. In this case, I have a situation in which I want an object to rest within the V-shape formed by two other objects. This seems to work well enough when the two cupping objects are stationary, and for some cases in which they move, but for in other cases the cupped object ends up slipping through the object that lies ahead of it (in the direction of movement, that is). This seems to happen when the cupped object is moving at much the same speed as the two cupping objects, and is "rolling down" the one behind it (i.e. in the direction opposite to motion) - it appears as though no collision is detected with the forward object. Illustration of the problem:

  Cupped object   
    |
 \  _  /
  \(_)/  --Cupping objects
   \ /

  \     /  ---> Direction of cup motion
   \  _/   
    \(/) -- Object slips through forward cup side
        
         Object is moving down and to the right, along the rear cup side

I currently suspect (but am not sure) that the problem is related to the additional velocity provided by the cup to the system, and specifically that I'm somehow ending up with a total velocity that results in the cupped object appearing to not pass through the forward cupping object. Unfortunately, I thus far haven't managed to find a flaw in the logic behind the system, or a mistake in the implementation. The system in brief: Overall, all objects that may collide with another are tested for collisions against all other objects with which they may collide. The earliest collision is found, and the entire system (that is, all objects) rolled back to a point just before that point. The calculated response is then applied to that earliest-colliding object, and the system updated forwards again for the remaining time, once again testing for collisions. This is repeated until either there are no collisions, or the amount of time left in the step is too small. In the latter case, the rollback and response is still performed, but the system is not updated forwards, in the hopes of preventing invalid states at the start of the next step. My approach to detecting collisions is to convert the reference frame into one in which one object is at rest, and then use the time elapsed, total velocity and previous positions of the two objects (that is, their positions at the start of the time interval) to generate a set of sweep segments for each point of the non-stationary object. These segments are then tested against the (non-sweep) segments formed by the points of the other object's shape. The operation is then performed in reverse, to catch situations in which a corner of the second object collides with a segment of the first, without any corners of the first passing into the second. In the case of cupping above, since the two cupping objects are being moved under the control of another object, that object's velocity is passed to the collision detection system and used in the calculation of the total velocity. Note that the end-points of the sweep segments are calculated independently of the objects actual end-position, instead being its previous position + total_velocity*time_elapsed. My thought, therefore, is that I'm somehow ending up with a sweep that results in the object appearing to move in a way that does not result in it penetrating the forward cupping object, as it should. Conclusion So... Does anyone have any suggestions, either of some element of the system that I should elaborate on in order to provide the appropriate information, or simply of a potential solution or candidate for the problem? As in the previous thread, since I'm not sure of where the problem lies, I also don't know one which points - if any - to elaborate. My thanks for any help given. ^_^

does it work when the cup is static? If it does, you just need to consider the relative velocity of the two objects (basically, consider the ball velocity as ball.velocity - cup.velocity).

That also applies for the response.

Thank you both. ^_^

Indeed, the cup worked happily when static, and for a number of moving cases, as I recall.

I was attempting to take into account the relative velocity, specifically by finding the relative velocity (obj1.vel - obj2.vel, with an additional velocity (as explained in my first post) also being subtracted where appropriate), and then calculating the displacement produced in the current amount of time. this was then used to determine a final relative position for the first object.

Why this was problematic I'm not sure - it may have been numeric imprecision, a discrepancy in the amount of time provided, or some flaw in my logic, either there or elsewhere.

Thankfully I seem to have made progress, primarily by switching to a different manner of calculating the relative positions, using the current and last positions of the two objects. I also, I think, found some flaws in other elements of my relative position logic. There seem to still be some problems, but they also seem to turn up much more rarely.

I very much apologise for not updating the thread - I had thought it passed over, and so hadn't thought it worth updating its status. Hopefully I'll remember to do so in future. ^^;;

I am grateful for the help, however. ^_^