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…

@JoeJ No that is why I had to clarify I only put a northward force next to the wall

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

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

the dev of box2d knows about the issue and demands everyone just use box2d chains (even though the box2d chains are glitchy in GM.) Most people do not know the box2d chains are glitchy also, even I did not know it until after building some large worlds and glitching out of the worlds. Box2d chain glitches are rare so most people do not know of it, you cannot just build a box2d chain expecting to find a glitch.

the exact issue is because box2d's physics method is just to teleport objects around as some sort of discreet physics. So when a box encounters multiple edges, he has to figure out some convoluted high IQ method to decide what edge to prioritize first, so it is not robust. Since when 2 boxes are next to each other the physics engine also thinks the inside edges are valid when inside edges should not be valid. So there is a small chance the physics engine prioritizes solving the inside edges first, thus making the box bounce out of the walls. This could be solved if he didn't rely on solving 1 edge at a time

another way to solve it is if box2d automatically changes static meshes into 1 giant mesh, but GMC expects random GM programmers to do it themselves, its a giant project for game devs to have to do themselves and probably will be buggy and not robust.

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. you'd have to bake non dynamic objects and merge them into 1 object as well, its absurd

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.

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

I am using a chamfered box so it does not do that. It does the regular box behavoir of spinning if a regular box is used.

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

He posted a wall of text about how his physics engine, Box2D sucks and how Box2D chains must be used. and he explains why box2d chains also suck since they are one-sided. Even though there could be a toggle switch to change the winding order of the chains, but I don't see one included in Box2D GM and its not included in Box2D vanilla either afaik

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.

insert laugh emoji

GM has newton support iirc, but its only a dll so it limits you only to PC sadly

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

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

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.

no the player will not know anything most likely the player will just be a casual gamer who doesn't know how the physics engine works. but when the boxes are together and they bounce away 5 feet for no reason they will just get a “vibe” that a trashy physics engine is used for the game, this may influence their overall opinion of the game and will effect the player experience. An example would be: A platformer with a wall and a corner, and the boxes are exactly moved into the corner with no gaps, the player will not expect to bounce up 5 feet when running on the boxes with no gaps nor would they expect it even if the boxes had gaps

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.

@JoeJ Its a box2d issue. Not to bootlick GM too much, but its not GM's responsibilty to create some kind of megamerger utilty for Box2D. Its box2d's fault for picking a method of solving one edge at a time, he should have known that is not going to be robust.

As for the chamfering, yes in Gm Box2D you have to add extra geometry for it. Most physics engines use incorrect terminology. They list it as “chamfer” when they are actually bevels. A chamfer is a 45° angle. A bevel is smooth. Anyway, it presents another problem where now the bevel introduces gaps so you have to stretch the geometry. And it only works with colinear walls/boxes, as you'll see in the next paragraph this makes it unfit for the megamerger utility.

The megamerger utility will be difficult perhaps nearly impossible to make, probably more difficult than importing a new physics engine into GM. Importing a new physics engine to GM will not be easy, GML is a custom language that is similar to C++ but not exactly the same, so it won't be as simple as just copy pasting some scripts. Importing a physics engine to GM will be a gargantuan task requiring a lot of debugging. Anyway, back to the megamerger… a thing nearly impossible (or just impossible) to make because of the following issue:

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

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.

@JoeJ CSG is good and all, but how would I use that for Box2D? Box2D only supports three things: basic shapes. up to 8 vertex polygons, or Box2D chains.

A Box2D chain is simply an array of points that connect together to form a 1 sided chain. Using BSP trees should prove to be futile, GM Box2D only supports Box2D chains.

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.

@JoeJ Missed the two boxes in the middle because i did run out of colors.

How did you run out of colors? MSPaint has lots of colors to choose from including the ability to create custom colors.

But the point is, you need to form multiple shapes,

The shapes you drew will not work, where I draw green, the shapes must be connected as 1 chain or the box will have edge ghosting problems:

Also Box2D chains do not have to be connected loops, but the documentation is unclear so I have to check that

edit: it does appear that you do not need to form a closed loop when defining box2d chains, that may make it somewhat easier