Hi there. GMC member here. I made a thread about how GM's implementation of Box2D sucks. Nobody seemed to agree with me and just simped hard for Box2D for some reason. Anyway, a mod closed the thread because I wasn't positive enough about Box2D's shortcomings. If you are interested, you can read the thread here: https://forum.gamemaker.io/index.php?threads/box2d-is-trash.110450/

Mainly, I want to verify if what one of the poster's said is true. One of the poster's told me that most physics engines have the same issue as this, the issue that everyone discussed in detail the thread. I am wondering is the true, do most physics engines suck like this? Or is that merely hyperbole?

tl dr: In box 2d GM if you add a bunch of walls next to each other and slide a box onto it, you cannot get smooth movement at all, because it randomly collides with interior edges. Someone said most physics engines are like this and I'm wondering if that is true

ReignOnU said:
GMC member here.

I had to look that up. GameMaker Community forums.

ReignOnU said:
One of the poster's told me that most physics engines have the same issue as this, the issue that everyone discussed in detail the thread. I am wondering is the true, do most physics engines suck like this?

Since you're not asking a Physics of math question, this is now moved to the Engines and Middleware forum.

I have not played with Box2D enough to know specifically, but I agree in principle with some of the posts. Any physics system will degrade or “explode” when given bad constraints and properties, that is true.

There is always a tolerance level. If you slide a box through a narrow channel in any physics system, make the channel too narrow, it will snag. When it does, the constraints and properties will determine if the object snags to a stop, bounces out, or violently explodes out of the narrow channel. If you force a big object into a tiny gap, make no allowances for getting stuck or traveling through impassable swept volumes, place a moving object inside of immovable objects, then told the simulator to find a physics response to keep volumes outside of each other, then of course it will be a scenario that looks bad because of the terrible constraints. The solver itself has nothing else it can do, it was placed in a broken scenario and forced to find a solution, and the only good one remaining given the constraints is to shove the object out.

Does that mean the compute engine “sucks”, or does it mean the developer doesn't understand the tools? I think mostly the latter.

@Tom Sloper might be more of a middleware question tbh. here is the math of it though:

https://box2d.org/posts/2020/06/ghost-collisions/​

@frob it is often said that a shoddy craftsman blames their shoddy tools. However, that was said before the 2024 Scamazon age where most tools sold are commonly junk.​

The post says that “However, Box2D only collides with one edge at a time.” This seems like a fail to me, a physics engine built like that might run into problems with that method from the getgo. Then they write that “it is too expensive to perform the point-in-polygon test. Therefore, it seems that smooth collision can only be efficiently and robustly achieved with one-sided edge chains.” which seems like another fail… surely they could just have a toggle switch and allow game devs to flip the chain order in real time? (Its not in the GM manual but maybe they included it in the latest Box2D?)

also the example I used of box2D does not use a narrow channel, it fails in wide open walls

ReignOnU said:
If you are interested, you can read the thread here:

I read your problem was collision discontinuities form assembling a intended flat surface from multiple boxes.

It's quite clear to me why this happens. Some time ago i had the same problem with the Newton physics engine. I have a large mesh to make the world, and wanted to use some chunks of it around the player for physics. I looked into Newtons code to see how it turns given models into static geometry. It merges coplaner faces to remove redundant edges, then builds acceleration structure, etc., as expected.

To achieve the smoothness you talk about, Newton stores adjacent face normals across edges.
So at the boundary of my tiles this information would be missing, the engine would no know about the neighbor surface, and issues as you have described would surely happen. (I did not even try)

To make it work for me, i have added information about adjacent face normals across the boundary.
I also needed to hack Newtons source code, because sadly there was no given way to achieve smooth tiling of chunks. In the end it was not hard to do, but ofc. you can't do things like that when using an engine like Game Maker. You would need source code for game and physics engine, the expertise to implement required changes, and after that you can no longer easily update the engines without a need to implement your changes again.

