[Most MP games] Unstable collision detection in VPhysics in modern game builds. (CS:S, DoD:S, CS:GO, TF2, Portal 2, HL2:DM, HLDM:S and SFM)

[Grocel]

About

All updated VPhysics branches (especially CS:GO (Source 1) vphysics) have quite an unreliable collision detection. This means in some cases props and other physics objects will briefly glitch through map object, other props or other physics objects.

It has been first discovered in Garry's Mod. It has been found to be an upstream issues on most Valve games, including CSS, TF2 and HL2:DM.

Visual summery

A reproduction Video

[!NOTE] The first three games in the video are "known good". The issues are visible starting at 5:45.

Games

In which games does it happen?

Game (Branch/Build)	Physics OK?	Notes	Link
Garry's Mod (x86-64, 32bit)	❌	3️⃣	https://github.com/Facepunch/garrysmod-issues/issues/5968
Garry's Mod (x86-64, 64bit)	❌	3️⃣
Garry's Mod (main)	✔️	3️⃣
Garry's Mod (dev, with double-physics-test build)	✔️	3️⃣
Garry's Mod (prerelease)	✔️	3️⃣
Counter Strike: Source	❌
Counter-Strike: Global Offensive (Source 1)	❌	See Garry's Mod note
Half-Life 2: Deathmatch	❌
Half-Life 2 (20th Anniversary Build, Latest)	✔️
Half-Life 2 (x64 2005 Build)	✔️	ℹ️
Team Fortress 2 (Latest, after 2025-08-14)	❌
Team Fortress 2 (double-physics-test, 2025-11-10)	✔️
Left 4 Dead 1 (Latest build)	❌
Left 4 Dead 1 (Day One Build, 2008)	❌	ℹ️
Left 4 Dead 2	❌
Portal 1	✔️
Portal 2 (Latest build)	❌	⚠️
Portal 2 (Day One Build, 2011)	❌	⚠️, ℹ️
Portal 2 Educational Edition (2013 Build)	❌	⚠️, ℹ️
Day of Defeat: Source	❌
Half-Life Deathmatch: Source	❌	⚠️, ℹ️
Alien Swarm	❌
Source Film Maker	❌
Insurgency	❌	3️⃣, 💀, ⚠️, ℹ️
Black Mesa (2012 mod)	✔️	3️⃣, ℹ️
Black Mesa (Steam version, "Definitive")	✔️	3️⃣, ⚠️, ℹ️
Postal 3	✔️	3️⃣, ⚠️, ℹ️
StrataSource (P2CE, buildid 19733512)	❌	3️⃣, ℹ️	https://github.com/StrataSource/Engine/issues/1490
StrataSource (Momentum 0.10.0-prerelease, buildid 19719896)	✔️	3️⃣, ℹ️

3️⃣ = Thirdparty game ℹ️ = Tested by someone else ⚠️ = Test map does not run properly out of the box and might need additional settings or modification. 💀 = Game does not start

[!NOTE] Garry's Mod uses a version of Counter-Strike: Global Offensive VPhysics for its x64 x86-64 branch. The main Branch uses a much older VPhysics that doesn't seem to have the issue. The older VPhysics is x32 only and is actually blocking the transition to a fully x64 bit Garry's mod.

OS and Hardware

It happens on Windows and Linux. On MacOS probably too, but untested. The issue is also hardware vendor independent.

Details and Reproduction

Please look into the Garry's Mod issue. There are all the details needed to know, these are relevant to all Valve games even if it seems Garry's Mod focused at first. There are test setups and maps for reproduction also.

SligWolf's Post

Hiho!

Some more tests and all the files down below to test it for yourself!

Foreword: If I fire the weapon in the video, it always fulfill a purpose and is not for fun. I do that to activate buttons and for the test purpose. Including also provoking physical behavior and movement of objects.

The first clip (GMod Default) in all videos is our basis for all followed clips in the video. Each video contain only a single experiment and the title numbers refer to the texture numbers from the map.

There are many blue colored buttons on the map that you see in the video. They have different values for the game engines. This is necessary because all the game engines have different physical environment settings.

I used 2 different maps because the physic problem tends to happen much more and worse if the map have big geometry in it. In our case the "func_detail" railways are the large geometry here on the map "physics_test_long".

