Jump to content
  • Topics

  • Posts

    • We don't decompose the collision vector. We calculate the resulting impulse from the contact normal, and the spin actually comes from calculating the torque given the impact position to the center. Since the shape is (almost) a rectangle, then it's just about calculating the lever effect on a axis - the contact point projected on it.  Velocities are also calculated based on this closest point. I think to apply your idea it would be to add a scaling to the lever effect? But I'm not sure it's always desirable, for example on the choke point wouldn't that create more units facing the wrong direction of movement?
    • @Atrik maybe you consider something already, I haven't delved deep enough into the code. In collisions, you would have radial and perpendicular components, the last one making the body rotate. Is that last one also scaled by relative velocity? I thought only the first one. But even if both are, their scaling could be treated differently, and what I'm saying is that if the perpendicular component were to depend even more strongly on relative velocity, it would rotate static objects blocking the way more easily, while (hopefully) not affecting those marching shoulder to shoulder, which are the problems mentioned. I'm not sure how it would behave if objects collided head on (high relative velocity), but the dependency could be defined in a way that the resulting behaviour is also what is wanted.
    • Wait, but I told you it does for collision, just not for the 'soft' push who are mostly meant to keep units apart more then simulating a collision. So for 'soft' pushs you don't really want to scale it down with velocity. It's not so much about complexity you even tried yourself it's just less then 10 lines of codes, less if we refactor with the one for collision. But why would it help rotation here?
    • I see, it was even more constrained than the case of me pushing that elephant in the open. It all comes down to their resistance to rotate, and how messing with that messes with other things. Seems the only solution is "taking into account the relative velocity" between them, but I guess you didn't want to complicate the code with that.    
×
×
  • Create New...