So what i mean is: Just because you can't make a special case work out of the box, it does not mean the engine is bad. Saying it sucks thus isn't justified, and worse - it's disrespect against the expert people who develop those engines and often give it away for free. I guess that's why responses to your post may have went a bad route (did not read further down).

ReignOnU said:
One of the poster's told me that most physics engines have the same issue as this, the issue that everyone discussed in detail the thread. I am wondering is the true, do most physics engines suck like this?

I can't tell for the specific problem, but accuracy, robustness, but also performance and features vary widely across physics engines. Personally i think some are much better than others, and some are righteous bad but also very widely used.

There were attempts to compare them, but it's hard to do this in a fair way, and backlash and flamewars usually is the only outcome.

Finding the right physics engine for your needs is hard, but still much easier than writing one yourself.

ReignOnU said:
tl dr: In box 2d GM if you add a bunch of walls next to each other and slide a box onto it, you cannot get smooth movement at all, because it randomly collides with interior edges. Someone said most physics engines are like this and I'm wondering if that is true

I do not fully understand, but let's say you compose a flat wall from many boxes, and then dynamic objects collide against internal faces which are not visible.

To solve this, you could use a static mesh instead box primitives, so there are no internal faces causing problems.

Most engines also support round extrusion, so a box can be chamfered. This should help as well if you really want to use boxes or other primitives.

@JoeJ I read your problem was collision discontinuities form assembling a intended flat surface from multiple boxes.

It's quite clear to me why this happens. Some time ago i had the same problem with the Newton physics engine. I have a large mesh to make the world, and wanted to use some chunks of it around the player for physics. I looked into Newtons code to see how it turns given models into static geometry. It merges coplaner faces to remove redundant edges, then builds acceleration structure, etc., as expected.

I think I understand what you are saying. But can you post a picture so I can be 100% sure?

To achieve the smoothness you talk about, Newton stores adjacent face normals across edges.
So at the boundary of my tiles this information would be missing, the engine would no know about the neighbor surface, and issues as you have described would surely happen. (I did not even try)

To make it work for me, i have added information about adjacent face normals across the boundary.
I also needed to hack Newtons source code, because sadly there was no given way to achieve smooth tiling of chunks. In the end it was not hard to do, but ofc. you can't do things like that when using an engine like Game Maker. You would need source code for game and physics engine, the expertise to implement required changes, and after that you can no longer easily update the engines without a need to implement your changes again.

You lost me here. Pics needed

So what i mean is: Just because you can't make a special case work out of the box, it does not mean the engine is bad. Saying it sucks thus isn't justified, and worse - it's disrespect against the expert people who develop those engines and often give it away for free. I guess that's why responses to your post may have went a bad route (did not read further down).

Lost me again. I said Box2D engine sucks and is trash. GM is a commercial paid product for profit product anyway. I don't think they Box2D dev gave it for free, and if they did, they are doing a disservice to humanity. Bootlicking by working for free drags humanity down by making people homeless.

As for disrespect, you should be allowed to disrespect pieces of software, otherwise you enter a trajectory of braveneworldy. And its also part of gaming, Dr. Disrespect is a part of gaming, why should gaming become overly sterilized and everyone has to behave in an overly chatGPT way?

Next step: Ban all non 5 star reviews. People worked hard and they need to feel they accomplished something, can't have anything less than 5 star reviews interrupting our positive community hubris. Do not disrespect the hard work of devs by posting anything less than 5 star reviews. Criticism will not be tolerated.

I can't tell for the specific problem, but accuracy, robustness, but also performance and features vary widely across physics engines. Personally i think some are much better than others, and some are righteous bad but also very widely used.

How does Box2D fare compared to the others?

There were attempts to compare them, but it's hard to do this in a fair way, and backlash and flamewars usually is the only outcome.

Finding the right physics engine for your needs is hard, but still much easier than writing one yourself.

There seems to be too much delusional fanboyish hubris in the game making makerspace. I call it the “junker's fallacy” where people who buy a certain make of car need to irrationally justify their purchase, so they overvalue it compared to other cars. Same happens with DAWs, people who download DAW demos tend to view the DAWs as junk, but someone who spends a lot of money on a DAW will try to make excuses for all the DAWs shortcomings, in order to retroactively justify their purchase.

