i have some questions

[adamwong246]

first, I hope it is ok that I contact you through the GH issues. Let me know if you want to move the discussion elsewhere.

second, this library is a gem. Absolutely great work!

third, I am using it to make a physics engine and I have some questions about performance.

So my question is, should I merge my level geometry into large chunks? Or are small chunks more performant?

My levels have a lot of face-to-face perfectly overlapping faces, and I'd like to cull them from both the renderer and the physics engine. Should I merge the collid-able surfaces into some very complex polygon?

I had hoped that I could collapse the whole of the collid-able surfaces into one complex polygon, and the inverse (the non-collid-able areas aka open space) into another, and use the former to remove excess geometry/physics elements and use the later to create a navmesh. But before I embark on the endeavor, I would really like to know you opinions. This is all in the name of performance, so keep in mind it's a game.

One more thing, I have found sometimes my physics elements get stuck together, sneak through cracks and otherwise get stuck inside walls. This could well be a problem on my end, I'm not really a math guy, but I thought you should know the state of it. I can point you to the code it you are interested.

Lastly, I have found that, if I disable rendering, I can simulate 3000 bouncing balls before the the update exceeds 1/60th of a second. I plan to use no more than 50 but I still think it's a pretty decent benchmark.

[Prozi]

first, I hope it is ok that I contact you through the GH issues. Let me know if you want to move the discussion elsewhere.

it's best here so other users can read and benefit

second, this library is a gem. Absolutely great work!

thank you, I value appreciative users

So my question is, should I merge my level geometry into large chunks? Or are small chunks more performant?

no, just make sure the static bodies have isStatic flag set to true

https://prozi.github.io/detect-collisions/interfaces/BodyOptions.html

BodyOptions is always the last parameter of body creation

you can also change it during runtime

One more thing, I have found sometimes my physics elements get stuck together, sneak through cracks and otherwise get stuck inside walls. This could well be a problem on my end, I'm not really a math guy, but I thought you should know the state of it. I can point you to the code it you are interested.

that is expected

1. you have to handle "pushback"
2. if the "move step" of a body is greater than it allows for stop, then you get what you wrote above
3. think like this, if you want to move 1km and there is a wall in between if you just move 1km it will teleport over the wall or into cracks, what you need to do is know in your app a "max allowed reasonable step" then do this in steps like

const distance = 1_000
const maxStep = 1 // example value, depending on world scale

let left = distance

while (left > 0) {
  const step = Math.min(left, maxStep)
  body.move(step)

  const collided = system.checkOne(body, ({ overlapV: { x, y } }) => {
    body.setPosition(body.x - x, body.y - y)
  })

  if (collided) {
    left = 0
  } else {
    left = Math.max(0, left - step)
  }
}

[Prozi]

Also to take optimization further, not only use
isStatic but also
padding > 0

and

use updateNow = false here
https://github.com/prozi/detect-collisions/?tab=readme-ov-file#step-4-manipulate-bodies

only update after all transformations
body.updateBody(true)