iT2D 1.4 Beta 2 - Objects Moving On Path Inconsistent re: UsesPhysics
by Edward F. Maurina III · in iTorque 2D · 05/18/2010 (10:33 pm) · 6 replies
Build: 1.4 Beta 2 (exists in 1.3 also)
Platform: Windows Vista 64-bit, iPhone Simulator, and iPod
Target: Stand Alone (iTorque2DGame.exe) and On Device
Issues: In order to move, objects on paths require 'UsesPhysics = 1' if the path type is linear, but do not require this flag at all for bezier and catmul.
Steps to Repeat:
1. Create t2DPath with a few nodes
2. Set 'Path Type' to Linear
3. Create and Attach any Object.
4. Run. Notice that the object does not move.
5. Stop game.
6. Change 'Path Type' to Bezier (or Catmul).
7. Run. Notice that object now moves.
Suggested Fix:
This occurs because t2dPath::linear() calls setLinearVelocity() to move the object and setLinearVelocity() depends on usesPhysics. Meanwhile t2dPath::bezier() and t2dPath::catmull() use calls to setPosition().
I suggest having objects on paths not require UsesPhysics in all instances. Adjusting the t2dPath::linear() method to calculate position and call setPosition() instead of setLinearVelocity() is more consistent, cheaper computationally, and avoids other nuisances for linear paths where users really don't want physics enabled.
Platform: Windows Vista 64-bit, iPhone Simulator, and iPod
Target: Stand Alone (iTorque2DGame.exe) and On Device
Issues: In order to move, objects on paths require 'UsesPhysics = 1' if the path type is linear, but do not require this flag at all for bezier and catmul.
Steps to Repeat:
1. Create t2DPath with a few nodes
2. Set 'Path Type' to Linear
3. Create and Attach any Object.
4. Run. Notice that the object does not move.
5. Stop game.
6. Change 'Path Type' to Bezier (or Catmul).
7. Run. Notice that object now moves.
Suggested Fix:
This occurs because t2dPath::linear() calls setLinearVelocity() to move the object and setLinearVelocity() depends on usesPhysics. Meanwhile t2dPath::bezier() and t2dPath::catmull() use calls to setPosition().
I suggest having objects on paths not require UsesPhysics in all instances. Adjusting the t2dPath::linear() method to calculate position and call setPosition() instead of setLinearVelocity() is more consistent, cheaper computationally, and avoids other nuisances for linear paths where users really don't want physics enabled.
About the author
#2
Does this mean, if I was to e.g. take an object that currently uses physics, but actually can be handled by a path, and I use a bezier or catmull path, will I achieve better performance?
I am thinking that my missiles always travel in a nice straight path and don't use any of the "interesting" physics stuff, perhaps if I switch to paths I might improve frame rates?
Anyone got any thoughts on this?
05/22/2010 (4:57 am)
Edward, very interesting find. Does this mean, if I was to e.g. take an object that currently uses physics, but actually can be handled by a path, and I use a bezier or catmull path, will I achieve better performance?
I am thinking that my missiles always travel in a nice straight path and don't use any of the "interesting" physics stuff, perhaps if I switch to paths I might improve frame rates?
Anyone got any thoughts on this?
#3
05/22/2010 (8:54 am)
Edward, good find and I'll second Marc :)
#4
*** NO DETAILS DIRECTLY RELATED TO FIX ***
Scott,
Take the 'better performance' part of the sighting with a grain of salt.
The catmull and bezier calculations are probably not cheaper than linearVelocity() which is probably used by your missiles.
Assuming this fix is made, moving objects on a linear path (with usesPhysics == 0) is only cheaper in the sense that the moving object doesn't interact with the physics system and all of the checking and calculation code there. The actual (linear path) movement calculations will probably be on the same order (cost wise) as linear velocity calculations.
The main thrust of this sighting/issue was to get pathing options consistent with regards to the physics sub-system usage.
Note: With regards to your missiles, if they have no interaction AT ALL with other objects you might benefit from linear paths and disabling physics (assuming GG makes the above change.)
However, my guess is your missiles implement collision testing which is probably what is costing at least part of your FPS budget.
To help reduce the cost of collision detection try the following:
1. Limit objects that can be collided with to very few groups (for example try putting them all in group 15).
2. Limit objects that can be collided with to their own layer (for example try putting them all in in layer 10)*.
3. Do the same kind of thing for missiles. Ex: Put them in group 14, and layer 9.
4. Now, set the collideable objects to only collide with objects in group 14 and layer 9.
5. Likewise, set the missiles to only collide with objects in group 15 and layer 10.
This has the effect of quickly removing objects from the 'possible collision set' by simply doing two bit-mask compares. See t2dSceneContainer::findPotentialCollisions() in t2dSceneContainer.cc to see what I mean.
* - Be sure this doesn't mess up your rendering-order/visibility.
-Ed
The specific code I'm referencing looks like this:
05/22/2010 (9:23 am)
*** ONLY AN ANSWER and ADVICE TO SCOTT ****** NO DETAILS DIRECTLY RELATED TO FIX ***
Scott,
Take the 'better performance' part of the sighting with a grain of salt.
The catmull and bezier calculations are probably not cheaper than linearVelocity() which is probably used by your missiles.
Assuming this fix is made, moving objects on a linear path (with usesPhysics == 0) is only cheaper in the sense that the moving object doesn't interact with the physics system and all of the checking and calculation code there. The actual (linear path) movement calculations will probably be on the same order (cost wise) as linear velocity calculations.
The main thrust of this sighting/issue was to get pathing options consistent with regards to the physics sub-system usage.
Note: With regards to your missiles, if they have no interaction AT ALL with other objects you might benefit from linear paths and disabling physics (assuming GG makes the above change.)
However, my guess is your missiles implement collision testing which is probably what is costing at least part of your FPS budget.
To help reduce the cost of collision detection try the following:
1. Limit objects that can be collided with to very few groups (for example try putting them all in group 15).
2. Limit objects that can be collided with to their own layer (for example try putting them all in in layer 10)*.
3. Do the same kind of thing for missiles. Ex: Put them in group 14, and layer 9.
4. Now, set the collideable objects to only collide with objects in group 14 and layer 9.
5. Likewise, set the missiles to only collide with objects in group 15 and layer 10.
This has the effect of quickly removing objects from the 'possible collision set' by simply doing two bit-mask compares. See t2dSceneContainer::findPotentialCollisions() in t2dSceneContainer.cc to see what I mean.
* - Be sure this doesn't mess up your rendering-order/visibility.
-Ed
The specific code I'm referencing looks like this:
// Check if there's a potential collision.
if ( pSceneObjectRef->getGraphGroupMask() & srcCollisionGroupMask &&
pSceneObjectRef->getLayerMask() & srcCollisionLayerMask )
#5
I did try a little experiment - I have a fireball sub game and I stuck the fireballs (15 of them) on a catmull path and switched off physics. I would say there was an improvement of about 4-5 FPS on the 2nd gen iPod Touch - didn't really see anything on the 3GS though. Collision detection still seemed to work fine which surprised me as I had switched off the physics.
05/22/2010 (10:46 am)
Thanks Edward. I am using collision groups but didn't go as far with collision layers, so i will give that a go as well.I did try a little experiment - I have a fireball sub game and I stuck the fireballs (15 of them) on a catmull path and switched off physics. I would say there was an improvement of about 4-5 FPS on the 2nd gen iPod Touch - didn't really see anything on the 3GS though. Collision detection still seemed to work fine which surprised me as I had switched off the physics.
#6
07/07/2010 (1:22 pm)
Hey all. Ok, so we just did a second pass on this through QA. Technically, the linear paths do work with usesPhysics turned on. This is not really a bug, as it does work. However, this can still be logged in our tracker as an improvement request. This will not hold up the 1.4 final release, but is something we will look at for another update. 
Torque 3D Owner Marc Dreamora Schaerer
Gayasoft
Nice find Edward