Still I wonder if had I been more robotic and braveneworldy in my tone and manner of posting, would it maybe not have activated the “fanboy” defensive response? Still, I wouldn't go back and change my behavoir, I'm gonna do it my way or the highway, and I could really care less about yet another series of immature fanboyish responses over the internet lol.

Anyway, I would need to create a “geometry management system” to fix Box2D's shortcomings, and I am not going to do that. And this all would be different if Box2D GM wasn't trash to begin with. For example, before I made the post, Box2D GM had no delta time implementation, making it objectively inferior, which makes the fanboy response even more irritating. It really is junker's fallacy imo. I shouldn't have to create a “geometry management system” in order for Box2D to function, it should automatically just function with arbitrary geometry given. And this is all because Box2D only solves one edge at a time, which automatically makes it not robust.

ReignOnU said:
You lost me here. Pics needed

It's surely irrelevant to your problem, but i have those clusters of triangles, people would call that ‘meshlets’ now i guess:

I want to load only what's currently needed and let the physics engine build it's own geometry and acceleration structures from that as usual.

The problem was that the physics engine - by default - does not know about adjacent clusters with a different color, and the simulation behavior is affected. So i needed t hack it to make it smooth.

ReignOnU said:
Lost me again. I said Box2D engine sucks and is trash. GM is a commercial paid product for profit product anyway.

GM may be paid, but Box2D is free and open source. Most physics engines are.

ReignOnU said:
As for disrespect, you should be allowed to disrespect pieces of software, otherwise you enter a trajectory of braveneworldy.

Agreed, but as i imagine your problem, it's clear it causes problems with any other physics engine too.
But you can post some image or drawing too. Maybe i imagine it wrong and have some idea how to fix it.

ReignOnU said:
How does Box2D fare compared to the others?

Idk, since i've never used any 2D physics engine.

But Erin Catto is very often cited, has very good reputation, and his works have a reference status.
Recently i saw a YT video of him showing various solvers, and what's their strengths and weaknesses.
He's definitively expert on physics. If i would need a 2D engine, i would try Box2D first, and i'm almost certain i would be happy without considering alternatives.

Using GM, you probably can't choose your physics engine. But if you could, i assume you would not find a better one. I guess the way forward is to figure out what to do differently so you can solve your problem while still using GM and Box2D. That's ideal, and i'm optimistic it's possible.

ReignOnU said:
There seems to be too much delusional fanboyish hubris in the game making makerspace.

Yeah, and i assume it will only become worse. That's surely one reason why often rant and show some disrespect. Happens to me too, i assure you. ; )

ReignOnU said:
Anyway, I would need to create a “geometry management system” to fix Box2D's shortcomings

Well, using a game engine, you should not need to do so.

Idk GameMaker, but again - illustrate your problem in more detail, so maybe we can help.

@JoeJ I want to load only what's currently needed and let the physics engine build it's own geometry and acceleration structures from that as usual.

The problem was that the physics engine - by default - does not know about adjacent clusters with a different color, and the simulation behavior is affected. So i needed t hack it to make it smooth.

Still don't understand what the problem is lmao. In that picture, the textures look very pixellated. Are those just textures or individual voxels of the physics engine? I've never seen a physics engine debugdraw that looks like that lol.

GM may be paid, but Box2D is free and open source. Most physics engines are.

So GM is using the most low hanging fruit possible and not even bothering to use a paid physics engine.

Agreed, but as i imagine your problem, it's clear it causes problems with any other physics engine too.
But you can post some image or drawing too. Maybe i imagine it wrong and have some idea how to fix it.

