Immovable = No Collisions?
by Aaron Miller · in Torque Game Builder · 02/01/2009 (7:40 pm) · 4 replies
I'm making a little lunar lander test project using t2dShapeVectors and am a bit confused by how collisions are supposed to work.
When my lander contacts a platform I've built it moves it around, so I selected Immovable under the platform's Physics properties. Now the ship falls through the platform.
The docs say "An immovable object will not react to any forces or velocities applied to it." Is this supposed to mean that the object will not transmit collisions to the collision detection system?
If this is the case, I don't understand how you can create ground / platforms that can resist collisions but can't be moved.
Thanks in advance for any help.
When my lander contacts a platform I've built it moves it around, so I selected Immovable under the platform's Physics properties. Now the ship falls through the platform.
The docs say "An immovable object will not react to any forces or velocities applied to it." Is this supposed to mean that the object will not transmit collisions to the collision detection system?
If this is the case, I don't understand how you can create ground / platforms that can resist collisions but can't be moved.
Thanks in advance for any help.
#2
You should still use the send/receive collisions groups/layers as normal to configure how this immovable object affects it environment though.
So, in other words, if your "immovable" object has send collisions checked then it'll do so. If it has received, it'll receive them but not react in a way that'll cause it to move because it's immovable.
If you want your immovable to effectively be for the purpose of static scene geometry than set it's receive collision to on but its send collision to off. In this way, objects can collide with it but not affect it.
If that's not a great explanation then let me know and I'll try explaining it a little better. :)
Melv.
02/02/2009 (8:47 am)
The "Immovable" flag is just a bypass within the engine that ignores any velocities that get applied to it. In this respect, it doesn't matter if a collision response or a direct velocity change in script tries to change the velocity, it'll be ignored.You should still use the send/receive collisions groups/layers as normal to configure how this immovable object affects it environment though.
So, in other words, if your "immovable" object has send collisions checked then it'll do so. If it has received, it'll receive them but not react in a way that'll cause it to move because it's immovable.
If you want your immovable to effectively be for the purpose of static scene geometry than set it's receive collision to on but its send collision to off. In this way, objects can collide with it but not affect it.
If that's not a great explanation then let me know and I'll try explaining it a little better. :)
Melv.
#3
If I don't want an object to move I'd think I didn't want the object to receive a collision. But if I wanted other objects to stop when they hit the object, I'd think I wanted the object to send collisions to other objects, so those other objects would know they need to react.
03/09/2009 (9:46 pm)
So, for an object to not get moved itself, you disable send collision but enable receive collision? That seems backwards.If I don't want an object to move I'd think I didn't want the object to receive a collision. But if I wanted other objects to stop when they hit the object, I'd think I wanted the object to send collisions to other objects, so those other objects would know they need to react.
#4
The concept is that for a collision to cause an object to move, a collision has to occur. I know that sounds obvious but that is all there is. It doesn't matter whether something sent the collision to the object and it received it or if the object sent a collision to another object and that object received it. In either of these cases, a collision occurs and therefore it will move to the next stage which is determining *if* a move (physics) can/will occur.
Because each object in the scene takes it in turn to move, all collisions occur because an object sends a collision. If it collides with another object that is receiving collisions (and meets the group/layer criteria) then the collision occurs.
I then implemented the ability for you to control precisely how a move (physics) is processed should a collision occur.
The send/receive physics flags are just filters. The send physics flag is a way to say "if I send a collision and it works then I will move (collision response) because of it". The receive physics flag is a way to say "if another object sends a collision and I receive it then I will move (collision response) because of it".
The next stage is that the object can select which move (collision response) it should have if it passes the previous two stages. This is for this object only and not the colliding party which has its own response and criteria.
The immovable flag has nothing specifically to do with these rules as they are mostly processed independantly of this flag. What this flag does do is simply suppress movement of the object. It doesn't make the rules any more complex. If you make something immovable then any physics send/receive flags are going to be ignored because it cannot move due to a collision.
Static level geometry is typically immovable and therefore there's no point in it having send collisions on. Instead it'll have receive collisions on so that when a sending object (perhaps the player) sends a collision to it, the player will have a valid collision.
There's a damn good reason to keep the number of send collisions down: Send collisions are the CPU costly component of collision detection because it's the active component e.g. it's seeking out collisions with other objects. Receive collisions are passive because they are only a flag used by objects that are sending collisions e.g. a send collision is only a collision if the object encountered is receiving them. (Obj1)Send + (Obj2)Receive = Collision!
In eventing terms, the send collision is the event and the receive collision is the sink.
I would recommend reading this as I explain this (with pictures) much better here.
Hope this helps,
Melv.
03/10/2009 (2:21 am)
The best thing for you to do is detach the act of send/receiving collisions from the process of moving because in the engine that's what happens.The concept is that for a collision to cause an object to move, a collision has to occur. I know that sounds obvious but that is all there is. It doesn't matter whether something sent the collision to the object and it received it or if the object sent a collision to another object and that object received it. In either of these cases, a collision occurs and therefore it will move to the next stage which is determining *if* a move (physics) can/will occur.
Because each object in the scene takes it in turn to move, all collisions occur because an object sends a collision. If it collides with another object that is receiving collisions (and meets the group/layer criteria) then the collision occurs.
I then implemented the ability for you to control precisely how a move (physics) is processed should a collision occur.
The send/receive physics flags are just filters. The send physics flag is a way to say "if I send a collision and it works then I will move (collision response) because of it". The receive physics flag is a way to say "if another object sends a collision and I receive it then I will move (collision response) because of it".
The next stage is that the object can select which move (collision response) it should have if it passes the previous two stages. This is for this object only and not the colliding party which has its own response and criteria.
The immovable flag has nothing specifically to do with these rules as they are mostly processed independantly of this flag. What this flag does do is simply suppress movement of the object. It doesn't make the rules any more complex. If you make something immovable then any physics send/receive flags are going to be ignored because it cannot move due to a collision.
Static level geometry is typically immovable and therefore there's no point in it having send collisions on. Instead it'll have receive collisions on so that when a sending object (perhaps the player) sends a collision to it, the player will have a valid collision.
There's a damn good reason to keep the number of send collisions down: Send collisions are the CPU costly component of collision detection because it's the active component e.g. it's seeking out collisions with other objects. Receive collisions are passive because they are only a flag used by objects that are sending collisions e.g. a send collision is only a collision if the object encountered is receiving them. (Obj1)Send + (Obj2)Receive = Collision!
In eventing terms, the send collision is the event and the receive collision is the sink.
I would recommend reading this as I explain this (with pictures) much better here.
Hope this helps,
Melv.
Torque Owner Steven Hine