bake_navigation_mesh() generates incorrect mesh on mobile

[thirty6down]

Godot version

v4.0.beta10.official [d0398f62f]

System information

Android 10 - SM-N960F

Issue description

I am seeing a significant difference between navmeshes generated on desktop and on an exported android project, to the point where the android ones are unusable.

Steps to reproduce

Run on desktop - and press the "generate navmesh" button. Run on mobile, do the same - see that the navmesh appears to float.

Minimal reproduction project

example.zip

[smix8]

I am seeing a significant difference between navmeshes generated on desktop and on an exported android project

Can you add a comparison screenshot between desktop and what you see on Android? I can't really test anything on Android / Mobile so other users / contributors need to verify this.

The average distance that the navmesh hovers over the source geometry is defined by the cell_height property on the NavigationMesh resource so the navmesh always floats cause the cell_height can't be zero. How does this exactly compare to desktop? There is no branching in the bake code that does anything different between the different OS.

[Zireael07]

I strongly suspect that the navmesh IS the same on both platforms, and that the issue is the GFX side due to lower precision on mobile.

[smix8]

Try testing with higher bake parameter values, e.g. cell_size from 0.25 -> 1.0+ and same with cell_height.

If the problem is reduced or goes away with higher bake parameter values it is a precision problem cause when precision is low and source geometry is overdetailed and complex it can map the source vertices to wrong integer voxelmap layer due to float errors when the cells are small.

I noticed that some meshes from the source geometry like the houses have incredible poor / overdetailed geometry for baking which will make the baking very slow at runtime and also add more map errors. On lowend hardware like mobile it would be better to bake from the more simple Static Collider shapes or use more optimized placeholder geometry instead of the visual meshes.

[thirty6down]

Thank you for the quick suggestions!

I have reduced the collisionshape3d (for both the tree and the house) down to boxshape3d.

Comparison between the two (cell and height both at default 0.25) Desktop Mobile

Adjusting the cell size and cell height to 1m, I still get very different behavior on desktop/mobile.

[smix8]

Does this also happen in older Godot 4 versions / Godot 3.5? The baking is identical in all those versions and this is the first time that an Android user reported such an issue. It seems like such an obviously wrong navmesh that I would assume there must be a flood of issue reports already if all versions had this issue.

I also noticed some bake objects like the houses have scaled their Nodes by 1.3x and are also .glb nested imports. Try removing the scaling from the nodes, reset to 1.0, and also to remove the .glb import, turn those nodes into direct Scene nodes with no dependency on the .glb file using the pure .mesh resource. Just to rule out this is a scaling bug or a .glb import bug on Android.

[thirty6down]

Does this also happen in older Godot 4 versions / Godot 3.5?

I can confirm that this happens in beta 9 as well - I can take a look at 3.5 as well if needs be, although I have no experience with 3d in 3.5 so it might take a bit for me to figure out the backport.

I also noticed some bake objects like the houses have scaled their Nodes by 1.3x and are also .glb nested imports. Try removing the scaling from the nodes, reset to 1.0, and also to remove the .glb import, turn those nodes into direct Scene nodes with no dependency on the .glb file using the pure .mesh resource. Just to rule out this is a scaling bug or a .glb import bug on Android.

I have removed the houses, and converted the trees into cube mesh's (through godot, not as .glb). I can confirm the unusual behaviour still persists:

[smix8]

Anyone with a mobile setup can test and reconfirm that the issue still exists in Godot 4 RC1+.

[smix8]

Closing due to being from an old beta-build with no confirmation, android-able testers and feedback after months.

If any mobile user can reconfirm that the issue still exists in recent Godot 4.1+ just add your findings below so we can reopen.

[Fobbos08]

faced the same issue on tablet everything ok on desktop but incorrect (sometimes not calculated at all) on android I've tried simple scene with PlaneMesh version 4.1.1 android 13

[smix8]

@Fobbos08 Can you test with the NavigationMesh baking set to parse static colliders only and use StaticBody3D physics collision shapes instead of visual meshes for the baking. Does it have the same bake issues on your mobile hardware as the visual meshes from MeshInstance3D?

[Fobbos08]

so, i've tried with BoxShape3d and it looks good.

Also i've tried to bake with mesh only on my another device, and it also looks good.

other device also on android 13 but with another processor on tablet Snapdragon 870 on mobile Snapdragon 778G

[Fobbos08]

I had opportunity to check this issue on one more device. And this issue reproduced. Looks like processors with instruction set ARMv8.2-A have this issue

[smix8]

@Fobbos08 Did those devices show the issue when baking from both physics shapes or only when baking from visual meshes?

[Fobbos08]

visual meshes only

[smix8]

If it works with physics shapes but not with visual meshes that would explain a few things.

There are a few issues open with known rendering bugs on specific mobile processors that have problems with corrupted mesh data e.g. https://github.com/godotengine/godot/issues/80668. The navigation mesh baking reads the mesh data from the RenderingServer. If this data is already corrupted by the rendering the navigation mesh will turn out bad as well.