Don't give up when encountering lines/points/... in collision mesh data

[mosra]

Motivation and Context

Instead just skipping them. See this Slack thread for background info.

As this makes the isMeshPrimitiveValid() check obsolete, I removed the whole implementation of it (which, after all, was just a very verbose way to print the mesh primitive name originating back in the days when Habitat used glog and thus couldn't just call Magnum's builtin output operator for MeshPrimitive). Furthermore, a call to this function was also the only reason why addStage() too the collision mesh group parameter, so I removed it from there as well. Which is a documentation TODO:

• The addStage() docs probably need to be updated as they mention collision data that are no longer passed there. I don't know what should be said there, tho.

The check is now moved to inside constructBulletSceneFromMeshes(), where it just skips unsupported primitives with a warning. If the code could access the originating Magnum Trade::MeshData instead of
CollisionMeshData, it could be easily extended to support also triangle fans and triangle strips (since there's a MeshTools utility for converting them to triangle lists), but right now it skips those as well.

Also contains a drive-by fix for viewer --help output and use of a deprecated Magnum API.

How Has This Been Tested

⚠️ I have no idea what am I doing! The viewer doesn't assert for me anymore, but I don't know anything about the physics code, how it should / should not behave, and how to verify if the collision mesh is indeed generated correctly. So please test and give feedback. Making the PR as a draft due to that reason (and due to the doc TODO above).

[aclegg3]

This fix looks good to me. Thanks! 👍

[mukulkhanna]

Hey @mosra @aclegg3 , I just noticed that even though these changes are allowing the scenes to be loaded, the navmesh construction is still faulty.

I have identified a list of (at least) 28 scenes with this issue. Here are scene IDs of two of those: 102816627, 102344403. The habitat-viewer's navmesh visualization for these scenes shows how the navmesh is being created for some non-existent surfaces on the ceiling (and almost nothing for the actual floor):

This should be easy to reproduce using the habitat-viewer with the main branch:

./build/viewer --enable-physics --stage-requires-lighting --recompute-navmesh --dataset /path/to/hab-fp.scene_dataset_config.json -- 102816627

[mosra]

As I said above,

⚠️ I have no idea what am I doing

unfortunately I know too little about this area of the codebase to be able to understand what's going on 😅 I only made a best-intention attempt to not discard everything when some of the meshes are not triangles, and that part, to my understanding, should be working. If it means some new meshes, which were completely skipped before, are now showing up in the navmesh generation, there's possibly some additional problem. But also I may have overlooked something important that the original code was doing and that the new code isn't anymore, which is why I'm deferring to people who actually know the navmesh generation code, such as Alex.

Scenes that loaded correctly before are loading correctly now as well? Or neither that? Do you see any

Unsupported collision mesh primitive , skipping

messages in the output for the scenes that load wrong?

[mukulkhanna]

Thanks @mosra.

Scenes that loaded correctly before are loading correctly now as well?

Yes!

Do you see any "Unsupported collision mesh primitive , skipping" messages in the output for the scenes that load wrong?

Yes, I do.

[aclegg3]

Hey @mosra @aclegg3 , I just noticed that even though these changes are allowing the scenes to be loaded, the navmesh construction is still faulty.
...

Sorry for the long delay here.
I've investigated the issue and confirmed that this bug is related to the interpretation of the non-triangle mesh components by the navmesh computation code. My hypothesis is that recast voxelization assumes triangles, so the indices are getting clobbered resulting in artifacts.

Quick fix is to again filter by primitive during the mesh join phase of navmesh re-computation. See PR #1951. Try this out and see if it works.