# deactivating objects

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

## Recommended Posts

Now i got my physics engine working very well without deactivating bodies but to speed up the engine and to make it more stable i tryed to put in a deactivation step. i made all the bodies that stay inder a certain speed (linear and rotational) for a certain amont of frames get deactivated (put to sleep) and that seems to work. i activate something if after a collision its speed is over a certain threshold, and then after activating that one i search for all the bodies that are touching it and are ontop of it and activate them and keep doing this recursivly. this also seems like it's working. the problem is that sometimes bodies are deactivated on the top of the stack even though the bottom of the stack is still active and then if i hit the bottom the top still stays in the air. how should i fix this? Thanks.

##### Share on other sites
You need a way to reactivate objects before they are involved in physical interaction again. This can be done by determining that something changed about the physical situation of an object: if the object was stacked on top of another, and the object below starts moving, then the friction forces (or even the response force) will change, and so the object deserves to be reactivated.

##### Share on other sites
Instead of not testing anything at all, I usually toss in a sloppy calculation in place of collision.

I try to determine the maximum distance that an object can travel in A seconds, at a rate of Bv. I usually keep A at one second if I'm trying to be accurate. v is the current magnitude of the velocity, and B is usually between 1.6 and 2.5, depending on how quickly I expect things to change. If two objects are far apart enough such that R > (ABvt)1+(ABvt)2, then I don't bother doing finer collisions until the next time. If for some reason the velocity becomes greater than my initial guess Bv, then I recalculate.

It's still doing something, but it's less intensive than constant collision checking, and usually happens every second or two instead of every 2 milliseconds, so there's still an improvement.

If you're in a scenario where you don't have constant forces applied, like gravity, or you have very specific constraints to what you're doing, then things don't need to be nearly as complex.

Basically, I'm taking a guess and saying "what's the soonest anything interesting could happen?" and waiting until almost then before I start testing. Be sure to toss in a few simple checks along the way to make sure your guess is still useful.

##### Share on other sites
Looks like you're missing a simple criterion for activity: if you're stacked in contact with an active object, you should also be activated.

Edit: no, reading again, you are trying to do that. Look at the code that does it, it sounds like there's a bug in there whereby you miss some in-contact objects.

##### Share on other sites
When I disable objects, I keep the contact points of the last frame intact (they are cleared right before collision detection). Each contact has a pointer to the object it was colliding.

Now, when an object at the bottom of the stack is re-activated, it will also re-activate the objects referred by the old contacts (recursively), regardless whether they are colliding or not.

The disadvantage is that you must generate fake contacts at the beginning of the simulation if you have pre-build stacks. This is ok unless the objects are not actually intersecting. Which is a big problem, since it is not easy to line up stacks precisely at design time.
I solved this by slightly upscaling the AABB so it overlaps in most cases and generates fake contacts pointing to each intersecting object.

Anway, the idea is that for each object, you keep a pointer to all other objects that it was colliding with at the moment it was disabled. Be carefull when deleting objects though!

##### Share on other sites
Not sure if it's the same problem - but I definitely had some similar symptoms with my disabling code. The solution I went for was to implement the disabling logic on networks of constrained bodies, rather than individual bodies. So, if a network of constrained bodies are ALL under my motion threshold, then I disable the whole network. If any body in the network is still in motion, I leave the whole network active.

As a side note, the thing I found invaluable in debugging and testing my disabling code was to add some colour coded feedback to the renderer so I could watch my physics solver deactivate and reactivate bodies as I played through the game. It was a real eye opener to see what it was *really* doing in some situations =)

##### Share on other sites
the "network" idea sounds intersting. could you elaborate on that? how do i define the networks? do they have to be predetermined or are the calculated in realtime?
Thanks.

##### Share on other sites
He means a contact group - i.e. after collision detection you go through and make groups of objects that are touching - so if A touches B, and B touches C, but none touches D, then you have two groups: {A, B, C} and {D}.

Then apply the actication/deactivation criteria to the group as a whole.

The disadvantage is that if you have a pile of objects, then just nudging one object on the edge of the pile will tend to activate the whole group - so you can loose some of the performance benefit. Or, if one object refuses to deactivate then that minor problem gets turned into a really big one.

Edit: I did something similar to remdul I think.

##### Share on other sites
Hmm, i'd like to try to implement that method. what kind of algorithm do you use to make the groups? and when do you make them - do you make new ones every frame or do you save them?
Thanks.

1. 1
2. 2
Rutin
22
3. 3
JoeJ
20
4. 4
5. 5

• 27
• 40
• 23
• 13
• 13
• ### Forum Statistics

• Total Topics
631735
• Total Posts
3001940
×