On the map "physics_test_short" the problem is not that bad on map brushes, but still persistent on the prop rail.

used console commands:
- sv_cheats 1
- vcollide_wireframe 1
- noclip 

---

All the following tests were made on the map called: "physics_test_long"

Note: In all video titles the [L] stands for the map "physics_test_long".

Test 1:

• We spawn doors and let them bounce on the brush rail (func_detail) via the buttons to see strange behavior.
• All buttons fire for 0.1 second a "trigger_push". https://www.youtube.com/watch?v=hnnJDZyqt-o

Test 1A:

• We spawn doors on the brush rail (func_detail) and and shoot them to see strange behavior. https://www.youtube.com/watch?v=WC6ikg_s4Qs

Test 2:

• We spawn 3 doors over each other and let them bounce on the brush rail (func_detail) via the buttons to see strange behavior.
• All buttons fire for 0.1 second a "trigger_push". https://www.youtube.com/watch?v=d02tjLdXa6o

Test 3:

• We let the build in train drive over the brush rail (func_detail) to see strange behavior. https://www.youtube.com/watch?v=Gj54b7JbkWM

Test 5:

• We let the build in train drive over the prop rail (prop_physics) to see strange behavior. https://www.youtube.com/watch?v=WosMI14pWeI

Test 6:

• We spawn doors and let them bounce on the prop rail (prop_physics) via the buttons to see strange behavior.
• All buttons fire for 0.1 second a "trigger_push". https://www.youtube.com/watch?v=2n6fjLcVBb0

Test 6A:

• We spawn doors on the prop rail (prop_physics) and and shoot them to see strange behavior. https://www.youtube.com/watch?v=OXYLC3yJmE8

Test 7:

• We spawn 3 doors over each other and let them bounce on the prop rail (prop_physics) via the buttons to see strange behavior.
• All buttons fire for 0.1 second a "trigger_push". https://www.youtube.com/watch?v=X8hLcqlunq8

---

All the following tests were made on the map called: "physics_test_short"

Note: In all video titles the [S] stands for the map "physics_test_short"

Test 1:

• We spawn doors and let them bounce on the brush rail (func_detail) via the buttons to see strange behavior.
• All buttons fire for 0.1 second a "trigger_push". https://www.youtube.com/watch?v=SRk8SZUfUtw

Test 1A:

• We spawn doors on the brush rail (func_detail) and and shoot them to see strange behavior. https://www.youtube.com/watch?v=X9PyEsTd5L0

Test 2:

• We spawn 3 doors over each other and let them bounce on the brush rail (func_detail) via the buttons to see strange behavior.
• All buttons fire for 0.1 second a "trigger_push". https://www.youtube.com/watch?v=XC74o327x64

Test 3:

• We let the build in train drive over the brush rail (func_detail) to see strange behavior. https://www.youtube.com/watch?v=lcu8k1tTWt4

Test 5:

• We let the build in train drive over the prop rail (prop_physics) to see strange behavior. https://www.youtube.com/watch?v=ICxQMo7mdSg

Test 6:

• We spawn doors and let them bounce on the prop rail (prop_physics) via the buttons to see strange behavior.
• All buttons fire for 0.1 second a "trigger_push". https://www.youtube.com/watch?v=Htk_s7__1oQ

Test 6A:

• We spawn doors on the prop rail (prop_physics) and and shoot them to see strange behavior. https://www.youtube.com/watch?v=xSZIL1Q1EqM

Test 7:

• We spawn 3 doors over each other and let them bounce on the prop rail (prop_physics) via the buttons to see strange behavior.
• All buttons fire for 0.1 second a "trigger_push". https://www.youtube.com/watch?v=buPUUq3hpKg

---

All files can be downloaded here: all_new_files_for_testing.zip (GitHub) all_files_for_testing.7z (DropBox)

Content list:

• physics_test_long.bsp
• physics_test_long.vmf
• physics_test_short.bsp
• physics_test_short.vmf
• rail_29696.mdl
• big_rail.blend
• big_rail_29696.qc
• big_rail_29696.smd

---

If there is something unclear or you have any questions, please leave a comment!

Originally posted by @SligWolf in Facepunch/garrysmod-issues/#5968

Solution

