Jump to content

Low FPS causing colliding objects to slow down more on impact...


photo

Recommended Posts

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

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

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

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

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

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

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

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

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
×
×
  • Create New...