[Bullet] Bullet Physics bad performance in GridMap

[burstina]

Godot version:
3.2 beta5

OS/device including version:
Windows 10

Issue description:
running this MRP stress test, Bullet is really slow compared to GodotPhysics.
I see bigger FPS drop when application is procedurally filling the gridmap, When the filling cycle ends, FPS turns good.

Steps to reproduce:
run MRP using Bullet and look at top-left label: showing FPS and Gridmap radius
run MRP using GodotPhysics and look at top-left label: showing FPS and Gridmap radius

Minimal reproduction project:
Project: GodotPhysics.zip
gridmap.gd tabless (for editor tab-to-space indentation issues) gridmap.txt

[MightyPrinny]

In my experience performance especially bad on meshes with generated trimesh collision when an object collides with a part of the terrain that isn't flat, not sure if that is related.

[burstina]

In my experience performance especially bad on meshes with generated trimesh collision when an object collides with a part of the terrain that isn't flat, not sure if that is related.

I also tried to use generated convex collision and performances were also bad

[lawnjelly]

When I tried to run your project (in a relatively recent 3.2 master) I got 'Parser Error: Mixed tabs and spaces in indentation'.

[burstina]

When I tried to run your project (in a relatively recent 3.2 master) I got 'Parser Error: Mixed tabs and spaces in indentation'.

I use these indenting settings and it run fine:

[Calinou]

@burstina Script parsing doesn't depend on your editor settings, but you do need to convert indentation when saving to fix non-compliant scripts.

[burstina]

@burstina Script parsing doesn't depend on your editor settings, but you do need to convert indentation when saving to fix non-compliant scripts.

I unferstand that, but in editor the script has spaces only, no tabs at all, I don't know the reason you get tabs.

[lawnjelly]

@burstina Script parsing doesn't depend on your editor settings, but you do need to convert indentation when saving to fix non-compliant scripts.

I unferstand that, but in editor the script has spaces only, no tabs at all, I don't know the reason you get tabs.

You are absolutely right burstina, I just reunzipped the project and opened in a different text editor and there are only spaces. My Godot is set to use tabs (tabs, 4, auto indent, convert indent on save, draw tabs, NOT draw spaces) and it seems to mess up auto converting when running the project. I'll open an issue for this as it seems to be a bug. (Sorry didn't mean to derail this issue)

Edit-> Ah got it I think, your spaces are not in multiples of 4.. e.g.

       for i in range(0,MeshArray.size()): (7 spaces)
           if (randi() % (i+1)) == 0: (11 spaces)
              GM.set_cell_item(tt_x,tt_y + i,tt_z,i) (14 spaces)

[lawnjelly]

Finally got it to run by ensuring my IDE was in space indentation mode before loading the project! 😄

Now to the issue, I can confirm I had the same behaviour on mine, Bullet was slower adding physics objects.

However, I would expect this. This is because physics engines typically have different aspects like space partitioning schemes (and different efficiencies with different types of objects). There can be a trade off between the speed of adding objects, and the speed of doing physics queries at runtime. And of course some methods are simply more efficient than others.

For instance having no space partitioning is really quick to add, but can be really slow at runtime with lots of objects.

Also there can be different costs to instantiating objects, sometimes pre-creating a pool can be a good idea.

I have just done a profile with valgrind, here is the result:

Note I haven't examined in detail what you are doing, only the comparison between Bullet and Godot physics. You may for example not be doing things in the most efficient manner, in terms of physics object types, or you may be better off creating one physics object to represent the whole terrain etc. Also, caveat, I've never used or examined gridmap myself, but it might be worth someone who does know the internals confirming it isn't doing something performance sapping like re-adding everything to the physics everytime something is added to the gripmap, instead of just the changes.

[burstina]

I just edited mail message to attach "GridMap.txt": people with indentation issues can download this txt , rename to Gridmap.gd and replace old Gridmap.gd.

[codespren]

Can confirm that this issue still exists in 3.2.1.

In my case I have created a large world from multiple Gridmaps with static colliders. I load gridmaps dynamically so only gridmaps close to player are loaded and visible. Everything was working fine in Godot 3.1 but starting from 3.2 the background loading is very slow because of static colliders (without colliders the loading is fast). Gridmap and colliders works fine once loaded. Loading works also fast when using Godot Physics instead of Bullet.

It also seems that it's not possible to do loading from background thread. If I load Gridmaps by calling call_deferred from background thread it's still as slow as before.

[Calinou]

@codespren Can you reproduce this issue in Godot 3.2 alphas/betas/RCs? You can download them here.

[codespren]

@Calinou I tested my personal project with few alphas and betas and had same slowness in all of them, including alpha 0.

I did some more testing but unfortunately have problems to reproduce the difference between 3.1 and 3.2. However, I made a simple test project where gridmaps are loaded from code without threads and at least in that test the loading is very slow but there's no significant difference between 3.1 and 3.2:

Gridmaps: 1
Godot 3.1.1 Mono Stable: 3.30380010604858
Godot 3.2.1 Mono Stable: 4.86759996414185

Gridmaps: 2
Godot 3.1.1 Mono Stable: 9.73939990997314
Godot 3.2.1 Mono Stable: 11.2165002822876

Gridmaps: 3
Godot 3.1.1 Mono Stable: 31.4248008728027
Godot 3.2.1 Mono Stable: 32.7775001525879

Gridmaps: 4
Godot 3.1.1 Mono Stable: 55.4754981994629
Godot 3.2.1 Mono Stable: 56.2607002258301

gridmaptest.zip

[slapin]

This is another clockbait bug, the performance issue is not in physics simulation but during addition of collision shapes, which make it similar to #30027

[Calinou]

Duplicate of #30027 (same cause). See also #28801 (which is unrelated, and occurs with both Bullet and GodotPhysics).