Jump to content
  • Advertisement
Sign in to follow this  
earl

Sleeping bodies

This topic is 3017 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm just in the final stages of building a relatively light-weight, iterative solver based 2D physics engine for my current project, and have been experimenting with how to handle deactivating and reactivating bodies in the simulation.

If each body is handled in isolation, you potentially end up with objects in a stack falling through the bottom object because it went to sleep first, or at least, causing it to wake up again. The stack will now also jitter whenever a body tries to sleep.

What are the options to deal with sleeping rigid bodies?

I would like to avoid islands if possible, as I feel they are a little heavy for my needs. The only other method I've seen is to use cells in a uniform grid to sleep all stationary bodies within the cell at the same time, but I'm not sure about the details - for example, are neighbouring cells considered in any way?

Aside from the 2 methods mentioned above, I came up with the idea of 'synchronized sleeping', by which I mean, not putting bodies to sleep as soon as they remain stationary for some threshold of time, but instead waiting until the next sync frame, such that a whole cluster of bodies can be put to sleep on exactly the same frame. The longer the sync period, the bigger the groups of bodies that can be in contact, as they have a longer chance to settle. This is not so good for waking bodies up however, as you can't wait for a sync frame, so waking a single body will cause a number of frames to pass before a whole stack is awake. This allows the stack to crumple a little before the floor pushes back. One possibility I just thought of is to record which bodies fall asleep on each sync frame, then to wake the whole sync group up when any one of them wakes, but is this becoming as expensive as 'islands', but without the added benefit they give in terms of early out constraint resolution?

What are the merits of the above methods? Do you think my 'synchronized sleeping' technique will provide any benefit over the other methods? Also, are there any methods that I haven't considered? I know, I know, profile them and pick the winner - but at this stage, I'd like to discuss it from a higher level design aspect.

Also, does anyone have any more details on the uniform grid method for sleeping bodies. I tried to follow the implementation in 'nape', but found it quite hard to follow. Thanks.

Share this post


Link to post
Share on other sites
Advertisement
Hi, the uniform grid method is something i came up with myself a couple years ago which i re-implemented in nape.

What follows is a rough off the top of my head attempt to explain the processes involved:

----

Essentialy, each grid cell is put to sleep when all of it's constituent objects are at rest (with a frame-delay to stop cells being woken/put to sleep constantly and to prevent the fatal situation of an object being thrown into the air and then sticking in the air because it came to rest :P).

When a cell is put to sleep, all of it's objects are put to sleep aswell given that the object has not been marked by a live cell previously in this step aswell as any related arbiters. In continuing to iterate the live cells, it's possible that some objects put to sleep will be awoken again as they also reside inside of a live cell.

In effect, an object is only put to sleep if it resides in cells which are all sleeping. And also as a result it's possible for an object in a sleeping cell to be awake and mixed with sleeping objects. Due to the nature of the grid sleep, what is guaranteed is this non sleeping body is at rest, however it still needs to interact with the sleeping bodies in it's cells so that it doesn't fall through them.

When an object is put to sleep it's inverse mass and moment of inertia are cached and in the contact calculations the cached values are used for computations so that the calculated impulses do not suddenly change, and the actual values which become zero when an object is put to sleep are used when applying the impulses to the body, so that sleeping bodies receive no impulse.

when arbiters are put to sleep, it's contacts remain with their cached impulses, and when awoken each contact has it's time stamp renewed so that the cached values that persisted from when it was put to sleep remain true and are used again straight away which prevents jittering when objects re-awaken and stops the sleeping becoming unstable.

in terms of cells being reawoken; this happens naturally with a cell being awoken whenever a new object is entered into it which necessarigly must not be at rest as it had to move to enter the cell, or when one of the non-sleeping objects within a sleeping cell loses it's state of rest.

What results is the 'partial' sleeping which occurs with this process where a large pile of objects can have part of the pile sleeping whilst part is awake, with shocks propogating through the pile and awakeneing sleeping parts with larger shocks propogating further and causing more of the pile to reawaken.

----

Really though, it's probably easier if you wanted to implement this to use the source which if you're using the real source as opposed to the compiled haxe code, is about as long as my explanation above!

:P good luck.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!