Do Physics objects ever sleep?

0 favourites
From the Asset Store
Simple yet very life-like rag doll made with Physics!
  • Hi there.

    I started this thread (above) some time ago and had no final answer, but since then the subject of the topic morphed, so I'll start this new thread for anyone interested in the Physics object. Also there is only a handful of posts there, so if you fancy a read and is aiming on helping here, please check it out real quick.

    So this new thread is aiming to discuss the general Physics behavior of "sleeping". To keep it simple, I cannot for the life of me make an object sleep. As you can see from the previous thread there's always jitter and when cheking on debug mode there's always some sort of velocity being attributed to the object, I even checked for general velocity below 1 and then manually set all velocities, including angular, to 0, but still there is NO SLEEP.

    I have had no answer on the part of Scirra regarding which port of Box2d they work so I could investigate further and they don't seem inclined to investigate themselves, yet there is this glaring issue.

    I would love any feedback, I never wished to be wrong more in my life! Just please tell me how you make something sleep in Physics (remember that Framerate Mode must be V-Synched and that higher Gravity augments the jitter as observed through experimentation).

    ps: This is not a hate post, my brain is just melting on this subject and I can't seem to find the help I need. This is out of despair, not anger.

    EDIT: A little gif to showcase further my point. These are all perfect squares with hitbox points in integer values collinding with an immovable Physics object, also with perfect hitbox aligned to an integer grid perfectly, still after setting every velocity to 0 (they would take a LONG time to reach 0 naturally), and as you can see, there's no reason for that object to move, it is still not sleeping. I don't get it! What is the reason of sleeping checking then?

  • Kyatric Sorry to bother, but I need support and I ran out of options a thousand years ago.

    Also this is not a rant, but a cry for help.

    I don't know where else to go about this. I need tools I can trust and a company that supports me. I pay to use Construct and I need to have some sort of safety using it. Physics is a major Plugin, and everything I hear is that the team doesn't fully have it under control nor they have the intention of having it under control, therefore if any bugs arise, they can't do nothing about it, making this major Plugin a blackbox for them and for me as well. I NEED to know which Box2d port you guys are using so I can have control over my work which is heavily dependent on Physics. Worst case scenario you'll never hear from me again on this matter, best case scenario I can help with something, who knows, either way it's a win for you guys.

    I love Construct as much as the next person but this is a nightmare for me. Recently I have used Matter.js, p5.js and dabbled in Unity (poorly I must add, I'm not that good of a dev), but their Physics behave as expected, and as far as I know there isn't a team there saying "oh well... that's just how it is, we can't do anything about it, it's out of our control... This one MAJOR plugin that's been used in thousands of games is incomprehensible for us".

    I don't expect you to do anything about it, but I need something to go on right now, because as I said, I'm out of options here. Is this blackbox gonna be a problem forever?

  • Construct 3 Physics uses the 2.3.1 wasm version of Box2D. The problem you have found is actually a feature of Box2D (at least the javascript version). When using framerate independent time-steps, each time-step is fed into the engine as a delta-time value that is slightly different to the previous delta-time (down to many decimal places). Box2D physics doesn't like that sort of varying time input, and that is why the objects never come to rest when the gravity is large.

  • Colludium This is the first proper explanation of this issue, thanks!

    Do you have plans on porting your Box2D+ addon for C3? Does it have this problem?

  • Colludium OMG, this is a breath of fresh air, thank you so much, please add any insight you may have on the matter, you would help me and the community a whole bunch!

    So this is part of Box2d, that's ok, but can we ever do something about it Ashley? This is an issue I didn't find when trying out other Physics engines (js based even as Matter.js and P5.js) and it's bad, it's not clean, it's not professional, it hurts development of anything that demands polishment.

    When a box, sitting on top of another box, moves, the player knows there's something nasty going on there.

    I'm not saying you have to do it, I'm nobody to say that, but if you tell me (and the community) that Scirra is unable to fix such errors and/or edge cases with its Physics behavior, if you tell us "yes, this is a black box", and let's remember, this is one of your top selling points (who doesn't love working and/or playing with the Physics plugin?) I must say, I love C3, but I must let it go, because this is hurting me like an abusive lover who refuses to improve. I will continue paying and using C3, I love it, but essentially this is not a safe work environment when Scirra has unfixable glaring issues with its bread and butter plugin.

    Hoping for the best, but honestly expecting nothing at this point.

  • dop2000 - You're welcome!

    I went one better than porting Box2D+ - I ported Google's Liquidfun! It has most of the features of Box2D+ but with the added fun of the liquid particles. It's a full technical plugin and is probably best for advanced users who understand Box2D. Here's the forum thread that contains the details.

    Edit: It also has framerate independent engine calling, so you can set the framerate (eg 60 FPS) and it will run at that update rate irrespective of the browser vsync rate. Which means that the engine gets constant delta-time inputs.

  • Colludium I have seen your port and it looks amazing, but what for you is just 25 bucks, for me is 170 (Brasil). Also I'm not saying it's not worth 170 bucks, it possibly is, I just don't have that money in the current situation we are all facing, so I guess I'll wait a bit before making this commitment. Thank you for you work though, I'm definitely not saying no to LFJS.

  • I don't think it's to do with the time step. I thought it was because objects have to come to a complete stop to go to sleep, and due to floating point rounding errors this can take a long time. E.g. at some point it will be moving by 0.0000001 pixels, but that does not count as stopped, so it will continue processing it until it drops all the way off floating point precision and finally hits 0. Again, this is something that's entirely happening within Box2D and is not anything to do with Construct.

  • Ashley So, that means that anything that happens to Box2d you can't do anything about, right? Therefore any Physics problems we have in the future, like we are having now, it's unfixable by you, correct?

    EDIT: What are my options here then? Sit back and relax, and accept these flaws?

  • Why does it matter? Sleeping is an internal optimisation in Box2D to avoid processing objects that aren't doing anything. If Box2D does not make an object sleep, it's because it deems it necessary to continue processing it. It's not a bug or something that needs fixing, it's just part of Box2D's design, and applies equally to the many thousands of games across the industry made in a variety of technologies and frameworks that all use Box2D in one way or another.

    It's better to focus on making a good game than running down the rabbit hole of technical minutiae like this.

  • It matters, because visually objects keep moving when they shouldn't move. As mentioned before, I've tested some basic principles in 3 other engines, 2 of them JS based (Matter.js, P5.js), and this behavior is not present. This is bad visually, bad for polish, undervalues mechanics and visuals.

    It's easier to make a good game when you have a good tool btw.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I don't think that's directly related to the matter of objects sleeping, so I don't think going in this direction will help you.

  • Dude, no direction is helping me, but there's clearly something that is happening to everyone. Noone seems to be able to stop an object fully at any given context or Physics settings. Are you trying to imply that this is just how it is supposed to be? Because I can tell you, it isn't. As I mentioned, I'm a mediocre developer and when I use literally any other engine, they behave accordingly. When something is stopped, it is stopped.

    Perfect squares don't start moving on top of other perfect squares out of nowhere.

    At least can you point me to someone, or somewhere I can go to discuss this further, because you're just not helping at all. You're an amazing developer, but right now you're just sweeping dust under the rug.

  • As mentioned in the other thread you posted, this is something that affects a lot of games that use the Box2D engine. You just have to deal with it with your game design, or try adjusting settings until it's acceptable.

  • Many years ago I made an Angry Birds like demo in C2, and remember having trouble getting the pieces to stop moving. So, I thought I would load that into C3 and see what happens.

    After playing around for a while I got it to work pretty well. I have it dim the brightness of pieces that haven't gone to sleep and have a timer running to show how long it takes for them all to stop moving.

    The first level has 68 physics objects and it takes about 7.5 seconds to get all the pieces to go to sleep. The second level only has 8 objects and they go to sleep in less than half a second.

    You can take a look at what I did here:

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)