chris.brown Posted December 21, 2011 Share Posted December 21, 2011 Hello, On some of our levels, when we fire cannonballs through crates which get removed on contact, the ball slows down considerably when the FPS is low. I was wondering if there was a way to not have low FPS affect the speed of the cannonball when it hits another body or, alternatively, not have collisions with crates alter the speed of the cannonball at all and have it remain at the same velocity it was going prior to the collision. Thanks, Chris Link to comment
ulf.schroeter Posted December 21, 2011 Share Posted December 21, 2011 Don't really understand your actual setup and the cause of the problem, but based on documentation lower rendering frame rate than fixed physics frame rate causes all kinds of troubles. Link to comment
ulf.schroeter Posted December 21, 2011 Share Posted December 21, 2011 Thinking about it an alternative approach might be to remove crates collison flag and use an attached PhysicalTrigger for detection of cannonballs entering crates "collision" volume (for removing them) without actually have the physics engine doing real collision impulse calculation which might alter the cannonballs velocity...but to be honest: just blind guessing Link to comment
ken.mayfield Posted December 22, 2011 Share Posted December 22, 2011 The problem I'm seeing with that approach is that they would no longer collide with the world. Currently they collide with other unbreakable stone objects and static metal objects. Link to comment
frustum Posted December 22, 2011 Share Posted December 22, 2011 Try to remove crates in the following global update function. Just add a crate into the queue in the contact callback. Link to comment
ken.mayfield Posted December 22, 2011 Share Posted December 22, 2011 We'll give that a shot. Our main goal is to have the ball destroy the crates and not be affected by any of the collisions (allowing it to pass directly through and destroying many objects while maintaining its current velocity). We can try to record the current linear velocity of the ball every frame and re-apply it after the crate has been destroyed and/or a collision has been detected. Also, putting the crate in a "removal queue" may also be needed. Link to comment
ulf.schroeter Posted December 22, 2011 Share Posted December 22, 2011 The problem I'm seeing with that approach is that they would no longer collide with the world. Currently they collide with other unbreakable stone objects and static metal objects. Maybe this can be handled with some clever usage of Shape::setExclusionMask(), so crates do not collide with cannonballs (so no slowdown should happen) but still can collide with other object of your world. Link to comment
ken.mayfield Posted December 22, 2011 Share Posted December 22, 2011 Actually, this sounds like a perfect solution. Maybe a combo of the physical triggers and collision masks. This would mean that the crates never actually collide with the ball, but would get destroyed as soon as the ball enters their associated trigger AND letting them interact with the rest of world. I'll try it out and let you know how well it works out. Link to comment
ken.mayfield Posted December 28, 2011 Share Posted December 28, 2011 Seems to be working out very well. Thanks for the help guys. Link to comment
ken.mayfield Posted December 29, 2011 Share Posted December 29, 2011 I take that back. It was working perfectly testing on iPhone 4. iPad 1 has a lower framerate and the cannonball is passing through the triggers without being detected. This raises a couple of questions. If the PhysicalTrigger is on the physics thread, how can the collision detection work with a shape, but not the trigger (we never had the problem before with the ball passing through the crate, only that it had adverse physical side effects)? Does the continuous collision detection not work with physical triggers? If the rendering framerate is lower than the physics framerate, are physics being calculated multiple times per frame? If they are being calcuated multiple times per render frame, I feel there should be no problem. Or are the extra physics ticks being dropped? Are callbacks being lost if they are called by a physics frame that is out of sync with the rendering frame? The reason I ask is because we have a collision callback on the crates. If they are touched by a ball, they should break, without exception. Sometimes during low framerate situations, the crates take a direct hit by the ball and fly away (thus having the collision, but no collision callback). Link to comment
frustum Posted January 1, 2012 Share Posted January 1, 2012 I will find the missing contact callbacks asap. samples/physics/fracture_00 example skips contacts also. Link to comment
alex.dovgodko Posted January 6, 2012 Share Posted January 6, 2012 We have similar problems with contact callbacks (on Windows) - they just don't trigger even with visually normally handled collisions. We thought it was a problem with older engine version that we used but we upgraded to the latest version recently and the problem still appears often enough. Would be very nice to have it fixed. Thanks in advance. Link to comment
frustum Posted January 7, 2012 Share Posted January 7, 2012 We have similar problems with contact callbacks (on Windows) - they just don't trigger even with visually normally handled collisions. We thought it was a problem with older engine version that we used but we upgraded to the latest version recently and the problem still appears often enough. Would be very nice to have it fixed. Thanks in advance. Can you create replication sample for the problem? Link to comment
Recommended Posts