Prevent object passing through walls / tunneling (implement CCD) about matter-js HOT 85 OPEN

Any updates?

from matter-js.

from matter-js.

Any progress on implementing CCD

from matter-js.

This really should be completed, considering it's such a big issue, and it's been open for so long.

from matter-js.

from matter-js.

The simplest solution if you need fast moving or thin bodies is to sub-step, it's robust and not all that expensive now and you get higher quality results all round.

You can even dynamically increase your substeps for just a few frames when you detect fast moving bodies, if performance was an issue (and you don't mind possibly inconsistent results, like with a dynamic timestep).

Until I've finished adding substeps as a feature into Matter.Runner (it's a bit tricky to handle all possible framerates, plus a few other things for the general case), here is a very simplified example (that assumes fixed 60fps) to demonstrate:

const delta = 1000 / 60;
const subSteps = 3;
const subDelta = delta / subSteps;

(function run() {
    window.requestAnimationFrame(run);
    for (let i = 0; i < subSteps; i += 1) {
      Engine.update(engine, subDelta);
    }
})();

As well as sub-steps also consider:

• make thin bodies thicker (but can render them thinner similar to this example)
• apply a max speed limit to bodies (e.g. similar to this example)
• avoid large timesteps (<= 16.666ms is recommended)
• ray cast along body velocity and clamp velocity to e.g. 50%

Let me know if that helps - I realise this isn't so obvious unless you're very used to game dev!

from matter-js.

I have a partially working solution in a branch I've not yet pushed, but it still has some major issues. It's a tricky one. Maybe I should push it if other people are interested in helping?

from matter-js.

I'd also like to see the tunneling issues resolved.

from matter-js.

I could look into it, but I can say already that even the 'always' mode is very performant. Though it changes the behaviour of a lot of the demos because the collisions are detected earlier, which causes some things to collapse (the 'dynamic' mode is fine though because it only applies to high speed collisions).

from matter-js.

Unfortunately there were some issues with this initial approach after a bunch of testing. I've got a new approach I'm working on though which should be simpler and more performant too.

from matter-js.

it's already 2021, we are almost in the middle of the year, do we have any progress with CDD ?

from matter-js.

+1

from matter-js.

There seemed to be a hack on Stack Overflow that worked with 0.12.0 and earlier.

from matter-js.

Still experiencing this issue, I guess it's still unsolved?

from matter-js.

