Weird Physics Behaviors.

Hi guys, so Im working on redesigning a game I built a while back using a different engine. Its kind of based on a pool table. So anyway I have most things working really well, But the physics engine just wont work for me. I have the "pool Ball" set to a circle collision shape inside of the physics, and the same with the other static shapes on the table. I have all of the settings within bounds (meaning no crazy densities (all are 1 for the time beings) or anything of the sort). The problem is this, the engine detects collisions when the objects are just close, not touching.. close.. It seems to be around a 6-10 pixel difference. I have the sprites trimmed down to the pixel, so if its using that to guess the shape, it should be the right size. Any ideas on whats going on here? Ive tried bullet, no bullet, just about everything I can think of and have no luck. Its a bummer because with this game I need that to be as precise as possible.. And it worked on other engines just fine. Thanks for any and all help guys!

Have you tried "Set stepping iterations" with some big numbers like 60/60?

If nothing helps, you can probably use invisible sprites with Physics, and pin visible ball sprites to them which are a few pixels larger.

Have you tried "Set stepping iterations" with some big numbers like 60/60?

If nothing helps, you can probably use invisible sprites with Physics, and pin visible ball sprites to them which are a few pixels larger.

Hey! I tried and it helped a bit, but the problem was still there. And Id totally make my own hitbox if it was consistent. unfortunately changing the sprite size and pinning another sprite on top doesnt work because its not a constant distance that triggers it. It kind of jumps around. Always close, but not the same everytime. Thanks for the help though, I appreciate it!

In C2 you can try Chipmunk physics, it may work better. Unfortunately, there is no alternative to Box2D in Construct 3.

The problem is this, the engine detects collisions when the objects are just close, not touching.. close.. It seems to be around a 6-10 pixel difference.

I would guess the object image doesn't line up exactly with the collision mask.

> The problem is this, the engine detects collisions when the objects are just close, not touching.. close.. It seems to be around a 6-10 pixel difference.

I would guess the object image doesn't line up exactly with the collision mask.

I kind of thought that too, but thats not what seems to be causing the problem. Its not a consistent thing. If it was the mask it would be the same distance every time, but it varies pretty strong across the board. also, i have them trigger events.. and sometimes the event will trigger while the ball is still moving towards the bumper, meaning its detecting the collision before if happens somehow.

In C2 you can try Chipmunk physics, it may work better. Unfortunately, there is no alternative to Box2D in Construct 3.

Sadly, Im on linux, so C2 is out, even though I do own it. Whats weird is the other engine I used was using Box2d as well. So it seems like it should work. Im at such a loss. I might have to use something else for this project sadly.

Can you post a small project demonstrating the issue, maybe there is some simple thing you've overlooked?

Hey! I believe I fixed it. Im not sure exactly whats going on, but its tied to the collision mask inside of the sprite. So I assumed that when you set the circle mask within the physics behavior that it just used the bounding box as a baseline for the circle(thats how other engines Ive used have handled it), but it seems that might not be the case. Construct assigned rather wonky looking masks inside the sprite editor to my sprites and I believe it was making the circles lopsided/ or at least not line up with the sprite correctly. And without being able to see the mask, there was no way to know... it worked well if the sprite was rotated to a side that was lined up well, but maybe was jutting out on the other side, hence the seemingly random collisions that made no sense. Im not sure, thats just my guess... Maybe someone with more knowledge can back me up, or explain it. Either way, it seems to be working now. And Im stoked for it haha. I was dreading starting again from scratch on another engine. Thanks so much for all the help!

If the Physics collision mask is "circle" or "bounding box", it ignores the collision polygon, as described in the documentation, e.g.:

Circle ignores the object's collision polygon if any, and for the purposes of Physics collisions considers the object to be a circle.

That's interesting, because changing the masks inside of the Sprite completely fixed the issue. So it still interacts with the physics somehow. Not sure if it's a bug, or if it's part of the system, but either way, changing them stopped the collisions from happening early and made the physics much more accurate.

Circle ignores the object's collision polygon if any, and for the purposes of Physics collisions considers the object to be a circle.

That doesn't really tell us that much. Where exactly is this circle, how is it calculated? Does it use the bounding box then does the math to figure out the radius ( 1/2 of the width of the bounding box for example )? Or is it something else?

> Circle ignores the object's collision polygon if any, and for the purposes of Physics collisions considers the object to be a circle.

That doesn't really tell us that much. Where exactly is this circle, how is it calculated? Does it use the bounding box then does the math to figure out the radius ( 1/2 of the width of the bounding box for example )? Or is it something else?

Yeah, Im not really sure. I just know taking my sprites from weird collision shapes inside the sprite editor to ones that more closely fit the sprite fixed the issue for me. So there is some link to the collision mask inside the sprite. I changed nothing else but that, and it fixed it somehow. This is all while using the circle hitbox in the physics engine. My guess would also be that maybe some logic uses the physics box, and some uses the sprite box. Like interacting with physics objects uses the physics one, but the collides with rules still use the sprite hitbox. Im not too sure yet.

Do you have any non-physics collision/overlapping checks in your code? Something like "Ball On collision -> set velocity..."?

Or any other behaviors not compatible with Physics (8-direction, pin, bullet etc.)?

Do you have any non-physics collision/overlapping checks in your code? Something like "Ball On collision -> set velocity..."?

Or any other behaviors not compatible with Physics (8-direction, pin, bullet etc.)?

Nope, The only things are some random collision checks for scoring etc. I got it figured out, just not sure why its working the way it does. Thanks for the help!