Someone posted that some other physics engines do this too, so I posted that the other physics engines suck too. Then a mod closed a thread and got offended I criticized some physics engines (physics engines that GM doesn't even use.) So I guess it is taboo to insult nonlving, nonhumanoid objects in today's internet.

Anyway, the problem is from Box2D ghosting because it only solves for one edge at a time. As you may already assume, “real life” does not work by solving physics like this, therefore any physics engine that uses a method like that cannot be robust. The problem is Box2D discretely jumps from positions to the next position, then the solver finds that it is already inside a bunch of edges. This is not how real life works at all.

In real life, an object is comprised of uneven molecular surfaces. If one molecule collides with a “fixed” body (such as a heavy concrete wall), then the first molecule to “touch” a concrete molecule begins to move backward sending a signal at the speed of sound of the material, to nearby bonded molecules. This and because the collision is not fully “rigid”, gives enough time for there to be multiple molecules for all intents and purposes colliding with multiple molecules at the same “time”. The object does not magically tunnel through objects and then require complicated IQ decisions to decide what edge it ought to solve for first, it just "does its thing".

Obviously a physics engine cannot really be as realistic as real life simulating every molecule. Instead of that for a physics engine to be robust the solver has to solve for multiple edges at the same time. Otherwise it will have the Box 2D issue where it has to decide what edge to prioritize solving first, and this will cause it to have glitchy collisions where it collides with interior edges.

This is not a niche issue because for any standard game with standard walls, often you will have a sequence of objects next to each other, and Box2D will fail you and make the object collide with it in weird ways… what if someone wanted to make a player collider that runs on walls? Can't because Box2D will make it bounce out of the walls in weird ways, can't make a platformer either unless you make sure there are no adjacent physics objects ever. And what if someone wants to have some dynamic crates? And if putting some crates next to each other while having smooth player movement on them? Can't do that either unless you create some weird geometric management system.

Yeah, and i assume it will only become worse. That's surely one reason why often rant and show some disrespect. Happens to me too, i assure you. ; )

Where are the emotes on here?

(image upload is broken and wont let me downsize)

but yeah. i firmly believe its the “junker's fallacy”, people that invested a lot of time into buggy software need to find a way to justify its shortcomings. any challenge towards the delusions is met with hostility

Idk GameMaker, but again - illustrate your problem in more detail, so maybe we can help.

gif of the issue,

see, it is not niche, any game with connected colinear walls will have this problem. As for devs putting work into the physics engine, yes this is true. But also what about game devs having to put a lot of work into trying to fix somebody else's buggy physics engine lol. and because of that the physics engine may have made people give up or quit making their games. And the GMC was acting like its a niche issue when it isn't at all

i am only applying a northward force to the wall, the bounce is purely from Box2D sucking, as you can see the box is chamfered, the problem still occurs on regular boxes though

ReignOnU said:
Instead of that for a physics engine to be robust the solver has to solve for multiple edges at the same time. Otherwise it will have the Box 2D issue

If you think you know so much better than the creators of these physics engines (most of whom are highly-regarded experts in the field), and that it's so easy to do better, why don't you create your own physics engine from scratch. Should be easy, right?

What you are completely ignoring is practical limitations on what is possible to do within the constraints of a real-time game engine. These are fundamental computational geometry problems, which if you solve efficiently maybe you could get a PhD, publish papers, and become a highly regarded physics engine developer yourself.

To be clear, the problems you see are “user error”, your error, in deciding to not use the built-in method the engine supports to deal with the problem you are seeing. If you want to avoid the interior edge problem it's simple, just don't use multiple boxes to construct your static level geometry. Use line meshes or whatever it is that Box2D provides specifically for this issue.

If you can't do that it seems like you are just here to complain about why the sky isn't red.

@Aressera Could care less. Maybe they have a PhD, citations, more IQ than me. Its irrelevant. I only care about results. And the current results are poor as piss and unfit for game development purposes. Telling me these people have PhDs, accolades, are physics experts changes nothing. It's like if the physics engine is crap it is like this, it is like putting a cherry on top of a dung flavored icecream.

And I mainly know Box2D, for all I know there are other physics engines that do not have this issue. If all physics engines have this issue so be it, maybe there is nobody high iq enough to solve the issue and all physics engines are just trash.