StrafesNET/strafe-project
7
Fork 4
Code Issues 18 Pull Requests Packages Projects Releases 2 Wiki Activity

Physics Bugs #9

New Issue
Closed
opened 2025-03-11 22:38:15 +00:00 by Quaternions · 15 comments
Quaternions commented 2025-03-11 22:38:15 +00:00
Owner
Copy Link
  1. smooth transfer between flush minkowski surfaces (#35)
  2. the monster jam bsp bug fall through slanted part (#37)
  3. bhop_toc bug hitting the side of a crate on the last stage, falling through the ground (#16)
  4. bhop_toc boosters repeated activation bug (#36)
  5. bhop_toc jump at end fall through floor DUPLICATE OF BUG 7
  6. walk into wall without moving mouse, walk target is not refreshed at end of wall FIXED in 55ff199269
  7. very small mv value fall through ground xD FIXED in 81c9e3470b
  8. surf (#38)
  9. divide by zero in Minkowski vert_edges (UNREPRODUCIBLE)
  10. bhop_arcane_v2 tetris stage accelerators are too strong FIXED in c7263df4ae0ec8be9d7f51dacf1dcb550b1a98e7, cbf8a1ccfb424abaaafc78f9f127c52c62ea62a3
  11. Fly and clip through any edge or corner (duplicate of 3?)
  12. Walking on a slanted surface and turning the mouse (duplicate of 8?)
  13. bhop_arcane fall through logs (#24)
1. smooth transfer between flush minkowski surfaces (#35) 2. the monster jam bsp bug fall through slanted part (#37) 3. bhop_toc bug hitting the side of a crate on the last stage, falling through the ground (#16) 4. bhop_toc boosters repeated activation bug (#36) 5. ~~bhop_toc jump at end fall through floor~~ DUPLICATE OF BUG 7 6. ~~walk into wall without moving mouse, walk target is not refreshed at end of wall~~ FIXED in 55ff199269ec9c99b715578ae7cf54cf28cc8017 7. ~~very small mv value fall through ground xD~~ FIXED in 81c9e3470b36f2a08bdced795f66086c4d8ad32f 8. surf (#38) 9. divide by zero in Minkowski vert_edges (UNREPRODUCIBLE) 10. ~~bhop_arcane_v2 tetris stage accelerators are too strong~~ FIXED in c7263df4ae0ec8be9d7f51dacf1dcb550b1a98e7, cbf8a1ccfb424abaaafc78f9f127c52c62ea62a3 11. Fly and clip through any edge or corner (duplicate of 3?) 12. Walking on a slanted surface and turning the mouse (duplicate of 8?) 13. ~~bhop_arcane fall through logs~~ (#24)
Quaternions commented 2025-03-14 02:01:19 +00:00
Author
Owner
Copy Link

Bug 2 identified as physics mesh faces consisting of vertices which don't lie precisely on the face. To fix: generate mesh vertices with half precision and limit the number of vertices per face to 3. Use bnum [u8;N] update to make this great.

WIP branches are max-area-triangulation and physics-bug2

TODO: Fix concavities on source engine maps

  • Split concavities into multiple submeshes ❌ too complicated
  • Generate convex hull from vertices instead to guarantee convexity in a simple way

Patch has been applied for part 1 of this bug: cfd9550566
Part 2 is to generate convex hull for bsp meshes

Bug 2 identified as physics mesh faces consisting of vertices which don't lie precisely on the face. To fix: generate mesh vertices with half precision and limit the number of vertices per face to 3. Use bnum [u8;N] update to make this great. WIP branches are [`max-area-triangulation`](https://git.itzana.me/StrafesNET/strafe-project/commits/branch/max-area-triangulation/) and [`physics-bug2`](https://git.itzana.me/StrafesNET/strafe-project/commits/branch/physics-bug2/) TODO: Fix concavities on source engine maps - Split concavities into multiple submeshes ❌ too complicated - Generate convex hull from vertices instead to guarantee convexity in a simple way Patch has been applied for part 1 of this bug: cfd9550566249ef2236b0ec8ce3a382093e13e49 Part 2 is to generate convex hull for bsp meshes
Quaternions commented 2025-03-14 22:23:18 +00:00
Author
Owner
Copy Link

Bug 9 is suspected by the Quaternion to be a brush mesh which is misinterpreted by the physics mesh conversion because of identical Face hashes.

Edit:
I don't think identical Face hashes is a problem because distinct SubmeshFaceIds are still generated for each polygon regardless if it points to the same MeshFaceId.

Bug 9 is suspected by the Quaternion to be a brush mesh which is misinterpreted by the physics mesh conversion because of identical Face hashes. Edit: I don't think identical Face hashes is a problem because distinct SubmeshFaceIds are still generated for each polygon regardless if it points to the same MeshFaceId.
aidan9382 commented 2025-03-18 22:08:37 +00:00
Member
Copy Link

I've been looking into the early collision end bug (not sure which one this counts under - it's where you fall off a platform too early when walking depending on how you landed on it) - so far the only substantial difference between landing on a part going towards or away from an edge is a SubmeshVertId chosen throughout the collision. If it should be different and why it causes weird collision end, no idea yet

I've been looking into the early collision end bug (not sure which one this counts under - it's where you fall off a platform too early when walking depending on how you landed on it) - so far the only substantial difference between landing on a part going towards or away from an edge is a SubmeshVertId chosen throughout the collision. If it should be different and why it causes weird collision end, no idea yet
Quaternions commented 2025-03-18 23:17:42 +00:00
Author
Owner
Copy Link

I've been looking into the early collision end bug (not sure which one this counts under - it's where you fall off a platform too early when walking depending on how you landed on it)

This is bug 1, the physics is failing to transfer the point of contact across the edge boundary to another flush minkowski face.

> I've been looking into the early collision end bug (not sure which one this counts under - it's where you fall off a platform too early when walking depending on how you landed on it) This is bug 1, the physics is failing to transfer the point of contact across the edge boundary to another flush minkowski face.
Quaternions commented 2025-03-19 23:43:38 +00:00
Author
Owner
Copy Link

Bug 1 has a fix in the minkowksi-transfer branch but it accentuates the effects of deeper bugs with the minkowski MeshQuery implementation. I desperately need a face crawler state visualizer to shake out the MeshQuery bugs.

Bug 1 has a fix in the [`minkowksi-transfer`](https://git.itzana.me/StrafesNET/strafe-project/src/branch/minkowksi-transfer/) branch but it accentuates the effects of deeper bugs with the minkowski MeshQuery implementation. I desperately need a face crawler state visualizer to shake out the MeshQuery bugs.
Quaternions commented 2025-05-10 02:35:36 +00:00
Author
Owner
Copy Link

Bug 10 is fixed. It was a combination of leaky acceleration state from a previous physics state (c7263df4ae0ec8be9d7f51dacf1dcb550b1a98e7), and rbx_loader interpreting Accelerator as also being boosters (cbf8a1ccfb424abaaafc78f9f127c52c62ea62a3). Note that acceleration should probably not be persistent state since it should never persist to the next state, it should always be freshly calculated.

Bug 10 is fixed. It was a combination of leaky acceleration state from a previous physics state (c7263df4ae0ec8be9d7f51dacf1dcb550b1a98e7), and rbx_loader interpreting Accelerator as also being boosters (cbf8a1ccfb424abaaafc78f9f127c52c62ea62a3). Note that acceleration should probably not be persistent state since it should never persist to the next state, it should always be freshly calculated.
Quaternions commented 2025-05-14 23:56:30 +00:00
Author
Owner
Copy Link

Bug 7 is fixed. Bug 5 is a duplicate of bug 7. Predicted intersection times could exceed the maximum / minimum representable Time(i64) values, which were being used like they were implicitly infinity. Refactored face crawler to use explicit Bounds to be able to represent unbounded time limits in 81c9e3470b. Added a unit test test_collision_small_mv in 2ecaeb1615 to prove that it is fixed and prevent regressions in the future.

Bug 7 is fixed. Bug 5 is a duplicate of bug 7. Predicted intersection times could exceed the maximum / minimum representable Time(i64) values, which were being used like they were implicitly infinity. Refactored face crawler to use explicit Bounds to be able to represent unbounded time limits in 81c9e3470b36f2a08bdced795f66086c4d8ad32f. Added a unit test `test_collision_small_mv` in 2ecaeb1615fc2a6e9066dac71f78b6175fbfca5b to prove that it is fixed and prevent regressions in the future.
aidan9382 commented 2025-05-15 10:11:39 +00:00
Member
Copy Link

An interesting note: Bug 8 (aka surfs in general) seem to behave differently depending on the direction you go - if you're turning into either the negative X or negative Z, the surf behaves reasonably well, whereas you'll basically never be able to surf if you're going positive X or positive Z

I've attached the map (with .txt on the end so it attaches, thanks gitzaname) so you can test it yourself - red indicates negative, green indicates positive (Note: pressing r to reset just kinda breaks so avoid pressing it and rely on the triggers below)

An interesting note: Bug 8 (aka surfs in general) seem to behave differently depending on the direction you go - if you're turning into either the negative X or negative Z, the surf behaves reasonably well, whereas you'll basically never be able to surf if you're going positive X or positive Z I've attached the map (with .txt on the end so it attaches, thanks gitzaname) so you can test it yourself - red indicates negative, green indicates positive (Note: pressing r to reset just kinda breaks so avoid pressing it and rely on the triggers below)
bhop_surfbug.snfm.txt
5.0 KiB
Quaternions commented 2025-05-22 22:31:44 +00:00
Author
Owner
Copy Link

An interesting note: Bug 8 (aka surfs in general) seem to behave differently depending on the direction you go - if you're turning into either the negative X or negative Z, the surf behaves reasonably well, whereas you'll basically never be able to surf if you're going positive X or positive Z

Falling through surfs happens when you move the mouse, which activates set_velocity_cull, which mistakenly culls the surf from the contacts. set_velocity_cull should not really exist in the first place, I believe that a proper fix would involve redesigning when and how contacts are culled.

pressing r to reset just kinda breaks

I bet this would be a great bugfix for learning Rust, and would genuinely help the project

> An interesting note: Bug 8 (aka surfs in general) seem to behave differently depending on the direction you go - if you're turning into either the negative X or negative Z, the surf behaves reasonably well, whereas you'll basically never be able to surf if you're going positive X or positive Z Falling through surfs happens when you move the mouse, which activates `set_velocity_cull`, which mistakenly culls the surf from the contacts. `set_velocity_cull` should not really exist in the first place, I believe that a proper fix would involve redesigning when and how contacts are culled. > pressing r to reset just kinda breaks I bet this would be a great bugfix for learning Rust, and would genuinely help the project
Quaternions commented 2025-08-27 23:09:37 +00:00
Author
Owner
Copy Link

Bug 3 is potentially caused by the size of the hitbox being exactly the same as the size of the platforms on bhop_toc. The platforms are potentially rotated by a tiny amount, or maybe not. This means that the time that the top of the hitbox stops hitting the top of the platform is exactly the same time that the trigger is hit. Only one of the two collision events is being processed, the other is ignored because they both occur on the exact same timestamp, and zero-time events are not well tested.

  • Create a unit test that contrives multiple simultaneous collisions to test this edge case.
  • Unrelated: create a unit test to contrive bounding box edge cases, like if something lands on the exact edge of something else.

Edit:
I've created the test and opened a dedicated issue: #16

Bug 3 is potentially caused by the size of the hitbox being exactly the same as the size of the platforms on bhop_toc. The platforms are potentially rotated by a tiny amount, or maybe not. This means that the time that the top of the hitbox stops hitting the top of the platform is exactly the same time that the trigger is hit. Only one of the two collision events is being processed, the other is ignored because they both occur on the exact same timestamp, and zero-time events are not well tested. - [x] Create a unit test that contrives multiple simultaneous collisions to test this edge case. - [x] Unrelated: create a unit test to contrive bounding box edge cases, like if something lands on the exact edge of something else. Edit: I've created the test and opened a dedicated issue: #16
aidan9382 commented 2025-11-19 18:56:12 +00:00
Member
Copy Link

You can always clip by walking into a wall and then releasing all movement keys just before you hit a wall. If you keep holding the movement keys, you won't end up clipping into it (see attached video)
Not sure matches any of the other categories
Addendum: You can also clip by being very close to the wall when you start walking. Basically, the only case where you don't clip is when you're at max walk speed

You can always clip by walking into a wall and then releasing all movement keys just before you hit a wall. If you keep holding the movement keys, you won't end up clipping into it (see attached video) Not sure matches any of the other categories Addendum: You can also clip by being very close to the wall when you start walking. Basically, the only case where you don't clip is when you're at max walk speed
walking.mp4
1.9 MiB
Quaternions commented 2025-11-19 19:00:05 +00:00
Author
Owner
Copy Link

You can always clip by walking into a wall and then releasing all movement keys just before you hit a wall. If you keep holding the movement keys, you won't end up clipping into it (see attached video)
Not sure matches any of the other categories

My guess would be that it's an algorithmic setup failure similar to the one described in #13.

Edit:
Maybe not. More likely it's a logic error in the MoveState impls mess (i.e. apply_enum_and_input_and_body and friends)

> You can always clip by walking into a wall and then releasing all movement keys just before you hit a wall. If you keep holding the movement keys, you won't end up clipping into it (see attached video) > Not sure matches any of the other categories My guess would be that it's an algorithmic setup failure similar to the one described in #13. Edit: Maybe not. More likely it's a logic error in the `MoveState` impls mess (i.e. `apply_enum_and_input_and_body` and friends)
Quaternions commented 2026-01-26 17:16:16 +00:00
Author
Owner
Copy Link

pressing r to reset just kinda breaks so avoid pressing it and rely on the triggers below

Worked around in 3893b2f44f. Looks like the physics gets asked to simulate a huge time stretch, and you clip through the ground instead of hitting the spawn. I reset the timer to 0 so it no longer gets requested to simulate a long duration in 1 tick.

> pressing r to reset just kinda breaks so avoid pressing it and rely on the triggers below Worked around in 3893b2f44ff45913f875631d146d2ab659e8523b. Looks like the physics gets asked to simulate a huge time stretch, and you clip through the ground instead of hitting the spawn. I reset the timer to 0 so it no longer gets requested to simulate a long duration in 1 tick.
Quaternions commented 2026-01-27 17:08:19 +00:00
Author
Owner
Copy Link

You can always clip by walking into a wall and then releasing all movement keys just before you hit a wall. If you keep holding the movement keys, you won't end up clipping into it (see attached video)
Not sure matches any of the other categories
Addendum: You can also clip by being very close to the wall when you start walking. Basically, the only case where you don't clip is when you're at max walk speed

Fixed in #30

> You can always clip by walking into a wall and then releasing all movement keys just before you hit a wall. If you keep holding the movement keys, you won't end up clipping into it (see attached video) > Not sure matches any of the other categories > Addendum: You can also clip by being very close to the wall when you start walking. Basically, the only case where you don't clip is when you're at max walk speed Fixed in #30
Quaternions commented 2026-01-30 18:03:30 +00:00
Author
Owner
Copy Link

Closing this issue in favour of closable individual issues.

Closing this issue in favour of closable individual issues.
Quaternions added the physics-bug label 2026-01-30 18:29:39 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
enhancement
map-convert
physics-bug
No Label physics-bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
AxisAngles CI itzaname Quaternions
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: StrafesNET/strafe-project#9
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?