Apparently @ficool2 has found a solution containing a single line fix. It also has been said that said fix had been submitted to Valve by @robotboy655 a maintainer of Garry's Mod a few week ago. The issue can not be fixed by @robotboy655, because of licensing issues.

Test Setup

The reproduction setup is designed to be mostly platform and game independent. Source files are included. It has been confirmed by @ficool2 to be able to reproduce the issue at hand.

Files of the test setup:

Version 1

• all_new_files_for_testing.zip (GitHub)
• all_files_for_testing.7z (DropBox)

Version 2

• valve_source_engine_issue7426_v2.zip (GitHub)
• valve_source_engine_issue7426_v2.zip (DropBox)

Known Fix

Compile VPhysics using doubles instead of floats.

[goodusername123]

This issue also affects Day of Defeat: Source and Half-Life Deathmatch: Source

[DarthTealc]

Gmod main branch, which does not have the issue, is using a 32bit vphysics that is signed by Valve and dated 2013. The bug was therefore introduced at some point after that. Robotboy655 (Facepunch Studios / Gmod) and ficool2 both have the one-line fix and have reportedly both submitted it to different Valve contacts.

As Grocel noted, the bug existing in Gmod's x86-64 branch's vphysics (both 32bit and 64bit) is preventing the migration of Gmod to 64bit as it's a regression over what's currently available on Gmod's main branch. But there's no 64bit version of the stable vphysics on main branch as it's from 2013. And while Facepunch could perform the fix themselves, they do not have the rights to distribute their own compilation of vphysics due to Microsoft's licencing restrictions on Havok/IVP.

[dvdvideo1234]

It was about time this gets updated. I am tired of answering people why their trains fall trough the rails in Garry's mod :) Valve please fix this physics bug.

[BlackIceKB]

This would explain some oddities I've come across recently - I was thinking if it was a Facepunch problem or a Valve concern, but if it is indeed due to Licensing, then we need to push Valve on applying this relatively easy fix.

[megakarlach]

Just tested it on L4D1, L4D2 and Portal 2, all 3 of them seems to be affected aswell. In test 4, prop trains on prop rails causing it to get pushed backward. Portal 1 isn't affected. Only tested with Test 1 and 4 (and Test 4 only on L4D2 & Portal 1).

Looks like any Source games since L4D likely introduced physics optimization so the game would ran better on Xbox 360 & PS3 and low end PCs, these optimization was later backported to older titles when those games are upgraded from Source 2013 MP to Team Fortress 2 branch.

[Grocel]

Just tested it on L4D1, L4D2 and Portal 2, all 3 of them seems to be affected aswell. In test 4, prop trains on prop rails causing it to get pushed backward. Portal 1 isn't affected. Only tested with Test 1 and 4 (and Test 4 only on L4D2 & Portal 1).

Thanks for testing. Added your info to the OP. So in summery: Almost all source engine games are affected.

[DarthTealc]

Not sure how useful this is given a fix has already been sent to Valve and it's just a matter of them adding it, but here's the signing dates for various Source games, with link dates for those that are unsigned.

I noticed Aperture Tag and Thinking with Time Machine were signed in 2014, which is between Gmod's "known good" 2013 version and "known bad" 2019 version. Could be interesting to test if they have the bug. They're based on Portal 2 which DOES have the bug, but they were updated a lot longer ago than Portal 2 was last updated.

It's also interesting to note that other than Gmod's main branch, Portal 1 and HL2 are the only games known to not have the bug, and they're also the only games that haven't been digitally signed (other than Alien Swarm which has not been tested), which I figure means they're on an older branch of vphysics that is closer to the 'known good' 2013 version used by Gmod's main branch.

It could also be worth testing Insurgency as it uses a version signed in 2017. It also has a 64bit version that they signed themselves.

[megakarlach]

https://github.com/user-attachments/assets/91386ac6-96a9-4a54-8169-c62d566eaae0

Just did additional test with L4D, this time using original (day one) launch build from Nov 17, 2008 / build 3663 (with signed VPhysics from November ‎16, ‎2008), confirmed that the same issue are present like the latest L4D build. This also very likely mean that any games derived from L4D branch (aswell as Alien Swarm, Portal 2, CS:GO which kept the VPhysics change from L4D) or backported L4D's VPhysics optimization to Orange Box & SteamPipe branch (like TF2 branch and GMOD's x64 branch) will have this issues.

