Gridmap

Public docs:

From Reddit

There is plenty of false rumor about GridMap. Here some corrections as I had to deal with the GridMap source code plenty of times in recent months:

GridMap gets a lot of flack and while there are undeniable issues (especially with the GUI), plenty of those issues that GridMap is blamed for by users are actual engine bugs or weird design choices and the grid layout amplifies them so those engine bugs and design flaws become very noticeable for the average user.

Visuals

GridMap is efficient, but it is only efficient if your setup is designed to be efficient.

GridMap updates per octant, which is a unit that maps a world position divided by this otctant size value to the map. This octant forms an update unit that bundles single cells together. If you have a large octant size and very few meshlibrary items GridMap is peak efficient, if you do the opposite it gets worst than using single MeshInstance nodes for each cell.

The GridMap creates a MultiMesh instance for each meshlibrary item that is used in the same octant. This means if you have a high octant value, lets say 100 cells per octant, and you only have 2 different meshlibrary items used inside your octant, you only have two rendering update calls for all those 100 items instead of 100 update calls (and more update stuff) if you use single MeshInstance nodes.

Now if you go with the default 8 cells per octant and use 8 different meshlibrary items mixed in the same octant you have 8 multimeshinstances and your efficiency is mostly gone. If you use an octant size of 1 you are basically using are worse version of a single MeshInstance nodes, cause those at least can be culled individually.

A MultiMesh has plenty of rendering limitations like no internal culling, it is visible or not visible for all instances. Users often expect the regular full range of features that they know from single MeshInstance nodes but this expectation can't be met. If GridMap would use MeshInstance nodes it would be just a swift grid placement tool (Editor already has grid snap) with the worst runtime performance imagineable.

Collision

Again GridMap merges physics bodies per octant. It does so by creating only physics shapes for each cell used in the octant that has a cell baked collision in the meshlibrary item. All those octant shapes are merged under a single physics body for the octant.

The issues that users report the most are wonky movement and collsion around cell edges but this is not a GridMap issue, it is a core bug in the physics engine and noticeable on all collision edges in all projects to some extend. GridMap makes it just very noticeable cause on a flat floor there are so many cell edges.

GridMap currently creates a single navigation region for each used cell that has a meshlibrary item with a baked navigationmesh. This alone is inefficient but when users have a lot of empty cells where the navigationmeshes can not merge by vertex they go through the very expensive edge distance calculation. The horror begins when a user changes one of those cells with baked navigation cause then the entire navigation map needs to update in full resulting into very noticeable lag on larger maps.

There is also a quality problem with these small, square shaped cells that is shared with GridMap, which is that this layout adds artifical vertex corners and edges that should not exist in an optimized navigation map. Hence post-processing like path optimization and corridior funnel do not work well and you often get wonky paths when moving diagonal. GridMap works with the NavigationMesh baking from NavigationMeshInstances / NavigationRegion3D so depending on your setup you can work around this by not using the build-in navigation of the GridMap and bake a far better navigationmesh for the entire GridMap.