In my use case, I managed to work around it by listening to collisionEnd event, check if the bodies were forced out of the viewport. If so, re-position that body to bring it back. (this is good enough for my use case because I only need to make sure no objects can get thrown out of the bounding rectangles.

Hope this helps.

from matter-js.

from matter-js.

Is it not possible to just copy/paste code from a JavaScript port of Box2D like PlanckJS to solve this issue?

from matter-js.

No, switching to box2d is the right move

from matter-js.

No, switching to box2d is the right move

Tried and failed to solve the issue. The problem is critical. I don't know if I should wait or jump ship. The tools and docs in matter.js are so much better than box2d.js.

You could open a PR instead of waiting.

from matter-js.

I switched from using applyForce to setVelocity, fixed the tunneling bug in my app.

        Matter.Body.setVelocity(ball, { x: ball.velocity.x + 20, y: ball.velocity.y - 20 });
        // Matter.Body.applyForce(ball, ball.position, { x: 0.05, y: -0.05 });

from matter-js.

ho am sad, i study the engine full day and i just realize there a big bug in math of this libs !
actuality most of my entities bypass walls ! and seem not easy solution !
why not add a flag like

Engine.create({
		ccdLevel: 1, //force to apply to limited by ccd
	}

from matter-js.

The simplest solution if you need fast moving or thin bodies is to sub-step, it's robust and not all that expensive now and you get higher quality results all round.

You can even dynamically increase your substeps for just a few frames when you detect fast moving bodies, if performance was an issue (and you don't mind possibly inconsistent results, like with a dynamic timestep).

Until I've finished adding substeps as a feature into Matter.Runner (it's a bit tricky to handle all possible framerates, plus a few other things for the general case), here is a very simplified example (that assumes fixed 60fps) to demonstrate:

const delta = 1000 / 60;
const subSteps = 3;
const subDelta = delta / subSteps;

(function run() {
    window.requestAnimationFrame(run);
    for (let i = 0; i < subSteps; i += 1) {
      Engine.update(engine, subDelta);
    }
})();

As well as sub-steps also consider:

• make thin bodies thicker (but can render them thinner similar to this example)
• apply a max speed limit to bodies (e.g. similar to this example)
• avoid large timesteps (<= 16.666ms is recommended)
• ray cast along body velocity and clamp velocity to e.g. 50%

Let me know if that helps - I realise this isn't so obvious unless you're very used to game dev!

Trying to substep like this breaks the outcome by moving the bodies proportional to the number of steps. (If I use 3 substeps I move 3 times as fast.) I think this is maybe because in the body update, I noticed that the time delta doesn't directly influence the velocity, only the acceleration ((body.force.x / body.mass) * deltaTimeSquared), so I tried compensating for this by modifying the "correction" value (which does seem to directly influence the velocity), not used in the sample above, but that just gives me various other problems, like only getting to tiny burst of movement before stopping cold.

Is there a way to use any number of substeps and be sure to see the same position step for one's matter bodies as if no substeps were used at all?

from matter-js.

I just added a poor man's solution to the tunneling problem. It detects if a body is outside the world bounds and then reverses the velocity and translates the body back. I tried via an event. Here is the code. Please have a look.
Events.on(_engine, 'afterTick afterRender', function (event)
{
// avoid tunneling
for (var i = 0; i < _world.bodies.length; i++)
{
var bodyA = _world.bodies[i];
if (bodyA.isStatic || bodyA.isSleeping)
{
continue;
}
var outside = false;
var adjustX = 0;
var adjustY = 0;
var epsilon = 0.01;
if (bodyA.bounds.min.y + epsilon >= _world.bounds.max.y)
{ // bottom
adjustY = Math.abs(bodyA.bounds.max.y - _world.bounds.max.y);
Body.translate(bodyA, {
x: 0,
y: -adjustY
});
bodyA.velocity.y = -1.0;
outside = true;
}
if (bodyA.bounds.max.x - epsilon<= _world.bounds.min.x)
{ // left
bodyA.velocity.x = 1.0;
adjustX = Math.abs(bodyA.bounds.min.x - _world.bounds.min.x);
Body.translate(bodyA, {
x: adjustX,
y: 0
});
outside = true;
}
if (bodyA.bounds.max.y - epsilon <= _world.bounds.min.y)
{ // Top
adjustY = Math.abs(bodyA.bounds.min.y - _world.bounds.min.y);
Body.translate(bodyA, {
x: 0,
y: adjustY // since body.bounds.min.y is negative
});
bodyA.velocity.y = 1.0;
outside = true;
}
if (bodyA.bounds.min.x + epsilon > _world.bounds.max.x)
{ // right
bodyA.velocity.x = -1.0;adjustX = Math.abs(bodyA.bounds.max.x - _world.bounds.max.x);
Body.translate(bodyA, {
x: -adjustX,
y: 0
});
outside = true;
}
if (outside)
{
Bounds.update(bodyA.bounds, bodyA.vertices, bodyA.velocity);
}
}
});

from matter-js.

Thanks for sharing, but does this work?

I ask because body.velocity is technically read only - the engine uses position Verlet meaning velocity is implicit to changes in position (see here)!

So what you need to do instead is simply set the body position to be inside the world, the engine will handle the velocity change for you.

Either way, as you say this is indeed a poor mans solution, as it's only a solution to going outside of the world bounds.

BTW note the event name is not 'afterTick afterRender', those are two separate events (that happen to relate to the same point in the step). You only need to use one here (e.g. it's like jQuery's events), otherwise this will run twice per step.

What we really need implementing is speculative contacts. I'll get round to it at some point hopefully!

from matter-js.

You are right. velocity change is not necessary. Just the translation does it.
I know, it does not work for inside objects, but at least it leaves the bodies at the table.

from matter-js.

+1

from matter-js.

It's a pretty big feature to implement really, I've played around with some ideas for this but I've not yet got much working. It's a tricky one.

I'm considering implementing a simple version for now (ray casting) that should prevent some of the more obvious tunneling cases.

from matter-js.

Ok I totally understand, thank you so much for all your hard work :)

from matter-js.

Note that increasing engine.timing.timeScale can cause this issue as well.

from matter-js.

Still having this issue using latest master as of e698b6b. I have somewhat mitigated it by halving the engine.timing.timeScale value. Not sure of the repercussions of this, but works for my simple use case.

from matter-js.

+1

from matter-js.

@liabru for https://cubeslam.com I ported a few SAT implementations to javascript but finally fell for this brilliant SAT implementation and converted it to be a part of this library.

It's very similar to your implementation but will also project ahead based on the polygons relative velocity to see if it will intersect and then returns a minimum translation vector which may be applied to keep two polygons from colliding if desired.

I found it to be quite stable and fast even in the pace of cube slam. Unfortunately google code just shut down so the implementation code for it is not viewable online anymore. But you can download it and have a look at the narrowphase implementation in lib/sim/physics.js#L74.

from matter-js.

@slaskis I remember playing with cubeslam, awesome project!

Thanks for the info. I actually played with using SAT for continuous collisions but I couldn't get it working at the time, so I'll take a look at your implementation for some pointers.

from matter-js.

@liabru thanks! I hope it can help you get this sweet library even better

from matter-js.

+1 Seeing lots of tunneling with bodies passing through svg generated bodies.

from matter-js.

Is there any workaround for this issue? The proposal from @abataille doesn't work for me.

from matter-js.

Not yet, I have a work in progress implementation. Depending on your needs, you could try doing some ray casts between updates (e.g. between centroids of bodies moving over a certain speed), if there's an intersection then move the body back. This won't be perfect but might help for some cases.

from matter-js.

@liabru would you mind sharing your in progress implementation as a PR or branch? I'm curious what it looks like and maybe we can help out?

from matter-js.

Will this also allow collision with simple lines? To be more specific imagine a force field, which limits you to not pass from both sides but has no thickness.
Which comes to the second idea of force fields coliding only in one direction, so you might move into the forcefield, but not leave it again.
Imagine it as a simple polygon which has only a one-sided face, you walk through it as you cannot see it. If you try to move back you see a wall there.
Used that feature to build some nasty tricky puzzles in prey a while ago, where the back-side was a portal placed inside a door. Which results in a door bringing you from a to b, but the same door back brings you from b to c :D

from matter-js.

@slaskis it is in a very unstable state, I was trying a different approach than using SAT. But it looks like it's not going to be viable, so I'm going to try implement it again in the same way you did. Looking at your code, the key part seems to be these lines right?

from matter-js.

@IceReaper if the implementation was perfect, then yes you could do a super thin body and it should never let anything through. I'm not sure if a practical implementation will be that accurate though, but hopefully.

Either way, for the kind of game mechanics you are talking about, it is better for you to implement that logic directly as it's not really in the scope of a physics engine but rather a game engine. Though once plugins are implemented (#213) you could use them to integrate this.

from matter-js.

@liabru yep, that's the part that uses the velocity to find the possible intersection.

And then the following lines may be useful for knowing how much to "push" the object back to the right side of the polygon.

from matter-js.

I've made some progress on this based on the technique @slaskis mentioned, so far it seems pretty viable. I'll commit it to a branch as soon as it is working well enough.

from matter-js.

I've just pushed my implementation to the ccd branch. If anybody wants to try it then use the build on that branch.

To use continuous collisions then set the body.continuous property to one of these values:

• 0 - disabled (default)
• 1 - dynamic (recommended)
• 2 - always

Where the 'dynamic' setting enables continuous collisions only when required based on velocity.
This provides better performance than 'always' at the cost of slightly softer collisions.
In a collision if either or both bodies have continuous collisions enabled then the check will be made.

See the included Example.continuousCollisions in the demo.

Let me know how you get on if you try it!

from matter-js.

@liabru that looks great, much more readable than my mess. I'll see if I get a chance to try it out this week

from matter-js.

Can we get some performance metrics between the different modes?

from matter-js.

Unfortunately I'm still experiencing a similar issue. Is there any way to cap the velocity of a body to a hard limit? This might be a quick fix for me.

Edit: it just so happens the bodies that they're going through are on the boundary of the canvas, also. Debugging someone else's code right now, not sure if there is another issue at play but figure the velocity cap would be worth trying.

from matter-js.

Yeah you could cap the body velocity in the engine update event quite easily. Either way, the CCD code will get merged soon after I finish work on #213 so you won't need to after that.

from matter-js.

I tried using the new build with the CCD code and setting continuous to 2 on all the bodies, but they're still going through walls / the boundary. The bodies are circles by the way, and the smaller they are the easier it is to get them to escape.

I also tried on engine update checking to see if the velocity is greater than (+/-)20, and if so, capping to (+/-)20, but it's still easy to get them out. Basically if you just click and drag them to the boundary and hold them there, they start spinning and bouncing like crazy and fly out.

There's probably another issue with my build that is causing this issue, but just wanted to let you know. I'd like to get you a case, but right now this is part of a larger framer.js project that I can't share. If I have time to break it out I will.

from matter-js.

I tried using the new build with the CCD code and setting continuous to 2 on all the bodies, but they're still going through walls / the boundary.

What are you doing to cause them to escape? Setting velocity, adding force or using the mouse or constraints? Does the CCD demo work for you? How are the walls constructed?

Basically if you just click and drag them to the boundary and hold them there, they start spinning and bouncing like crazy and fly out.

There are some cases where CCD checks won't always be applied (e.g. things that 'teleport' or force positions, like constraints). Note that also there are no boundary checks, the space is infinite. If this is the case then it may be tricky to fix.

from matter-js.

The walls are Matter.Bodies.rectangle(). I'm using a MouseConstraint to move the circles.

Edit: I just built the CCD demo, and I'm able to just drag the squares through the center rectangle at will not through the outer rectangles. I figured out this is because the squares are both 1) really big and 2) overlapping at the corners. I implemented in my own application, and using the new CCD stuff seems to help (circle's don't exit as often) but it doesn't take it all the way. The walls still have to be really big and overlapping.

So from where I stand the CCD fix isn't really working yet. If someone else want to build the demos and try out the CCD one that would be great.

Thanks again for your help.

from matter-js.

I build the demos and I am also able to drag the little rectangles through the small bar in the middle.
I also managed to get them through by making them really, really fast/applying a lot of force.

I am using this branch for my game at the moment, and regardless of it not working at very, very, very high speeds it is making things much more stable, so this implementation is already a win for me. :)

