Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move_and_slide is slower than with Godot Physics #626

Open
mihe opened this issue Oct 1, 2023 · 1 comment · Fixed by #860
Open

move_and_slide is slower than with Godot Physics #626

mihe opened this issue Oct 1, 2023 · 1 comment · Fixed by #860
Labels
performance Something isn't as fast as it probably could be regression Something that used to work but now doesn't severity:minor Small impact on functionality or usability topic:runtime Concerning runtime behavior (or its source code)

Comments

@mihe
Copy link
Contributor

mihe commented Oct 1, 2023

It appears that version 0.7.0 (most likely #559) introduced a performance regression to move_and_slide, causing it to take roughly twice as long as before, leading to it now being slower when compared to Godot Physics.

Here's how to reproduce it:

  1. Download this project: move_and_slide_regression.zip
  2. Download debug symbols (if you're going to profile): godot-jolt_v0.8.0-stable_symbols.zip
  3. Build Godot from source (if you're going to profile)
  4. Run the main scene
  5. Note the average delta displayed on the screen
  6. Switch physics engine to Jolt
  7. Run the main scene again
  8. Note the average delta being higher

When picking out some average-looking physics ticks in Superluminal, the total time spent in move_and_slide in this particular scene is as follows:

Godot Physics (godotengine/godot@58f0cae): 4.74 ms
Godot Jolt (0.6.0-stable): 3.41 ms
Godot Jolt (0.7.0-stable): 5.70 ms
Godot Jolt (0.8.0-stable): 6.11 ms

(Note that these fluctuate quite a bit, so the difference between 0.7.0 and 0.8.0 seems to be within margin of error and probably not the result of further regression.)

When looking at move_and_slide more closely, it appears that Godot Jolt is returning collisions from body_test_motion that causes Godot to believe that some of them are not contacting the floor, causing it to run apply_floor_snap here, which ends up taking as much time as the slide iterations themselves.

@mihe mihe added topic:runtime Concerning runtime behavior (or its source code) severity:minor Small impact on functionality or usability regression Something that used to work but now doesn't performance Something isn't as fast as it probably could be labels Oct 1, 2023
@github-actions github-actions bot added the needs triage Something that needs investigation label Oct 1, 2023
@mihe mihe removed the needs triage Something that needs investigation label Oct 1, 2023
@mihe mihe closed this as completed in #860 May 18, 2024
@mihe
Copy link
Contributor Author

mihe commented May 23, 2024

It seems I was too eager to close this. apply_floor_snap still runs as of #860, albeit not as often.

Since #860 inherently causes planes parallel to the movement vector to be discarded, no collision will be reported when moving along a level surface, which causes is_on_floor to be false during the first part of move_and_slide, thus causing it to run apply_floor_snap in response, which fixes is_on_floor but which does not actually store its collision results as slide collisions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Something isn't as fast as it probably could be regression Something that used to work but now doesn't severity:minor Small impact on functionality or usability topic:runtime Concerning runtime behavior (or its source code)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant