Disable body/collisions temporarily

[Spek]

Silly question maybe, but what is the easy/proper way to deactivate a body? Meaning it causes no collisions, doesn't deliver results for raycasting, and has its body "in rest".

To give a practical example. Say a weapon is laying on the floor, thus with physics and everything. When you pick it up, the weapon is still there, but the physics are deactivated until you drop the weapon again.

I can think of 3 ways, but they all feel a bit dirty:
1. Destroy & Re-create the body when needed
2. Move the body far outside the world (puts its matrix somewhere far away)
3. Assign a special material that can't collide, and should be skipped when raycasting via the pre-filter

[Shaderman]

Hi Spek,

I think

void dgWorld::BodyDisableSimulation(dgBody* const body)

and

void dgWorld::BodyEnableSimulation(dgBody* const body)

could be what you want.

[Spek]

Does those functions match with "NewtonBodyGetSimulationState" / "NewtonBodySetSimulationState" (using the DLL here)? Well, lets give that a try. Thanks!

[Shaderman]

I think they do, because NewtonBodySetSimulationState either calls BodyEnableSimulation or BodyDisableSimulation

[JoeJ]

To disable collisions only, you could use NewtonMaterialSetCollisionCallback.
There is one callback to set when bounding boxes intersect at broadphase, and i use this to prevent further collision processing depending on body user data, like:

int GenericOnAABBOverlap (const NewtonMaterial* material, const NewtonBody* body0, const NewtonBody* body1, int threadIndex)
{
if (BodyGetMyMaterialFromUserData (body0)==0 && BodyGetMyMaterialFromUserData (body1)==0) return 0;
else return 1;
}

I use this to disable collisions between ragdoll feet, but they still collide against other stuff.
For your usecase disabling sim seems the better idea.

[Spek]

Enabling / Disabling the body simulation did the trick
Simple questions with simple answers for a change, Thank you both!

[Schmackbolzen]

I have basically the same issue, but disabling the body also destroys all connected joints. Is there a way to disable/enable all connected bodies including the joints so that it can be completely suspended? That way you can disable all the stuff which is not needed to be simulated at a distance around the player without having to destroy and load all of it again.

[Julio Jerez]

not the engine does not have that functionality. but there is the island call back
void NewtonSetIslandUpdateEvent (const NewtonWorld* const newtonWorld, NewtonIslandUpdate islandUpdate);

this function is call each time the engine build a new island for simulation.
if you set the call back and you return 0, the engine will consider the island sleeping.

and not time will be use until you return true, or the island is change by some even,

for a demonstration, in file ..\applications\demosSandbox\sdkDemos\toolBox\PhysicsUtils.cpp look at functions:

Code: Select all

int PhysicsIslandUpdate (const NewtonWorld* world, const void* islandHandle, int bodyCount)

[Schmackbolzen]

Thanks for the reply. Unfortunately this only reduces computation time by about 30%. If I add lots of objects and disable them all, Newton spends a lot of the time doing nothing. I have experimented with NewtonBodySetSimulationState, NewtonBodySetSleepState and NewtonBodySetFreezeState, but the results did not get any better. Is this a bug in the engine? E.g. 16000 Objects use not disabled around 7ms (a lot of them have zero mass) and with the island method it is around 5ms. So sadly there seems not to be any useful way to disable objects, at least for me.

The idea was to have a grid or similar and only activate certain grid parts with their objects when needed.

[Julio Jerez]

you say 16000 objects.
If the ratio of objects with zero mass to dynamics objects is high, say may few hundred bodies are actually dynamics. then your game is spending lot of time check traversing static collision for objects that do not move.
is this some kind of vegetation terrain where many object are static?
if so, you are using the engine is the worse possible way. The engine has tow special ways to deal wit that.

1- there is the scene collision, when the zero mass object are all bundle in static compound collision.
you can have many scene collision, basically you divide your world into sectors and for each sector you add the collision of these objects, this reduces your world for 15000, to maybe a couple of dozen and you get maybe 100 fold speed up. but you have to do some house keeping. this is my prefect way

2- if your scene there are objects that need to be dynamics, you can use the persistence broadphace. On initiation select that options, and the world will be divided at the root level into two large nodes, one node for the static bodies and the other the dynamics.

Code: Select all

   #define NEWTON_BROADPHASE_DEFAULT                  0
   #define NEWTON_BROADPHASE_PERSINTENT               1
   NewtonSelectBroadphaseAlgorithm (m_scene->GetNewton(), PERSINTENT);


this reduces the tree traversal which is what I believe where the engine is spending the time.

3- this option is using aggregates, but that more a refinement. and is a way to grouping dynamics objects and reducing iteration between them when you know that should no interact.
this is good for thongs like ragdoll, of contraction made of joints. Basically the will get a box around them that will cut check as soon at the are trivially rejected.

I would start by option 2 because is quick, just one line of code.
them I would try option 1, because this is when you will get the biggest bang provided the large majority of the objects are static (zero mass). The 7 or 5 ms will reduce to few 1 or 2 millisecond if any. Some people has successfully placed about one million tress in a terrain using that method.

[Schmackbolzen]

Yes, option 2 really did the trick. Now down to around 1ms. I will try option 1 now, like you suggested. This has really been helpful, thanks! Maybe it would be a good idea to write things like this in the wiki, because sometimes it is not easy to figure out the right way how to do things.

[Julio Jerez]

ha cool, that seemed like a good saving.

if you try option one combined with option two, you will probably cu that time by another half.
Option one will take more work, but is important because is saves you several dozen of megabyte of memory, may hundreds of megabytes which has an indirect effect in memory bandwidth.

finally after you get your scene all set up, you can even get the physics time free. for the view point of the game side. for this you use the NewtonAsyncronousUpdate, you can assign two or three threads and Badabin Badabum the physic free and very much independent of the game complexity.
You can put as many objects as you want.