StrafesNET/strafe-project
6
Fork 4
Code Issues5 Pull Requests2 Packages Projects Releases2 Wiki Activity

Physics Bugs #9

New Issue
Open
opened 2025-03-11 22:38:15 +00:00 by Quaternions · 9 comments
Quaternions commented 2025-03-11 22:38:15 +00:00
Owner
  1. smooth transfer between flush minkowski surfaces
  2. the monster jam bsp bug fall through slanted part
  3. bhop_toc bug hitting the side of a crate on the last stage, falling through the ground (multitouch?)
  4. bhop_toc boosters repeated activation bug
  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 05dfb3920b
  8. surf
  9. divide by zero in Minkowski vert_edges (UNREPRODUCIBLE)
  10. bhop_arcane_v2 tetris stage accelerators are too strong FIXED in c7263df4ae, cbf8a1ccfb
1. smooth transfer between flush minkowski surfaces 2. the monster jam bsp bug fall through slanted part 3. bhop_toc bug hitting the side of a crate on the last stage, falling through the ground (multitouch?) 4. bhop_toc boosters repeated activation bug 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 05dfb3920b85b89e8ddd38fa5f22486d1cc05814 8. surf 9. divide by zero in Minkowski vert_edges (UNREPRODUCIBLE) 10. ~~bhop_arcane_v2 tetris stage accelerators are too strong~~ FIXED in c7263df4ae0ec8be9d7f51dacf1dcb550b1a98e7, cbf8a1ccfb424abaaafc78f9f127c52c62ea62a3
Quaternions commented 2025-03-14 02:01:19 +00:00
Author
Owner

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: split concavities into multiple submeshes

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: split concavities into multiple submeshes
Quaternions commented 2025-03-14 22:23:18 +00:00
Author
Owner

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

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

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

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

Bug 10 is fixed. It was a combination of leaky acceleration state from a previous physics state (c7263df4ae), and rbx_loader interpreting Accelerator as also being boosters (cbf8a1ccfb). 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

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

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

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
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: StrafesNET/strafe-project#9
No description provided.
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?