This is how the demo looks at the start for me.
This is how much I can "drag" it until it gets through.

from matter-js.

Either way, the CCD code will get merged soon after I finish work on #213 so you won't need to after that.

Is it time? :)

from matter-js.

Any update on the ccd merge? I see it has a release-candidate label, that sounds promising!

from matter-js.

Any updates on this issue?

from matter-js.

@liabru can the new approach do with help? Any specific things that'd push it along?

from matter-js.

I have an idea. The object falls through the wall because the hitbox is too small. If the hitbox was bigger it would fix it. The size should be the size to the object + the velocity in that direction. If the object fall down the hitbox should be the size of the object + the y-velocity downwards.

from matter-js.

@liabru Any update on this? It looks like you abandoned the CCD branch and maybe are implementing your new approach in a different branch? Perhaps I can help code it up. I'm trying to make a game for mobile and this is the most performant 2D physics JS library I've found so far. Just need to get this bit fixed.

from matter-js.

Does that solve the problem now?

from matter-js.

I have a similar problem with my project

from matter-js.

@liabru Sounds like that might be a good idea? Along with a brief description of your approach, and of the problems that still need solving might be helpful.

from matter-js.

Is this ever going to be continued?

from matter-js.

I was also wondering about that @qwertyquerty. Any progress on implementing CCD @liabru ?

