Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Hi there,
There is an issue with role permissions that is being worked on at the moment.
If you are having trouble with access or permissions on regional forums please post here to get access: https://www.boards.ie/discussion/2058365403/you-do-not-have-permission-for-that#latest

Rigid Body Collisions

  • 30-04-2006 12:03am
    #1
    Closed Accounts Posts: 2,653 ✭✭✭


    I'm working on something at the mo and trying to basically come up with a realistic way for two 2D squares to bounce of eachother. I've done it easily enough with circles after a bit of research, but what I've found about doing it with squares has completely lost me.

    Basically I want something like this: http://www.myphysicslab.com/collision.html
    Doesn't have to be perfect, just something that looks right basically. My knowledge of physics is limited to the Leaving Cert and thats a good few years ago so I'm really not sure what I'm doing.

    Basically I want to create a method that takes in two squares as parameters(each square having a set of co-ordinates, a direction its facing, an x velocity and a y velocity) and based on their collision gives their new positions/velocities, would anyone know any links they recommend?


Comments

  • Closed Accounts Posts: 261 ✭✭bishopLEN


    This is just an idea (nice to see someone else up dickyin) anyway

    instead of having what you say (the method)
    Have your system recognise when a collision occurs.
    Have it recognise what squares collide.
    Then have a method for each seperate square involved to calculate new velocity etc.
    I will wait for a reply before i rant on about something completely stupid.


  • Closed Accounts Posts: 2,653 ✭✭✭steviec


    bishopLEN wrote:
    This is just an idea (nice to see someone else up dickyin) anyway

    instead of having what you say (the method)
    Have your system recognise when a collision occurs.
    Have it recognise what squares collide.
    Then have a method for each seperate square involved to calculate new velocity etc.
    I will wait for a reply before i rant on about something completely stupid.


    That would be fine... I can set up those methods easily. Its working out the mathematics of what each squares new velocity will be thats the problem! Something might come to me when I'm a bit more fresh in the morning...


  • Closed Accounts Posts: 261 ✭✭bishopLEN


    You can't quite now, lol .

    So at the moment you have collision detection ?
    You have a velocity associted with a square (lets just say 1 square when it's moving you record a velocity) ?
    Maybe i'm thinking a bit basic here, you get a collision on two sqaures can you just add the velocity together (wait a second I have to get a piece of paper)


  • Closed Accounts Posts: 261 ✭✭bishopLEN


    You need more than just velocity associated to the squares.

    You need momentuem, so then when you take into accout friction on colision and the moenteum you will get the square to bouce.
    My idea before of just adding velocity will cancel out the vectors and all bodies will travel at the same velocity but at different x y co-ords.


  • Closed Accounts Posts: 2,653 ✭✭✭steviec


    Well as of right now I'm using circles, they're a lot easier to deal with. I have collision detection and they bounce correctly. But I need that with squares. Telling if they hit eachother shouldn't be a problem, there's ways of doing that. Knowing what they do after they hit eachother is the tough bit.

    With squares aswell as an x and y velocity I'll need a turning velocity.
    ______
    |       |
    |  -> |   _____
    |____|  |      |
               |  <- |
               |____|
    Goes to
    
             /\
           /    \
           \->/
             \/
               /\
              /<-\
              \   /
               \/
    
    

    Well... something like that.

    Just before the point of impact I can draw them, I know their x velocity, I know their y velocity, I know their size and centre point(and therefore can get the four corners seperately if needs be), I know their mass, I know what direction their facing, I just don't know how to mathematically convert these figures into a new set of results after the collision.

    Edit: the ascii thing turned out wrong but you get the idea...


  • Advertisement
  • Closed Accounts Posts: 261 ✭✭bishopLEN


    Let's say when they collide you do an x y subtraction to see which compass side was hit, the you do a centre to centre measure to see what part of the square hit, youi can use this measurement like this;

    the distant between the centres is shortest when their full edge meet and longest when their corners meet

    I think you could approximate what half edge the square was hit at , so applying the force on the makes the square rotate.
    Just include the veocity calcs from the circles and it may be something.


  • Closed Accounts Posts: 261 ✭✭bishopLEN


    After collision, have a method to manipulate the turning speed that is always called.
    0 for stationary etc. +/-
    Then when you decide on a calculation for the velocity of turn just increase the step size for the corner coords.


  • Registered Users, Registered Users 2 Posts: 1,272 ✭✭✭i_am_dogboy


    If you want the blocks to spin after a collision you're getting into the wonderful world of rotational velocity/acceleration and whatnot, though if you're working in 2d it's not that big a deal. The formulae for the rotational components are the same as the linear components only with the rotational components in there.

    That you need to calculate is the mass moment of inertia(simple in 2d) which is the ability to resist rotational acceleration. When you have that you need to get a vector from the center of the body being hit to the collision point and you need a vector representing the force of the collision. The cross product of these is the torque. Then in your update method, the one that you call each frame, you multiply the moment of inertia by the torque to get the rotational acceleration, differenciate this with respect to time to get the rotational velocity.

    I'd explain all these steps to you but there are much better sources out there, this is a great book to start with if you can find it. But your best bet is to have a look at the articles on gamedev and gamasutra for some simple collision stuff.

    Hope I helped.


  • Registered Users, Registered Users 2 Posts: 4,188 ✭✭✭pH


    The site you linked to has the math for all this, which you'll need to understand if you're writing it from scratch.

    Depending on what language you're using there may be a physics simulator available that already handles this.


  • Closed Accounts Posts: 2,046 ✭✭✭democrates


    Interesting problem, which I've never had to solve.

    Assuming all squares are equal in size and mass which is uniformly distributed throughout, then the intersection of the diagonals is the centre of gravity.

    The scenarios are:
    No initial rotation:
    Squares colliding along the full side, no resultant rotation.
    Squares colliding along a partial side causing rotation.


    With initial rotation:
    May collide with edges flush (it could happen).
    Will mostly collide with the corner of one square striking the edge of the other square.
    And the squares can have different rotational velocity prior to collision.

    At least they don't deform, absorbing energy.

    Simple centre of gravity vector addition isn't going to do it, because the collision points are different distances from the cog and thereby have different leverage. It's all about momentum, and the mass in various triangles within each square. Wait, the rotation. Hmm. Every point in the square has a different vector. Sounds like a job for calculus.

    If it were me I'd start with a point mass hitting a stationary square first, then a spinning square, then a spinning square with a cog vector, and finally two squares.

    Rather than jump to the final solution, break it down into simpler problems and solve each one in turn, no pun etc.

    Edit: Check out how to write a 2d game in java, might be of more help!


  • Advertisement
Advertisement