Also tested Source SDK Base 2013 MP's sourcetest (Source Engine Test), both the Source 2013 MP branch (previous2021) and TF2 branch version. The last version of SDK Base 2013 on 2013 MP branch was dated June 2021 (also the last for CS:S, DOD:S, HL2DM and HLDM:S), and it doesn't have VPhysics issues, while TF2 branch version of SDK Base 2013 MP does.

[megakarlach]

For Alien Swarm, it's very tricky to test, and the map has to be modified so the player can interact with the buttons while having 3rd person view. Regardless, physics issue are likely also present here aswell, and unlike other Source games, the train cart doesn't rotate when pressing the reset button, and when trying to reset the train 4th times, the game freezes, while the physics glitching out.

https://github.com/user-attachments/assets/c0020388-7506-413b-ae1f-5da49d98ac83

https://github.com/user-attachments/assets/97b38adc-e71b-4ffb-ac15-3c81105112e9

[megakarlach]

Replying to https://github.com/ValveSoftware/Source-1-Games/issues/7426#issuecomment-3137015748

And just to be sure, I also tested this on SFM (also on Alien Swarm branch) which has first-person view, and the physics issue are present here aswell, and like Alien Swarm, the train cart doesn't rotate here either. This time I used the same pre-compiled map file from that zip without any modifications. The only difference here is that, unlike Alien Swarm, SFM doesn't freeze when the train was reset for the 4th time.

VPhysics dll on SFM was unsigned, but SFM itself was last updated in Jan 12, 2015, with engine built on Nov 4, 2014.

Test 1 and 2:

https://github.com/user-attachments/assets/7f6b1fac-7dde-42b5-ab09-930ff916e41a

Test 4/5:

https://github.com/user-attachments/assets/174797f3-4c5c-41d4-a5dc-a2b294c9acc6

[Grocel]

The prop rail is actually supposed to be frozen (motion disabled), but on working versions of vphysics it also even works well without issues if it is not frozen.

The issue is more pronounced on very elongated objects, that's why it is there. The issue is also not limited to prop rails and trains, but it is the most obvious there.

It is a real pain in Garry's Mod, as the game relies heavily on physics based gameplay. The issue has the potential to kill big parts of the game when the game migrates to x64 at this current state of VPhysics.

[megakarlach]

Replying to https://github.com/ValveSoftware/Source-1-Games/issues/7426#issuecomment-3139267278

Basically all games built on Left 4 Dead branch (up to CS:GO branch), and TF2 branch (which succeeds 2013 MP and used in all MP games) have unstable physics, while Portal and HL2 (including HL:S and HL2 Episodes & Lost Coast) are not affected since it ran on Source 2013 SP branch without any VPhysics optimizations/reduced precision, and all games on Source 2013 MP branch (including previous version of CS:S, DOD:S, etc. from 2021) are not affected either.

[SligWolf]

Hiho!

New test map version

@Grocel and me made a new version of the test maps!

• valve_source_engine_issue7426_v2.zip (GitHub)
• valve_source_engine_issue7426_v2.zip (DropBox)

Changelog

We optimized the test maps a bit. Changes:

• Fixed game crash with the train in Alien Swarm
• Improved usability in Alien Swarm
• Fixed train reset/teleporter not working properly in some games
• The zip package ships all used textures, including dev textures that might be missing in some games
• Changed skybox texture to be a solid gray
• Changed the numbering for the test regions from decals to func_illusionary's
• Added spawn points for all games and a buy zone for CS:S
• Made test setup more robust against user errors

Tested games

I tested the behavior of the new map in the listed games.

Issue happend:

Game	Yes	No
Counter Strike: Source	X
Half-Life 2: Deathmatch	X
Half-Life 2 (+ Episodes, Lost Coast)		X
Team Fortress 2	X
Left 4 Dead 1	X
Left 4 Dead 2	X
Portal 1		X
Portal 2	X
Day of Defeat: Source	X
Half-Life Deathmatch: Source	X
Alien Swarm	X
Source Film Maker	X

New Video

I will release a new testing video soon. It will be a summery video featuring the new map and addional games as listed in Grocel's main post.

Excluded from the video will be:

• Half-Life Deathmatch: Source
• Portal 2
• Source Filmmaker
• Insurgency

Half-Life Deathmatch: Source

