ReignOnU said:
gif of the issue,

But there is no issue? It slides smoothly along the wall and does not jump off?

I assume you drag the object with the mouse, and the one or two downward jumps i see come from lifting the object down by intent, and then pushing it back upwards also by intent.

I was thinking you compose the wall from multiple boxes, and the sliding object can bounce off at vertices in undesired ways.

So i'm confused. Please describe the issue once more…

ReignOnU said:
when i am sliding it back and forth on the wall, at no point i push the object down the jumps you see is purely box2d

Ok, but then something strange is going on. This is what i would have expected:

The red box slides to the right, penetrates the walls slightly, detects collision against internal surface, bumps up and starts spinning clockwise.

But yours does not start to spin. It just goes up. So the issue is probably something else.

How do you control the sliding box? Do you apply force or set it's velocity?
Do you have gravity or other external forces?

Physics engines have debug visualization, showing actual collision geometry, contact points and contact forces. Ideally you can enable this in GM. It is the first thing to do if things behave in unexpected ways.

ReignOnU said:
the dev of box2d knows about the issue and demands everyone just use box2d chains

How do you know he knows? Do other people report similar issues?

For me, the first thing i do to test a physics engine is pushing a box against a static wall and see how it behaves.
Most behave badly. The box can sink in, at some point jumps back to recover penetration suddenly, but then the box sinks in again. Often the box also starts to jitter.
In fact, the only engine i have found which behaves well in those cases is Newton.

So that's a normal issue, but your gif looks quite different. The box does nto penetrate or jitter, and no stress is visible. Then it jumps far away from the surface, but still acts smoothly. I have never seen such a behavior, but well, maybe that's just Box2Ds way to show it's limitations.

The solution is usually to apply force instead velocity, so the solver can deal with it.
And the force should be as small as possible.
You might need to check for contacts, or even predict contacts using ray tracing, and reduce the controlling force accordingly.

Or you're creative, e.g. by hiding the jitter behind the force field of a gravity gun, so the force field effect explains the jitter.

In general you really want to be gentle when controlling rigid bodies, which isn't easy.

So yes, unfortunately robustness of those engines is pretty limited. Things do now work as perfectly as we would like or naively assume. If you try to code a physics engine yourself, you would see why this is so hard.

Since we both assume the same reason - ‘internal’ surfaces, here's how rounded / chamfered objects can help:

It dos not prevent the issue, but it might make it more acceptable.

ReignOnU said:
And even if you baked static meshes like this, it would still suck because it doesnt actually fix the problem, for example what if you had a game with dynamic crates and u push them next to each other, your player collisions will still suck.

If the player places boxes manually beside each other, he knows that it's two objects with eventual gaps and sharp edges between. So he won't be surprised or baffled if collisions happen at the gap.

The problem is much worse if the player does not know about the gap.

But well - just to mention.

ReignOnU said:
oh it is the moving box that is chamfered, chamfering the wall boxes would be far too expensive

Actually, chamfering should have no cost at all, even if you did it on both bodies.
E.g. to calculate intersection between a sphere and a capsule, we would calculate the closest distance between a line and a point, then subtract the sum of both radii.
But maybe it's not as simple as i think, or GM / Box2D implements the chamfering with real geometry for some reason, causing a lot of extra polygons.

ReignOnU said:
An example would be: A platformer

Yeah sure. It's not acceptable. I meant for example a game like Portal where players build a stair from stacking up individual crates.

But yes, thinking of making a Super Mario kind of game, i would want to use boxes as well for the platforms. And i agree it sucks that it does not work.
But i would point the finger at GM. It should allow to define a physics boundary for each block, and then it should merge all geometry to form a static mesh without internal faces or redundant vertices.

But idk. how game engines handle physics geometry. I've tried UE5 to see Nanite in action. It was eays to place the rock models, and i also had a 3rd person character running around with zero work. But it could walk through the rocks. : ) I wonder if people need to model low poly colliders manually using game engines.

ReignOnU said:
Good luck getting an algorithm to decide how to make Box2D Chains out of that. Lol

I could do it. Because i never used engines and always had to solve such problems myself :P

Idk what those ‘chains' actually are, but to remove internal faces from a set of non axis aligned 2D convex shapes i would build a BSP tree. The same thing which was used to make Doom levels.

I think i have learned this from Michael Abrashs Graphics Programming Black Book, and iirc. he even provided code examples which surely are still around. It's actually very interesting and not super difficult.

There might be easier ways, but that's what comes to my mind first.

Likely it does not matter if Box2D or GM should do this for you. If neither does, doing it yourself seems the only option.

ReignOnU said:
They list it as “chamfer” when they are actually bevels. A chamfer is a 45° angle. A bevel is smooth.

Good to know. So i have meant ‘bevels’ then. : )

EDIT:

I was just googling for ‘open source CSG 2D library’. Many results!
Probably you can find and use one of those. What you want is in other words a 'union', which is a primary CSG operation.

ReignOnU said:
Box2D chains.

I've looked it up. It's basically a arbitrary polygon, and the ‘ghost’ tells the adjacent edge, similar to how i needed to give adjacent face normals to Newton.

The polygon can have any shape - convex or concave. So that's what you need actually.

I draw some example outlines, where each color means one chain shape:

Missed the two boxes in the middle because i did run out of colors.
But the point is, you need to form multiple shapes, connecting polygons with shared edges, but disconnecting separated polygons.
You also need to remove redundant vertices dividing a straight line i guess.

But then it should work i think.

Btw, you have some cases where polygons meet at a single vertex, but do not share an edge.
I assume this would still cause problems. This often causes problems for many algorithms. One issue is that it's not clear if the two shapes are connected or not, but almost always it works better to treat them as disconnected, which i did and thus i end up with multiple shapes.

Beside technical reasons, it's also recommended to avoid this for aesthetical reasons. In art there is a name for this flaw, but i forgot it. However, they say it should be avoided because it always looks bad. (No joke - i was at some art school.)

So if you can, avoid it by design, i would say.

Generating a BSP tree from the scene makes it easy to extract those boundary cycles robustly. It would also work of some of the polygons overlap, for example. (BSP is often used to implement CSG)
But i also feel it's a bit of overkill for your case eventually.
Maybe it's enough to generate a graph data structure, connecting polygons with coplanar edges. Then color them with flood fill to form colored islands. Then trace the outline per island.