At an impasse with Rigid Body & Trimesh Collisions

Valknor

To whom this may concern,

I have spent the past two months developing my first game, using Godot. I was trying to create something similar to Marble it Up. So I worked on getting the ball to roll, then getting a camera that didn't roll with the ball, then getting the ball to roll based on the camera's orientation. Everything was going alright until last week, when I ran into a problem with _integrate_forces(state)

Since then, I've gone down a rabbit hole, trying to find various fixes. I did find a workaround of sorts by switching from Bullet Physics to Godot Physics. Then I added some test meshes, to see how well this worked. This is when I learned about the titled problem, which I cannot find any solution for. There's a lot of issues documenting this problem, this might be the best one I've found: https://github.com/godotengine/godot/issues/50463

I have no idea if there is a workaround. I have tried everything I could think of, including jacking up the Physics Framerate to 240, which does mitigate the issue, but it also makes the game run in slow motion. I chose Godot because I wanted to make my game open source, so people could create derivative works. Is this game salvageable?

Calinou

including jacking up the Physics Framerate to 240, which does mitigate the issue, but it also makes the game run in slow motion.

You could compile a custom build of Godot to increase the maximum number of physics iterations per frame: https://github.com/godotengine/godot-proposals/issues/1893

However, if the game slows down when physics FPS is set to 240, it already means you're rendering less than 30 frames per second – which I wouldn't consider a playable experience by today's standards.

Valknor

That's what I was thinking at first; however the FPS monitor claims it's getting a steady 60FPS. Perhaps the monitor in the debug panel lies?

Calinou

@Valknor said: That's what I was thinking at first; however the FPS monitor claims it's getting a steady 60FPS. Perhaps the monitor in the debug panel lies?

If the image you see on your screen appears smooth, then the monitor isn't lying (it uses the same value as Engine.get_frames_per_second()).

Could you upload a minimal reproduction project somewhere?

Valknor

Here you go. I stripped out the textures and other unneeded assets to minimize file space.

Controls are WASD for movement, space for jump, and you use the mouse to move the camera.

Valknor

Well, this is the strangest thing. I downloaded Godot_v3.5-beta1_x11.64 to test the project with, and the physics slowdown didn't appear. Then I opened the same project in Godot 3.4.2, and the problem still didn't show up. I even loaded a backup of the project that 3.5 never touched. I've tested jump height, responsiveness, and acceleration, everything is checking out now. Maybe I changed some setting. Oh, I should mention that when I downloaded a release candidated for 3.4, a new menu showed up in the stable version of 3.4.

Anyhow, if I use Godot 3.5 it's possible I won't have the physics slowdown anymore. And if the physics speed holds at 240 frames, I might be able to mitigate the collision issue.