Merge map tris or use different BSP lump

[Derpius]

Context

• Gelly uses BSPParser's triangulated vertices to build Flex collision meshes from
• This causes artefacts when using fluid with a high adhesion value (as seen in #41)
• The BSP format includes at least two lumps for collision data, stored in the same format as .phy files according to the wiki (meaning we have no readily available documentation on how the data is structured, beyond the headers)
  • https://developer.valvesoftware.com/wiki/BSP_(Source)#Physics
  • https://developer.valvesoftware.com/wiki/PHY

Scope

There is an easy but less robust solution, and a difficult but robust solution to this problem. The scope for a robust solution using the physics lump is given, but the alternative is merging coplanar connected tris returned by BSPParser.

• Update BSPParser to parse and expose the physics lump
  • Requires investigation into the lump's format
• todo: rest of the scope

Acceptance Criteria

todo

[yogwoggf]

This is mostly superseded by the PHYParser PR #106, but I've encountered that PhyCollide, lump 29 doesn't always contain displacement physics data. In 2009 a new BSP lump was added, lump 28, known as PhyDisp. This is a special lump with displacement collision data. Internally, it's made by serializing vcollide data for the displacement "hulls" as virtual meshes.

Like you said, there are two lumps for physics collision. It's a little obvious that displacements would be one of them, but the main issue is that it's different between Hammer versions (technically, the vbsp.exe versions used). So, lots of players are finding that Hammer++ maps and old (2007) Hammer maps are working correctly. But, 2009 Hammer and up is compiling displacements into lump 28 which is choking up PHYParser.

Virtual meshes have never been parsed by anyone before, so it'll be some work until we can actually close this issue out. Therefore, this ticket has not been properly closed out by #106

Known bad maps being commonly reported by players

• koth_harvest_final
• phys_dmm_house
• phys_dmm_house_ni

Worth noting that ctf_2fort is broken completely due to LZMA compression and not inherently anything here (analysis shows 2fort doesnt even have any displacements which would cause the issue)

[yogwoggf]

Closed by #127, finally... although the fix is a band-aid. All it does is fall back to the BSP triangulated map data when PHYParser can't parse the known bad maps.