T2D tutorial - implementing collision affects movement rate
by Joe Bestor · in Torque Game Builder · 03/02/2005 (9:16 pm) · 10 replies
Anyone else experience this or just me?
Desc: Once implementing Collision for an image (player/enemy,) the image begins slowing down to a crawl after a certain distance of travel. The distance is about the distance from one end of the window to the middle. From there the movement rate continues to decrease.
Steps To Reproduce:
1) implement collision (follow page 19 - 23 of the tutorial)
2) run game
3) move the player ship across the screen (be sure to have enough distance of travel because starting from the middle and moving towards the edge is not enough to see it)
4) observe the rate of movement slows to a crawl
5) close game
6) comment out the following lines ("// Set player's collision info:" section)
$player.setGroup(1);
$player.setLayer(1);
$player.setCollisionActive(true, true);
$player.setCollisionMaterial(standardMaterial);
$player.setCollisionPolyCustom(4,"-1 0 -0.1 -0.6 0.98 0.15 -0.1 0.7");
$player.setCollisionMasks(BIT(2), BIT(2));
$player.setCollisionCallback(true);
7) repeat steps 2 and 3
8) observe the rate of movement remains constant
Thanks!
Desc: Once implementing Collision for an image (player/enemy,) the image begins slowing down to a crawl after a certain distance of travel. The distance is about the distance from one end of the window to the middle. From there the movement rate continues to decrease.
Steps To Reproduce:
1) implement collision (follow page 19 - 23 of the tutorial)
2) run game
3) move the player ship across the screen (be sure to have enough distance of travel because starting from the middle and moving towards the edge is not enough to see it)
4) observe the rate of movement slows to a crawl
5) close game
6) comment out the following lines ("// Set player's collision info:" section)
$player.setGroup(1);
$player.setLayer(1);
$player.setCollisionActive(true, true);
$player.setCollisionMaterial(standardMaterial);
$player.setCollisionPolyCustom(4,"-1 0 -0.1 -0.6 0.98 0.15 -0.1 0.7");
$player.setCollisionMasks(BIT(2), BIT(2));
$player.setCollisionCallback(true);
7) repeat steps 2 and 3
8) observe the rate of movement remains constant
Thanks!
#2
03/02/2005 (10:59 pm)
That would be the physics system in action. Open up your demoDatablocks.cs file in the T2D/client folder and look at the Standard Collision Material settings (not the incorrectly labeled one at the top, the one two down from that). You'll see that the friction is set to 0.6. That setting will cause an object to slow down over time. This is why setting an object's velocity to 10 will show a bigger slowdown than setting it to 20 - friction will kick in faster at slower velocities. Set it to 0 and you'll be all set. Either that or make sure your ship retains a constant linear velocity by using setMinLinearVelocity() (be careful tho - there's a minor bug in that function - see this thread, 12th post down) 
#3
Friction (dynamic friction) only affects the object when it collides e.g. when surfaces touch, it's not air resistance so changing it, assuming you don't collide with anything, won't affect you. What you're seeing is "damping". I believe this is set to "0.1" so you get a 10%/sec damping effect. Setting this to 0 results in continuous movement.
Sorry there's no documentation yet on that, we'll be putting some nice stuff out when things have settled a little. :)
In the meantime, please ask away.
@Drew: "not the incorrectly labeled one at the top" - Are you referring to the immovableMaterial? Why is this incorrectly named? The density is 0 which makes the object immovable by the physics system. You can still position it in the world but applying forces will have no net result.
- Melv.
03/03/2005 (12:28 am)
That's not quite correct, let me explain that a little...Friction (dynamic friction) only affects the object when it collides e.g. when surfaces touch, it's not air resistance so changing it, assuming you don't collide with anything, won't affect you. What you're seeing is "damping". I believe this is set to "0.1" so you get a 10%/sec damping effect. Setting this to 0 results in continuous movement.
Sorry there's no documentation yet on that, we'll be putting some nice stuff out when things have settled a little. :)
In the meantime, please ask away.
@Drew: "not the incorrectly labeled one at the top" - Are you referring to the immovableMaterial? Why is this incorrectly named? The density is 0 which makes the object immovable by the physics system. You can still position it in the world but applying forces will have no net result.
- Melv.
#4
@melv - sorry, me not being completely specific again :) it's the comment block above it, not the name of the datablock itself. In the script file I have, the immovableMaterial datablock is commented as Standard Collision Material, as well as the actual standardMaterial datablock two blocks below it. I just didn't want Joe to immediately think I was wrong when he opened his file, saw Standard Collision Material (at the top) and saw that the friction was set to 0 :P (of course, it turns out I was wrong anyways so... go figure eh? :)
03/03/2005 (12:46 am)
D'oh! So close :P@melv - sorry, me not being completely specific again :) it's the comment block above it, not the name of the datablock itself. In the script file I have, the immovableMaterial datablock is commented as Standard Collision Material, as well as the actual standardMaterial datablock two blocks below it. I just didn't want Joe to immediately think I was wrong when he opened his file, saw Standard Collision Material (at the top) and saw that the friction was set to 0 :P (of course, it turns out I was wrong anyways so... go figure eh? :)
#5
- Melv.
03/03/2005 (2:58 am)
@Drew: Ahh, I see. Cool. I know you just have but don't forget to mention stuff like that. Those are the "bugs" I like fix ... heyhey!- Melv.
#6
Melv, do these characteristics such as dampening have a stop point where the calculations are no longer performed? Taking away 10%/sec (or any percentage) in theory will go on forever and never reach absolute zero.
Lets say an actor is set in motion, never leaves the screen, never removed from the game, and never stopped and restarted. Dampening set to a value greater than zero, the actor will eventually appear to stop moving but the calculations will continue.
Will I need to concern myself with all these calculations when debugging performance issues? For example, to end the dampening calculation I could use an if statement to set the actor velocity to zero once the velocity is below a set point such as 0.1
03/03/2005 (12:32 pm)
That was it. And since that info is in datablocks, I can easily create another datablock with different values to distinguish between the behavior of the actors.Melv, do these characteristics such as dampening have a stop point where the calculations are no longer performed? Taking away 10%/sec (or any percentage) in theory will go on forever and never reach absolute zero.
Lets say an actor is set in motion, never leaves the screen, never removed from the game, and never stopped and restarted. Dampening set to a value greater than zero, the actor will eventually appear to stop moving but the calculations will continue.
Will I need to concern myself with all these calculations when debugging performance issues? For example, to end the dampening calculation I could use an if statement to set the actor velocity to zero once the velocity is below a set point such as 0.1
#7
03/03/2005 (12:46 pm)
TGE doesn't support infinite floating points. So your ship would eventually reach a state of "0" speed due to rounding the floating point number.
#8
To answer you question though; damping will eventually reduce to zero because of float precision but it will take a long time. There's a setting called "setMinLinearVelocity()" which essentially sets the minimum speed an object can have at which point it's speed is set to zero. This is this rest-velocity.
The physics are very efficient and most of the time I'd like to think that you'd be suprised what you can ask T2D to do before it starts to stress your computer. We've got more work to do on it though with stuff like sleep processing and possibly using a higher-order integrator (we currently use a first-order euler integrator) as well as other work related to prediction across the network.
You're not going to be hit because you configure a a couple of dozen objects wrong. The big killers are rendering, particularly particles as they can get crazy pretty quickly and tuning them is very important and then next would be tile-maps with hundreds of objects colliding with hundreds of rigid-body tiles. We'll be adding batch-processing of particles, tile-map caching and plenty of physics refinements.
The debug-stats "fxSceneGraph2D::setDebugOn(BIT(0))" lets you monitor stuff like particle allocations/rendering, object potential/actual renders, collision/contacts, physics iterations and other stuff. To do real debugging though, T2D uses the same realtime, hierarchical C++ profiler that the TGE does and can be extremely useful.
Not trying to push aside your concerns on how to do stuff efficiently, it's just that I've seen all too many forums tumble down the hole of only talking about performance and going speed crazy and nobody actually produces anything. We really want to see people produce games and in the meantime we'll make T2D crazy-fast so that you can keep pushing it harder and harder.
That's the idea anyway. :)
- Melv.
03/03/2005 (12:51 pm)
@Joe: The whole idea of T2D is so that you don't have to worry about it. That's not to say it isn't good to be interested in how it works and if there's easy ways to grab back bits of performance.To answer you question though; damping will eventually reduce to zero because of float precision but it will take a long time. There's a setting called "setMinLinearVelocity()" which essentially sets the minimum speed an object can have at which point it's speed is set to zero. This is this rest-velocity.
The physics are very efficient and most of the time I'd like to think that you'd be suprised what you can ask T2D to do before it starts to stress your computer. We've got more work to do on it though with stuff like sleep processing and possibly using a higher-order integrator (we currently use a first-order euler integrator) as well as other work related to prediction across the network.
You're not going to be hit because you configure a a couple of dozen objects wrong. The big killers are rendering, particularly particles as they can get crazy pretty quickly and tuning them is very important and then next would be tile-maps with hundreds of objects colliding with hundreds of rigid-body tiles. We'll be adding batch-processing of particles, tile-map caching and plenty of physics refinements.
The debug-stats "fxSceneGraph2D::setDebugOn(BIT(0))" lets you monitor stuff like particle allocations/rendering, object potential/actual renders, collision/contacts, physics iterations and other stuff. To do real debugging though, T2D uses the same realtime, hierarchical C++ profiler that the TGE does and can be extremely useful.
Not trying to push aside your concerns on how to do stuff efficiently, it's just that I've seen all too many forums tumble down the hole of only talking about performance and going speed crazy and nobody actually produces anything. We really want to see people produce games and in the meantime we'll make T2D crazy-fast so that you can keep pushing it harder and harder.
That's the idea anyway. :)
- Melv.
#9
@Melv - I'm all for not having to concern myself with performance issues! Thanks again.
03/03/2005 (5:28 pm)
@"LabRat" - Thanks!@Melv - I'm all for not having to concern myself with performance issues! Thanks again.
Torque Owner Joe Bestor
Initially I was using a velocity of 10 for the player ship to notice the decrease in movement rate to a crawl. The decrease is harder to see with higher velocities such as 20.