I was experimenting with an idea I had for terrain level of detail. The concept is to update a copy of the terrain mesh before replacing the current mesh with that updated mesh. But I’m having some collision problems. The replacement of the terrain mesh will sometimes interfere with the players movement, causing it to shoot up high into the air.
I don’t know what could be causing this except I’m guessing that the translation and replacement of the terrain mesh are not executed simultaneously, even though the methods are called on the same logic tic. I would really appreciate some help with this. If this could work as expected, this probably will clear the path to continue with my project.
Thanks.
Attached blend: wait a few seconds for compiling map data, arrows to move and turn the player
My coding isn’t that great so I am not entirely sure what is happening, but perhaps you can add a force to your player preventing him from flying off. I have seen similar results during several of my own project tests and I suspect an undesired physics reaction between the terrain and the player.
More likely, a subtle change in the physics bounds of the terrain may be causing a slight overlap with the bounds of the player, you might need to move the player upwards by a very small amount to head that situation off.
Indeed it sounds like the typical teleporting issue - intersecting objects. In your situation you are not teleporting the character but the terrain.
The Physics engine resolves such conflicts by applying a force that throws the dynamic objects out of the conflicting position. This can easily result in very strong forces and unexpected directions.
I can only suggest to find a way that replacing the terrain does not create intersecting faces between the objects.
Thanks guys, but is this a bug maybe? Because there couldn’t possibly be any change in the collision bounds of the mesh. The coordinates of the vertexes (of the triangle polygons) are exactly the same every time because there’s no calculation after loading. Or is the physics mesh never exactly the same even when it is defined up to the float? Maybe if I could understand how this (imperfect) conversion works I could anticipate.
Because the method I’m using couldn’t cause a subtle change in the physics bounds of the terrain I was thinking that maybe their is a latency of the physics mesh conversion… Anyway, I’ll try to move the player slightly up. But any thoughts are still welcome.
Wait a few seconds until map data is compiled. Then you’ll see exactly the same terrain mesh as the mesh with the Displace Modifier in the outliner. Only the mesh will follow the player to ensure level of detail.
I spent some time with your file and will affirm this to be a small discrepancy with physics.
Keep in mind that bullet doesn’t create the physics data exactly where the mesh vertices are. Rather, it approximates over the mesh.
Since you’re supplying different mesh data each time (even though the space around the player remains unchanged), one can expect slightly different results.
Possible workarounds:
Force the player to hover just above the mesh
Use a separate somewhat low-res physics mesh (you can generate it the same way) that never updates. This also fixes the problem of dynamic objects being far from the player. <- My favorite
Use smaller, high-res physics mesh that only uses data around the player. I’d only do this if you need a high-detail simulation. Like for golf.
I guess the solution will depend on the needs of your game. Good luck!
Thanks for spending some time with it. I’m glad to hear the approximation causes the issue. Not that I like it but, now I have something to work with.
Thanks for those suggestions. I’ve decided to go for a combined approach. I’ll build the physics mesh out of section peaces and only update those that are on the edge of the area that moves with the player. I already have a working model. And maybe I’ll have a look into the vertex shader if this could also supports buffer shadows, because of what I saw before, there’s some issues with that.