Question about the limits

[Gamepro5]

In order for the simulation to be accurate, dynamic objects should be in the order of 0.1 to 10 meters long and have speeds in the order of 0 to 500 meters per second. Static object should be in the order of 0.1 to 2000 meters long.

Is this limitation only because double precision isn't supported yet? I feel like the speed limit might be a limit games run into more often than the others.

[mihe]

I can't speak to the precision/accuracy aspect of the speed limits (maybe you can chime in @jrouwe), but I had it explained to me that the speed limits were mostly "a last resort to prevent the system from exploding in case something keeps adding energy to the system, so you probably don't want to set it much higher than the current default."

I'm assuming you're thinking of projectiles needing to move that quickly? I'm mostly used to seeing such things to be implemented as ray/shape casts in the few games I've worked on. I'm not sure how much value you'd get out of actually simulating something moving that quickly.

Note that you can technically raise these speed limits in the project settings. It's only the slider that's soft-capped at the default limits. You can edit the field itself to whatever you want, with the above mentioned warning in mind.

[Gamepro5]

a last resort to prevent the system from exploding in case something keeps adding energy to the system

lmao, so a terminal velocity was implemented? That's quite funny. I wonder what kind of situation could give something this much velocity. Good to know that it isn't a hard limit. Looking forward for 4.1 btw :)

[thomasluce]

If you're trying to make a shooter game with real bullet physics, for example, modern rifles routinely will shoot a projectile at over 1200 m/s. However, if all you care about is if it impacts or not, a successive series of raycasts from the previous position last frame to current position is more performant and gives just fine results. You probably don't want your physics engine applying massive forces to things that you shoot.

[jrouwe]

If you have an unstable physics construct (e.g. a very complex construct of bodies and constraints), the speed limits prevents the speed from growing unbounded and possibly causing the entire simulation to explode (as the fast moving objects can hit other objects which then also go out of control). Very fast moving objects also cause a lot of stress on the collision detection system, which can slow down the simulation to a crawl. In normal simulations it shouldn't do much.

[thomasluce]

Sorry to resurrect a closed discussion, but I was wondering about the possibility of a double-enabled build for this. I'm working on a space game with real-world scales for a personal learning project, and have everything working okay in godotphysics, but want to try to get ahold of savestates and manual physics stepping for some multiplayer experimentation that I'm doing, and that just seems much easier with Jolt, and according to the godot devs a rollback state isn't really possible right now without greatly changing their area/shape state management code.

[mihe]

I was wondering about the possibility of a double-enabled build for this

There is technically double-precision support already (although I haven't released any binaries for it yet) but it's my understanding that Jolt (unlike Godot Physics) is double-precision "only" when it comes to positions and not velocities/displacements, so if your hope is to have a spaceship moving at lightyears per second you'll probably run into trouble just from a precision standpoint. But given what was mentioned here already I would guess that other parts of the physics engine break down before that happens.

want to try to get ahold of savestates and manual physics stepping for some multiplayer experimentation that I'm doing, and that just seems much easier with Jolt, and according to the godot devs a rollback state isn't really possible right now without greatly changing their area/shape state management code.

This extension doesn't really do much to alleviate that problem. You still end up using the exact same scene nodes as with Godot Physics. Rollback (and saving/restoring state in general) would require not only changes to this extension, in order for any extension-specific state to actually be saved/restored, but also likely changes to Godot itself in order to reconcile whatever changes that happened to the scene, which the physics implementation (i.e. this extension) has no real control over.