from matter-js.

Also interested in seeing this feature.

from matter-js.

object passing through walls，I met this problem, too.
I'm really looking forward to the problem being solved

from matter-js.

^^^ Me too

from matter-js.

Is there any way?

from matter-js.

EDIT 2: https://gist.github.com/fabienjuif/a7d9fc3e34e23f6000bcfc185dc0e341

EDIT: I fall into FPS issues, the engine run objects faster on 60FPS than on 30FPS. So don't try that at home :(

I did this trick for now:

  // engine
  // - run the engine several times, so we have the feeling the game is fast
  // - also, this avoid collision detecting issue since CCD is not implemented yet in matter-js
  let lastLoop = Date.now()
  for (let i = 0; i < RERUN; ++i) {
    Engine.update(engine, i === 0 ? delta : (Date.now() - lastLoop))
    lastLoop = Date.now()
  }

And divide all my velocities by the RERUN amount :)
It works, but I assume this is less performant

from matter-js.

+1

from matter-js.

Is there any work in-progress to address tunneling issues?

from matter-js.

Can we throw money at this issue? I'm writing "A Book About Hype" and Hype uses Matter.js as its Physics engine. I was writing about the CCD issue and I realized that I could add a blurb where people can send money to fix this problem. Maybe GitHub sponsors works?

