Facepunch
Random func_detail brushes become non-solid to player (and other collision anomalies)
I have a fairly large and complex map for which I finally got around to doing a full compile. I noticed a strange phenomenon where certain func_detail brushes become non-solid to the player. Props and other physical objects collide with the brushes normally, but not the player, NPCs, or bullets. Tools such as the paint tool (applying decals) do not work on said brushes either. Breaking up a large func_detail into smaller func_details does not affect anything.
Additionally, I also notice some other strange anomalies. Certain areas of the map (I'm calling them "cursed" areas) display unusual behaviour. Like the non-solid func_detail brushes, these cursed areas appear in arbitrary locations, but their locations remain consistent across compiles. While in a cursed area, I've noticed the following things:
- Functions based on where the player is looking at don't seem to work. Spawning props, NPCs, etc. don't spawn on the crosshair but rather on the player's position. The physics gun beam displays similar behaviour, appearing to focus on a position at center of the player. Toolgun related things exhibit the same behaviour (spawning entities on the player's location).
- Bullet casings ejected from weapons do not fall to the ground as usual. Instead they float in place immediately after they are spawned.
- The "use" key functionality seems to work fine in cursed areas.
This issue occurs both with and without props present in the map. The introduction of cordon bounds (i.e. cutting the map in half) seems to mitigate the problems. The locations of the non-solid func_details and cursed areas do not seem to correlate.
There aren't any warnings or errors present in either the compile log or game console. Compile log is below. I am compiling without VIS or RAD, and including the -allowdynamicpropsasstatic and -notjunc options on VBSP. I will report more if I find anything else.
** Executing...
** Command: "D:\Program Files (x86)\Steam\SteamApps\common\GarrysMod\bin\vbsp.exe"
** Parameters: -allowdynamicpropsasstatic -notjunc -game "D:\Program Files (x86)\Steam\SteamApps\common\GarrysMod\garrysmod" "d:\gooball60\documents\source modding\maps\district\gm_district"
Valve Software - vbsp.exe (Dec 6 2021)
notjunc = true
8 threads
materialPath: D:\Program Files (x86)\Steam\SteamApps\common\GarrysMod\garrysmod\materials
Loading d:\gooball60\documents\source modding\maps\district\gm_district.vmf
ConVarRef mat_reduceparticles doesn't point to an existing ConVar
Patching WVT material: maps/gm_district/gm_conglomerate/blends/blenddirtgrass002_wvt_patch
fixing up env_cubemap materials on brush sides...
Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring...
ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (0)
ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (0)
Processing areas...done (0)
Building Faces...done (0)
Chop Details...done (1)
Find Visible Detail Sides...
Merged 6602 detail faces...done (2)
Merging details...done (1)
FixTjuncs...
PruneNodes...
WriteBSP...
done (3)
writing d:\gooball60\documents\source modding\maps\district\gm_district.prt...Building visibility clusters...
done (0)
Creating default LDR cubemaps for env_cubemap using skybox materials:
skybox/sky_gm_district_hdr*.vmt
! Run buildcubemaps in the engine to get the correct cube maps.
Creating default HDR cubemaps for env_cubemap using skybox materials:
skybox/sky_gm_district_hdr*.vmt
! Run buildcubemaps in the engine to get the correct cube maps.
Finding displacement neighbors...
Finding lightmap sample positions...
Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10
Building Physics collision data...
done (1) (3677611 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 19751 texinfos to 11992
Reduced 868 texdatas to 674 (32873 bytes to 25897)
Writing d:\gooball60\documents\source modding\maps\district\gm_district.bsp
16 seconds elapsed
** Executing...
** Command: Copy File
** Parameters: "d:\gooball60\documents\source modding\maps\district\gm_district.bsp" "D:\Program Files (x86)\Steam\SteamApps\common\GarrysMod\garrysmod\maps\gm_district.bsp"
** Executing...
** Command: "D:\Program Files (x86)\Steam\SteamApps\common\GarrysMod\hl2.exe"
** Parameters: -dev -console -allowdebug -game "D:\Program Files (x86)\Steam\SteamApps\common\GarrysMod\garrysmod" +map "gm_district"
Version is BSP 20. I've emailed you a stripped down version of the map which only includes basic geometry, it's enough to demonstrate the issue.
I've also noticed a new issue which I didn't include before since I couldn't reproduce it reliably, but it's come up again. Every now and then some sort of phantom collision volume appears in a random part of the map. It's a cube-ish shaped area that acts like an invisible clip brush, but isn't. The player gets stuck on it, but only when touching the faces aligned to a particular axis. I've included a compiled version of the map that suffers from this. I can't seem to figure out what exactly causes it, I've had it appear in a few different places only to disappear again a couple compiles later.
It might be worth noting that the map does fail to compile without -notjunc ("Too many t-junctions to fix up! (3603 prims, max 32768 :: 65541 indices, max 65536"). Since t-junction fixups are related to how func_detail geometry integrates with the world, perhaps there is a correlation.
Just for kicks I tried turning all of the func_detail brushes into world geometry, and surprisingly the problem still persisted. Seemingly random groups of brushes were still non-solid. The "cursed areas" seemed to disappear, however.
(restating this here from duplicate issue #5243 that I foolishly created)
A patch note from June 9 of last year stated that MAX_MAP_BRUSHSIDES was increased to around 163k (up from the previous limit of 65536). However, it seems as though that is not actually the case. While a map will appear to compile just fine with brushsides exceeding well above 65536, the aforementioned anomalies start to appear when that magic number of 65536 is exceeded.
Attached is a map (brushside_test.vmf) which has a very high density of brushes that, when compiled, results in a brushside count of 65503 - just barely under 65536. No anomalies are found in the map at this point. If you want to confirm this, compile the map with vvis and rad (preferably with -fast). Make sure the "Exceed brushside limit" visgroup is disabled for now. Observe the fullness chart entry for brushsides:
brushsides 65503/163840 524024/1310720 (40.0%)
Now, enable the "Exceed brushside limit" visgroup and compile again. The fullness chart now reads:
brushsides 65709/163840 525672/1310720 (40.1%)
Of course this is now exceeding 65536, and you can see that a portion of the half-cylinder in front of the info_player_start is non-solid, essentially exhibiting the same behaviour as what I described originally. You can add more cylinder segments to observe how the anomalies get worse the more you exceed the limit of 65536 brushsides.
This issue should be fixed on dev branch- in engine, it doesn't require recompiling map, it can be marked as solved¡ The update releases on the 13th- please help us test it prior! Originally posted by @robotboy655 in https://github.com/Facepunch/garrysmod-issues/issues/5036#issuecomment-1971246917