All objects spawned by point_template are spawned twice for no apparent reason. So proper testing is not possible. But I was still able to repoduce the issue somewhat. The train being spawned twice:

Portal 2

Most brush textures are invisible for no known reason. It was possible to repoduce the issue there too. However it would be hard to see in a video. The rendering issue looks like this:

Source Filmmaker

I have to admit that I am not familiar enough to confidently produce a suitable video. So I will skip this one too. The issue was reproducible in Source Filmmaker aswell.

Insurgency

This game does not launch on Windows 11 and crashes your PC. The issue is not testable in this game in its current state and without modifying the game. It's also a source engine game, but not a Valve game. I just attempted to test it on @DarthTealc's request.

[DarthTealc]

Insurgency

This game does not launch on Windows 11 and crashes your PC. The issue is not testable in this game in its current state and without modifying the game. It's also a source engine game, but not a Valve game. I just attempted to test it on @DarthTealc's request.

I tried the 64bit version of the game in Windows 10 and was able to load into the maps, but the large map crashed the moment I shot the spawn button for test 1, and the small map crashed when I got near the buttons for test 1. I assume the game has stripped out some core things or simply doesn't work well outside of Windows 7.

Was just noteworthy as it contains a 64bit vphysics self-compiled by the company, between the "known good" and "known bad" dates for Gmod's versions. I think it's unlikely that they would've fixed the vphysics bug though.

[megakarlach]

Reply to #7426 (comment)

Portal 2 has this kind of quirk that cause the brush to disappear, due to skybox being drawn after the world brush. Large maps (or possibly poor VVIS optimization, or both maybe) can cause this kind of issue. Using r_skybox_draw_last 0 will fixes it.

HL Deathmatch: Source is infamous for it's bugs like HL:S, and this game has one bug specific to this game which is duplicated entities, any maps (including default HLDM:S maps) will always spawn duplicated entities.

[megakarlach]

Tested Insurgency (both 32-bit and 64-bit). In Windows 11, due to BattlEye anti-cheat shipped with the game was outdated and the game hasn't been updated since 2018, the game will fail to work on Windows 11, there are two solutions which is boot the game without BattlEye using "insurgency.exe" or "insurgency_x64.exe" (64-bit), or alternatively updating BattlEye using files from another game that has BattlEye anti-cheat.

Regardless, point_template is extremely broken in Insurgency and usually crash the game when spawned, making it impossible to do any test involving spawning props using this entity. Despite VDC mentioning that setting gamemode to "training" fixes it, it didn't work. Both 32-bit and 64-bit versions crashes in same way. What I can atleast do is the train test (physbox train on func_detail), which does get jammed when making a turn.

