Closed Derpius closed 1 week ago
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
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)
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.
Context
.phy
files according to the wiki (meaning we have no readily available documentation on how the data is structured, beyond the headers)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.
Acceptance Criteria
todo