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.

@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

@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.

@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

@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.