-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Kinematic/Character bodies cause slowdown/crash when colliding with convex collision shapes #48587
Comments
Does it happen with 3.2.3 as well, or just 3.3? |
Note for junior job: Identifying the issue seems to be easier with Godot Physics, since it's a complete freeze (and it's likely to have a similar cause as Bullet). Here's what can help identifying the issue:
|
Note: for the freeze, it's enough for you (the player) to collide with a building, so it can be trivially reproduced. It doesn't appear to cause the slowdown the AI do cause, possibly because the player won't keep trying to drive ahead once crashed or possibly because there's only one of you the player around ;) EDIT: I wish I knew how to compile Godot on Linux, because I have VS Code and could probably help out on one of the afternoons after the day job is done... |
@Zireael07 Thanks for the extra information! About compiling godot: it's not too complicated. You would be very welcome to give it a try :) |
So, whoa, 7000+ vertices in the convex hull for the building tell me some things a) I can't wait for the #48533 and b) I have to replace the convex hull with a box shape ASAP ;) and c) the godot remote tree DOES NOT tell me how many vertices are in autogenerated convex hull because if it did, this whole issue wouldn't have happened as I wouldn't have used convex in the first place and d) I think there's already an issue open about convex hull not simplifying? |
@Zireael07 Good job on finding the issue! In your specific case, since it's a building you can try to just use a concave shape instead, it handles large amounts of vertices much better in both Bullet and Godot Physics. In general, I agree some extra information for this case would be useful. I think a warning on the tree node when using a convex hull with too many vertices could help, and possibly some read-only information in the inspector to see the number of vertices. |
What would be the maximum number of vertices to consider as "reasonable" for a single convex shape? Something like 200? |
The best would be to test with both Bullet and Godot Physics, and maybe make the threshold dependent on the physics engine (at least for 3.x) since Bullet has a better algorithm for this case. Godot Physics could also use some optimization for convex collision, because right now the performance cost probably grows linearly with the number of vertices. |
Bullet definitely has a better algorithm, since all it did was slow down for that extreme collision shape xDDD A drastic optimization of the collision shape (a box shape instead, or for future polygonal base buildings, possibly a hand-specified shape) fixed the issue, no more freezes, no more slowdowns <3 Leaving the issue open because Godot needs to warn/inform users of badly generated (overly complex, something like 200 vertices Calinou suggested or maybe 500 because it's a nice round number) convex shapes and because well, Godot physics shouldn't freeze even in such an extreme case (abort the loop after more than x iterations, maybe?) EDIT to add: No, wait, one more thing - I am almost 100% certain remote scene tree does NOT display yellow triangle warnings, since it took me so many months to finally twig to the fact Plane shape is being deprecated, and since I've forgotten to add a static body and/or a shape resource for a collision shape several times, and all of those (collision shape without shape, collision shape without body, body without shape) produce yellow triangles in editor. (Most of the collisions are generated from script, either via node.create_convex_collision() or by manually assigning collision shape nodes and/or resources) |
It's true editor warnings are not really useful for runtime-generated shapes. It would make sense to also have these warnings in the log when the shapes are created at runtime. |
If it's ok, I'd like to investigate this and see whether I can make collision detection fast with large convex shapes. No promises, but I think there's a lot of room for optimization. It looks to me like the problem is that |
The real problem is godot/servers/physics_3d/godot_collision_solver_3d_sat.cpp Lines 2132 to 2144 in ecc86af
This one loops over every pair of edges. There also are loops over all pairs of vertices and all vertex/edge pairs. Inside each loop it calls |
hmmm the convex object I was using is rather simple, I didn't check exact number of vertices,but I think it only has like few hundred at max, since the model I used to generate convex is just a lowpoly plane model with minimal faces. |
@MagickPanda the model used in this original issue was a lowpoly boxy building, you would think the convex shape would be simple but nope, lots of vertices! |
In this case it is actually just 28 vertices for the convex shape, so this affects even low-poly convex shapes |
Godot version:
Godot 3.3.
OS/device including version:
Linux Manjaro, Intel Kaby Lake
Issue description:
Noticeable slowdown when a kinematic body collides with stuff. I managed to "manage" most of it by a) optimizing the collision shape of the AI and b) reducing the number of "slides" attempted to 1. (I tried to change the physics to move_and_collide() but failed :( I am also looking at kinematic mode rigidbodies as a possible solution - I really like how smooth movement/AI code are with kinematic bodies as opposed to VehicleBody )
This is Bullet physics BTW - if you change to Godot physics and collide with a building, the game freezes, no output in log.
Cars: kinematicbody3d with a box collision shape
Ground: staticbody with a box collision shape
Buildings and some part of the road: convex collision, autogenerated (I will likely try replacing those with simpler shapes next)
Steps to reproduce:
Run the project, drive around. The fastest way to trigger AI crashing into stuff is to start a race (red flag on minimap, red marker on ground) because the AI crash into stuff after crossing finish line (unfinished [pun intended] AI handling xD)
Minimal reproduction project:
Not minimal, because it takes several AI going around and crashing into obstacles for stuff to happen, but:
https://github.com/Zireael07/FreeRoamRoguelikeRacerPrototype
master branch: drops to single digits when an AI or two crash into stuff
develop: drops to 20-ish fps
@Calinou and whoever else told me to make a new issue
The text was updated successfully, but these errors were encountered: