Elastic collision between RigidShapes (TGE 1.5)
by Jarno Mannelin · in Torque Game Engine · 11/13/2006 (8:31 pm) · 10 replies
Hi
Is there any way to compute this using only native functions available for RigidShape, such as resolveCollision? I haven't really understood functionality of several collision-related functions, so help would be appreciated. Alternatively, if someone has written onCollision suitable for this task, I'd be more than happy to get to see it. Thanks.
Edit: setVelocity is not supposed to work? I can't find a non-empty definition for it.
Is there any way to compute this using only native functions available for RigidShape, such as resolveCollision? I haven't really understood functionality of several collision-related functions, so help would be appreciated. Alternatively, if someone has written onCollision suitable for this task, I'd be more than happy to get to see it. Thanks.
Edit: setVelocity is not supposed to work? I can't find a non-empty definition for it.
About the author
#2
Thank you for your reply, but I'm not sure you quite understood what I was meaning with elastic collisions. For example, when two balls with different masses collide (not head-on), both of them will be given new direction and velocity. Projectile hitting something won't effect on velocity or direction of the other object, thus making it a lot easier to compute.
In RocketBowl, objects (cones and ball) collided elastically with each other, but I've understood that RigidShape won't implement that kind of elastic collision behaviour? Is this correct, or is there a way to make a curling game, for example, with native Torque 1.5, using only scripts for computing collisions' consequences?
11/14/2006 (6:21 am)
HelloThank you for your reply, but I'm not sure you quite understood what I was meaning with elastic collisions. For example, when two balls with different masses collide (not head-on), both of them will be given new direction and velocity. Projectile hitting something won't effect on velocity or direction of the other object, thus making it a lot easier to compute.
In RocketBowl, objects (cones and ball) collided elastically with each other, but I've understood that RigidShape won't implement that kind of elastic collision behaviour? Is this correct, or is there a way to make a curling game, for example, with native Torque 1.5, using only scripts for computing collisions' consequences?
#3
You're right, the type of collision that affects two rigid bodies as they collide was commented out of the codebase, I assume due to its lack of stability. So you get some rather weird effects when two cars collide, for example: the one that just happened to 'do' the colliding behaves like it hit a brick wall, while the other one is utterly unaffected.
You could try giving both colliding bodies an impulse, emanating from their conjugate centre of mass,
11/14/2006 (7:02 am)
Jarno,You're right, the type of collision that affects two rigid bodies as they collide was commented out of the codebase, I assume due to its lack of stability. So you get some rather weird effects when two cars collide, for example: the one that just happened to 'do' the colliding behaves like it hit a brick wall, while the other one is utterly unaffected.
You could try giving both colliding bodies an impulse, emanating from their conjugate centre of mass,
#4
Even then making RigidShapes react upon others colliding into them shouldn't be too hard either.
When a shape collides with something, subtract the velocity of the colliding object with your own. This way a accelerating shape that collides into a static one will make the static one travel in the direction the accelerating shape was travelling, while the accelerating shape will lose alot of it's momentum.
11/14/2006 (7:07 am)
Aye, I misunderstood. Even then making RigidShapes react upon others colliding into them shouldn't be too hard either.
When a shape collides with something, subtract the velocity of the colliding object with your own. This way a accelerating shape that collides into a static one will make the static one travel in the direction the accelerating shape was travelling, while the accelerating shape will lose alot of it's momentum.
#5
Sam: Thank you for corfirmation. I guess I'll abandon idea of elastic object-to-object collisions with Torque.
Stefan: That applies in some situations, but can only be relied upon in simple cases like head-on collision of two balls, effectively making the collision one-dimensional. A free three-dimensional collision of two (often irrelugarly shaped) objects will depend greatly on the way objects hit each other (hardly ever head-on), causing momentum to objects and changing their directions in quite a complex manner.
11/14/2006 (8:05 am)
Hello againSam: Thank you for corfirmation. I guess I'll abandon idea of elastic object-to-object collisions with Torque.
Stefan: That applies in some situations, but can only be relied upon in simple cases like head-on collision of two balls, effectively making the collision one-dimensional. A free three-dimensional collision of two (often irrelugarly shaped) objects will depend greatly on the way objects hit each other (hardly ever head-on), causing momentum to objects and changing their directions in quite a complex manner.
#6
The collision data generated by Torque does include the normal of the surface at which the collision occurs. It should therefore be possible to do what you want. In fact the version of Rigid::resolveCollision that deals with two colliding rigids (i.e. the one that has been commented out) does exactly what you'd want, except for its instability!
11/14/2006 (8:42 am)
Jarno:The collision data generated by Torque does include the normal of the surface at which the collision occurs. It should therefore be possible to do what you want. In fact the version of Rigid::resolveCollision that deals with two colliding rigids (i.e. the one that has been commented out) does exactly what you'd want, except for its instability!
#7
I never said it was the full scope, I leave that up to your implementation. Which again is why I suggested that you took a look at the classes already implementing directional collisions, like projectile does. It takes the normal of the surface hit and recalculates the velocity vector accordingly.
Edit: Are the features Rigid provides essential for your simulation? It is quite heavy and not so stable in combination with features like these, currently.
11/14/2006 (8:59 am)
Jarno:I never said it was the full scope, I leave that up to your implementation. Which again is why I suggested that you took a look at the classes already implementing directional collisions, like projectile does. It takes the normal of the surface hit and recalculates the velocity vector accordingly.
Edit: Are the features Rigid provides essential for your simulation? It is quite heavy and not so stable in combination with features like these, currently.
#8
11/14/2006 (10:30 am)
I'd need elastic collision physics for a bowling / curling -type of game. Speed is not essential as there won't be so many collisions, but instability is very bad as the collisions would be the heart of the game. I guess I need to do some homework to get a good picture of collision-related functions... I just try to avoid changing code as I really don't really know what effects on what. Thank you both for your replies, I guess I'll try some other type of program first to get familiar with TGE.
#9
elastic collision physics is pretty easy.
for player-versus-player collisions for example,
i implemented a squishy bounding cylinder versus the regular bounding boxes
by first detecting that it's a p-vs-p collision, and then branching the collision tests.
i left player-vs-environment alone.
you could prolly do something similar for ball-vs-ball.
edit but it's also true the TGE collision code is .. mysterious.
11/14/2006 (11:45 am)
If your objects can be approximated by spheres or axis-aligned cylinders,elastic collision physics is pretty easy.
for player-versus-player collisions for example,
i implemented a squishy bounding cylinder versus the regular bounding boxes
by first detecting that it's a p-vs-p collision, and then branching the collision tests.
i left player-vs-environment alone.
you could prolly do something similar for ball-vs-ball.
edit but it's also true the TGE collision code is .. mysterious.
#10
I did something similiar as Orion and implemented bouncing objects. It's not really hard at all, and there's alot of code in the engine already which you can cut out and use. I purchased the TankPack to get a better picture on how they did bouncing, and it got me in the right direction.
Hope it works out for you.
11/14/2006 (12:49 pm)
For rolling objects I guess Rigid is a must.I did something similiar as Orion and implemented bouncing objects. It's not really hard at all, and there's alot of code in the engine already which you can cut out and use. I purchased the TankPack to get a better picture on how they did bouncing, and it got me in the right direction.
Hope it works out for you.
Torque Owner Stefan Lundmark
Elastic collisions are easy. Look at the projectile class and how it handles bouncing objects.