from matter-js.

I switched to Planck.js at last. It worked well, just lack of documentation. Matter is way more intuitive. But this bug is too annoying

from matter-js.

@liabru Helppppppppppp

from matter-js.

@Feavy Something like that, but porting isn't super easy.

from matter-js.

it's kind of amazing to receive updates on this issue like 4 years later, reminding me of where I was in life while working on this. Trump hadn't been elected, it was a simpler time. Anyway it would be great if the maintainer or others could give any ideas or an outline of what a solution might be. seems like it would reduce friction for finding someone to work on it (bounty or not).
…
On Tue, Apr 28, 2020 at 12:04 PM dzcpy @.***> wrote: I switched to Planck.js at last. It worked well, just lack of documentation. Matter is way more intuitive. But this bug is too annoying — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARQDMXKEN4JDXMSR3U3JGLRO35CBANCNFSM4AMWL26A .

So, hopefully most of you guys would choose to jump ship as long as you still can. Don't let yourself sink into despair for another 4 years.

from matter-js.

I ran into this tunneling problem with matter.js and eventually abandoned it in favor of box2d.js and haven't had a problem since. box2d.js's API is less nice because it's directly compiled from C++ using Emscripten but it wasn't hard to switch. Highly recommended.

from matter-js.

Be the change in the world you wish to be, peeps! Any Pull Requests on this issue?

from matter-js.

No, switching to box2d is the right move

Tried and failed to solve the issue. The problem is critical. I don't know if I should wait or jump ship. The tools and docs in matter.js are so much better than box2d.js.

from matter-js.

No, switching to box2d is the right move

Tried and failed to solve the issue. The problem is critical. I don't know if I should wait or jump ship. The tools and docs in matter.js are so much better than box2d.js.

For me box2d works perfectly in my projects. I used Planck.js though. It's true that matter.js's documentation is way better, but I can't get it work

from matter-js.

Same Issue while working with Matter.js in React Native!
Changing the body size and velocity or obstacle thickness does not solve the issue.

from matter-js.

Is there some sort of path tracing collision detection? Say if object A moves from position X to position Y, create a line (X1, X2, Y1, Y2) and check if the line intersects with the object lines? My body seems to be phasing through other bodies despite the speed not being that quick.

Or to be precise, when applying force to a body near to another body it phases through, maybe I have another problem?

from matter-js.

@Anatoly03 see the last point in #5 (comment) about raycasting - to avoid some of the worst cases that approach seems reasonable (especially for user controlled bodies), but generally difficult to make robust. Again I'd strongly recommend using sub-stepping as mentioned in that comment.

from matter-js.

@Anatoly03 see the last point in #5 (comment) about raycasting - to avoid some of the worst cases that approach seems reasonable (especially for user controlled bodies), but generally difficult to make robust. Again I'd strongly recommend using sub-stepping as mentioned in that comment.

Is it possible to creating an extended polygon of the movement by tracing the nodes, then check for objects intersecting this polygon?

from matter-js.

+1

from matter-js.

PR #1254 adds built-in support for sub-stepping (as discussed above) - see the included Example.substep on that branch for an example if you wish to try it out.

from matter-js.