BodyRigid and Contact Callbacks

[taylormorris]

Hello,

 

Setting up a player movement system and having some problems with the ContactCallbacks coming from a BodyRigid. For the system, we are using absolute position changes in Update to move the player with a child node's BodyRigid receiving collision information. What we want to happen is the player stop at the point of contact and re-apply the movement that would be reset/ignored to the player's forward vector (like sliding along a slope)

 

All of that is set up and working as expected currently, but the BodyRigid doesn't detect a contact until after it is already far inside the surface it's colliding against. In the attached example, the player/sphere has moved partly inside the terrain with no contact callback. If the player/sphere continues in the same direction, the contact will trigger and our code to move them outside runs. Why is there no contact until the body is almost halfway inside?

 

I think there is also something funny happening with the execution sequence, but the documentation on setContactCallback is confusing. When exactly does the callback execute, after Flush? And is there any other way to detect a contact inside Flush or even Update? We tried to solve first with getNumContacts, but as other forum posters have found, it's not viable for this purpose because of the collision resolution sequence.

 

Thanks!

[taylormorris]

Continuing to experiment with this. I've created a ball spawner with the same setup to visualize the problem better. Any ideas?

 

 

[unclebob]

Hi there, Taylor!

 

I believe it's not a good idea to set transform to body directly as it's operating with forces and velocities. By setting a direct transform to the body it'll have to use transform and place itself without any collision response, then it'll try to resolve contacts during flush so you'll have jittering (setTransform directly -> sphere moved under the ground -> physics -> collision response -> sphere tried to correct its position). Also, if there were no forces applied to the body it may considered as frozen by physic engine and it'll skip contact resolve.

 

So instead of placing body inside child node just assign body to the root node and call setLinearVelocity instead of setWorldPosition. Another idea is to get rid of body at all and use engine.world.getIntersection to determine the point where your character can go with particular speed.

[taylormorris]

Hi Andrey,

 

We started with a system based on engine.world.getIntersection and had it working (I think you might remember me asking about intersections on water for this same thing), but we are now testing using a sphere collider to check intersections on all sides. We are thinking of trying a new system with multiple getIntersection checks in different directions, but using a sphere collider to get intersection information would be our ideal. 

 

Again, we don't want to use physics at all, just the collision/contact info and nothing else. This data would be incorporated in the next setTransform computation under Update. Flush should just be for getting data.

 

In my second post/picture, the multiple spheres that are ~40% inside the terrain ARE working off of physics and don't have any Update code. These are just sphere primitives with ShapeSphere BodyRigid's of the same size as the primitive but we have the same problem. 

 

I now believe that this could be a problem with the terrain, possibly LOD's? If I import the same height map to a new terrain, this problem does not occur. Do LOD's affect collision meshes?

[unclebob]

Taylor,

 

Terrain will check collisions & intersections with LOD0 so it should work properly. Could you show us your movement code so we'll be able to play with it and understand your problem better?

[taylormorris]

Hm, I don't seem to be able to reproduce this reliably so I think we will probably just abandon our experiments with colliders right now and get back to working on a raycast-based system.

 

When I created a terrain of the same size with the same height map, the colliders worked just fine. It's definitely not the movement code as I re-wrote that today to be as simple as possible (get input, add input*speed*ifps to old position, that's it!) and there was no difference. Furthermore, those spheres in the second picture above are just rigid bodies with no code, pure physics simulation, and they are still sunk into the terrain.

From all of these tests, I can only conclude that there must be some problem with our terrain setup (possibly materials/masks) but it's not worth the investment for us to continue to diagnose this problem.