This was tested with small version of the map, one named physics_test_short_v2.bsp and the other named training.bsp (i rename the original training map) in order to trick the game into enabling training gamemode (as Insurgency doesn't have game_mode console command, nor map [map name] [game mode] like CS:GO), and like i said above, changing gamemode didn't fix the entity crashes.

https://github.com/user-attachments/assets/30637939-365c-4fad-89b2-87a9ee0ebe56

https://github.com/user-attachments/assets/19f3a11b-69f5-4362-85d1-2d54ccea1cb9

[SligWolf]

Here is the new video I made:

Games shown in the video:

Game	State: Good	State: Bad
Half-Life 2 (+ Episodes, Lost Coast)	X
Portal 1	X
Garry's Mod (Default)	X
Garry's Mod (x86-64)		X
Counter Strike: Source		X
Half-Life 2: Deathmatch		X
Team Fortress 2		X
Left 4 Dead 1		X
Left 4 Dead 2		X
Day of Defeat: Source		X
Alien Swarm		X
Portal 2		X

[!IMPORTANT] The physics shown in Garry's Mod were recorded BEFORE the physics patch from 2025-08-08.

In all games I will show these 8 physics tests:

Test 1:

I spawn doors on a func_detail railway and let them bounce for 5 times. They should land on the same spot after each hop. Slight movement is acceptable but no rotating or glitching.

Test 1 (shooting test):

I spawn doors on a func_detail railway and shoot 5 of them. Twitching is acceptable but no bigger movements like sliding or glitching.

Test 2:

I spawn doors on a func_detail railway and let them bounce for 5 times. But each stack has 3 doors instead of just one. Slight movement is acceptable but no rotating or glitching.

Test 3:

I let the brush-train drive through the curve to the straight part of the track. The motion should be mostly smooth with maybe a few bumps. Getting stuck and glitching through the railway should be considered as not stable.

Test 5:

I spawn the train from the map on a big frozen prop_physics rail. The train should normally land on the railway and drive smoothly on it. Everything else should be considered as not stable.

Test 6:

I spawn doors on a frozen prop_physics railway and let them bounce for 5 times. They should land on the same spot after each hop. Slight movement is acceptable but no rotating or glitching.

Test 6 (shooting test):

I spawn doors on a frozen prop_physics railway and shoot 5 of them. Twitching is acceptable but no bigger movements like sliding or glitching.

Test 7:

I spawn doors on a frozen prop_physics railway and let them bounce for 5 times. But each stack has 3 doors instead of just one. Slight movement is acceptable but no rotating or glitching.

Start parameters in all games

-console -dev

Console commands

Alien Swarm:

• firstperson
• thirdperson
• asw_hide_marine 0/1
• asw_controls 0/1

Portal 2:

• noclip
• r_skybox_draw_last 0/1

[Grocel]

I have posted on Knockout (a Source Engine related forum) to see if someone has more details about the whole issue. https://knockout.chat/thread/74503/

This guy might gave us the missing link in finding where Ficool's "single line" fix is supposed to be. The other claim about other changes Valve could have done destabilizing VPhysics on double precision is already has been found to be false.

Source: Discord Chat, 2025-08-08

[dvdvideo1234]

At work I usually use binary search on the tree to find the needed cange faster.. Maybe we can implement that here... When there are 100 revisions you test 50. The bug is either there or missing. If it's there you test revision 75 otherwise revision 25 and so on..

[Grocel]

At work I usually use binary search on the tree to find the needed cange faster.. Maybe we can implement that here... When there are 100 revisions you test 50. The bug is either there or missing. If it's there you test revision 75 otherwise revision 25 and so on..

I think your hint is not relevant to this issue, but thank you anyways. It is likely that someone at Valve already knows how to fix it. I think it is just a mater time.

Ficool2 just told me that he actually is a source engine licensee is not allowed to share information about the fix publicly, as the VPhysics source code is a matter of an NDA.

[megakarlach]

TF2 got a physics crash fix update today so i wonder if Valve also quietly fix the physics bug, loaded the test map again (V2 version) and nothing changed.

[zxz41]

VPhysics is generating collision penetration events for physic props, that shouldn't be penetrating in the first place, which in return causes them to be pushed away from each other. Happens presumably often whenever a collision set is updated somewhere. (Butterfly effect.) This was tested on the most up to date version of VPhysics (The one shipped with Team-Fortress 2)

glview file for reference, (glview is broken in the MP SDK, use SP branch I.E. Half-Life 2)

[Grocel]

Replying to https://github.com/ValveSoftware/Source-1-Games/issues/7426#issuecomment-3192585789

Does this behavior also happen in hl2 for you? We have found HL2 physics to be glicht free regarding of the matter of this topic. I classified the HL2's physics as known good in this case.

[zxz41]

Replying to #7426 (comment)

Does this behavior also happen in hl2 for you? We have found HL2 physics to be glicht free regarding of the matter of this topic. I classified the HL2's physics as known good in this case.

Nope, this does not occur on the Half-Life 2 Anniversary build. Or at least I haven't been able to reliably recreate it.

[zxz41]

I've been testing the VPhysics stuff toughly trying to figure out a reliable way to reproduce the bug, and so far the easiest case I've found is creating 16w 4096l 8h func_detail and mess around with small props such as the popcan01a model.

I've noticed the rotation and normals of the triangles seem to affect the collisions, although it's been inconsistent wherever or not the faulty collision is extruding outward or inward.

Top (and bottom) being affected.

https://github.com/user-attachments/assets/9a8d4edf-f6fa-4085-8ec2-03683b4da6b8

Left and right being affected.

https://github.com/user-attachments/assets/9bc4d92e-ea98-49da-94b0-aec0520849c8

Here's a rare instance of penetration detection pushing a physics prop upward.

https://github.com/user-attachments/assets/650c31e9-526f-4d79-8ab3-2cb0804cca76

For whatever reason, despite drawing the vcollision for the world (g_PhysWorldObject) there does not appear to be any bugged geometry.

VMF and compiled BSP file for test_align

[eepycats]

tested original x64 port of hl2 (2005) and it seems to be fine there

[Grocel]

Yeah the title of this issue is a bit misleading. It is an issue about the modern version of vphysics not if it is x86_64 or not. I will add your result to the OP. I also have seen this issue happening in modern x86_32 builds.

[megakarlach]

tested original x64 port of hl2 (2005) and it seems to be fine there

Can confirm that aswell. Basically any games that uses L4D's VPhysics (with that VPhysics optimization) or derived from L4D branch will have this issue, regardless whether it's 64-bit or not.

Edit: Since this test map was built for newer version of Source, the large map can cause crashes (hitting engine limits) with "too many verts for a dynamic vertex buffer" if you move the camera and look at the back of the map on Old Engine (Source 2004 and 2006).

https://github.com/user-attachments/assets/2c3ded05-f701-49ef-a559-0762347893b1

https://github.com/user-attachments/assets/6bbd01be-fa5f-4016-894e-22746b14b113

[megakarlach]

Also doing test with two third-party games, Black Mesa (both 2012 mod version on Source 2007 and latest Steam version/Definitive) and Postal III since those games, while still on Orange Box branch (heavily modified 2013 MP and 2009), both the Black Mesa DE and Postal 3 implemented certain features from L4D branch like what Valve did with TF2 branch (this doesn't always mean that VPhysics optimization from L4D was backported).

Black Mesa (Definitive Edition) engine (Xengine) is based off TF2 version of Source 2013 MP in mid-late 2010s with some features and optimizations from L4D and Portal 2 branch, while Postal III is Source 2009 but had implemented features from L4D branch like VPK v1 support (which was left unused), and have Nvidia PhysX which run side-by-side with IVP/Havok (PhysX is disabled by default since Postal III 2023 update and only used on Postal Dude coat but enabling it doesn't cause any problems with IVP/Havok anyway).

Neither game have L4D's VPhysics optimization, so there isn't any issues whatsoever, the only issues with the map on Black Mesa is the train itself doesn't render properly when teleported for first time and Postal 3 will crash when switching weapons (the test can still be done without it) since this map was built for HL2 and have entities that spawn HL2 weapons (however if you modify this map and remove the HL2 weapons entities, and replace it with Postal 3 weapons entities, it will work as expected).

Edit: The original 2012 version of Black Mesa render the train prop properly without any issues, only the Steam version have this issue.

Black Mesa (2012 mod), this also includes Source SDK Base 2007 in general:

https://github.com/user-attachments/assets/d1257816-fda1-4337-8762-e45c4389cda7

Black Mesa Definitive Edition:

https://github.com/user-attachments/assets/39024c56-b47b-4903-b441-0c375df18fee

Postal III:

https://github.com/user-attachments/assets/a6f766fa-4869-4a09-89ab-f80ad6f286d1

[megakarlach]

Tested day one build of Portal 2 (Apr 2011) and Portal 2 Educational Version (from Apr 2013), just to see if Valve done any physics fixes to these games during development (as gameplay in Portal series often involve physics) or whether Valve later breaks it after update.

Again the issue is still present (just like the L4D day one build). Also since "Aperture Tag" and "Thinking with Time Machine", two third-party mods/games are based on Portal 2 branch, they will have this issue.

The map also doesn't render properly like the latest Portal 2 build due to the same quirks and require r_skybox_draw_last 0 or VVIS & map optimization to display properly.

Lastly, Xbox 360 version of HL2 (via Orange Box) was partially tested (using unofficial SDK tools to convert the low-endian map to big-endian for console). The door push test seems to work differently and push way higher than before compared to PC version, and the prop_physics train track doesn't spawn due to issues related to converting the props using the unofficial SDK, so one of these test can't be done, but there appears to be no issues with VPhysics on this version either (or Valve didn't make any VPhysics optimization prior to L4D) and the train doesn't get jammed when doing the train test with func_detail train tracks.

https://github.com/user-attachments/assets/762f2a74-d8ea-4d79-b4a4-658ab7cface0

https://github.com/user-attachments/assets/b704a2be-53d9-4474-aeec-30438c4958d2