Compound body problems

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
Peter Prins
Posts: 54
Joined: Fri Mar 11, 2011 11:44 pm

Compound body problems

Post by Peter Prins »

I have an object that consists of a CompoundBody cb_a, which has two children; another CompoundBody cb_b, and a ConvexHull ch_a. cb_b has one child; another ConvexHull cb_b.

I have two problems with this entity. Firstly the buffered CenterOfGravity of ch_b is not in the correct position, and is very jittery. Secondly, using the code from the demo to draw the entities results in ch_a not being drawn in the correct location. Rather it seems to be drawn at cb_a's location.

I'm using version 0.14.3.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Compound body problems

Post by Norbo »

In v0.14.3, sub entities will not have meaningful values in all of their properties. They are not actually in the world as entities; they just donate their collision shape to the compound basically. There may be other issues that I cannot guess given that information as well.

I would recommend updating to v0.15.0+ or possibly even the v0.16.0 development version: http://bepuphysics.codeplex.com/SourceC ... evelopment

In the latest versions and especially the development version, compound bodies have a much clearer organization. A CompoundBody (the entity) has a CompoundShape which has other shapes in it, not other entities.
Peter Prins
Posts: 54
Joined: Fri Mar 11, 2011 11:44 pm

Re: Compound body problems

Post by Peter Prins »

I'm trying to update to 0.15.2 now, however, I have some problems with this. Where could I find a piece of example code on how to construct entities in this version? Also I would like to use the drawing code form the demos for debugging but I don't know where the source code for this is on the new site.

I would like to suggest integrating the drawing possibilities of the demo into the system in such a way that I don't have to update the entire code for drawing every time I update to a newer version. I know a lot of this is already contained in the BEPUphysicsDrawer.ddl, but there is still a lot of code that I need to copy from the demo to my own project. Also, with the current way it works I have to add extra code to the creation of entities to make sure they are drawn. It would be nice if this were done automatically when I add the entity to the space.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Compound body problems

Post by Norbo »

Where could I find a piece of example code on how to construct entities in this version?
The development version has a comprehensive EntityConstructionDemo: http://bepuphysics.codeplex.com/SourceC ... evelopment

All the old entities like Box, Sphere, etc. are still available too.

The source downloads also include the BEPUphysicsDemos and BEPUphysicsDrawer (basically the set of projects I use to develop BEPUphysics).
Also, with the current way it works I have to add extra code to the creation of entities to make sure they are drawn. It would be nice if this were done automatically when I add the entity to the space.
The easiest way to do this is to either make your own function which adds an entity to both the space and the drawer simultaneously, or do what the demos do- loop through the entities after the initialization phase and put them all in at once.

The drawer will not be tightly integrated into the physics engine itself; the drawer is just a secondary testing/debug project and I'd rather keep the physics engine responsible for only physics.
Peter Prins
Posts: 54
Joined: Fri Mar 11, 2011 11:44 pm

Re: Compound body problems

Post by Peter Prins »

The drawer will not be tightly integrated into the physics engine itself; the drawer is just a secondary testing/debug project and I'd rather keep the physics engine responsible for only physics.
Would you consider at least separating the drawing component of the DemosGame class into a separate class? That way users don't have to do that separation themselves with every update, if they want to use the BEPUphysicsDrawer in their own project.

Also, I'm trying to update the following lines of code from v0.14.3 to v0.15.2

Code: Select all

Space.SimulationSettings.CollisionResponse.StaticFrictionVelocityThreshold = .5f;
            
Space.SimulationSettings.TimeStep.UseInternalTimeStepping = true;
Space.SimulationSettings.TimeStep.TimeStepCountPerFrameMaximum = 3;

Space.UseMultithreadedUpdate = true;
I already found Space.TimeStepSettings.TimeStepCountPerFrameMaximum, however, every subsystem also seems to have a TimeStepSettings. Is there a point to using different settings for these?

Space.AddToRemovalList does not seem to exist anymore. Does Space.Remove use automatic Buffering or should I do this myself?

I have some problems with the ForceField. I used to override UpdateDuringForces, so that I could do some pre-calculations and possibly even change the ForceField's shape. Is there a way to do this in the new setup?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Compound body problems

Post by Norbo »

Would you consider at least separating the drawing component of the DemosGame class into a separate class? That way users don't have to do that separation themselves with every update, if they want to use the BEPUphysicsDrawer in their own project.
I'm not sure exactly what this refers to. The links to the BEPUphysicsDrawer in the DemosGame are:

Code: Select all

ConstraintDrawer.Update();
ModelDrawer.Update();
in the update, and:

Code: Select all

if (displayEntities)
    ModelDrawer.Draw(Camera.ViewMatrix, Camera.ProjectionMatrix);
if (displayConstraints)
    ConstraintDrawer.Draw(Camera.ViewMatrix, Camera.ProjectionMatrix);
in the draw.

If you mean the contact point/bounding box drawing stuff, I suppose I could pull that into a BEPUphysicsDrawer helper class or something. That section isn't required to use the rest of the drawer, though.
Space.SimulationSettings.CollisionResponse.StaticFrictionVelocityThreshold
This is now CollisionResponseSettings.StaticFrictionVelocityThreshold.
Space.SimulationSettings.TimeStep.UseInternalTimeStepping = true;
Passing a time into the Space.Update method automatically uses internal time stepping. Not passing a time into the Space.Update method performs a single time step.
Space.UseMultithreadedUpdate = true;
This is also automatic now. If the ThreadManager has more than 1 thread, then multithreading is used. Individual stages also have an AllowMultithreading property which you can set to false if you want them to run sequentially still.
every subsystem also seems to have a TimeStepSettings. Is there a point to using different settings for these?
By default, the TimeStepSettings object used by the Space is shared amongst the Space processing stages. Changing values in one changes values in all of them. Each stage has its own property because the processing stages can be used independently from the Space. Basically, the Space is 'glue' that binds a complete set of stages together, but users can choose to pick and choose if they desire.
Space.AddToRemovalList does not seem to exist anymore. Does Space.Remove use automatic Buffering or should I do this myself?
Space.Remove does not buffer. There is a Space.SpaceObjectBuffer that can be used to do something similar. Note that it updates at the beginning of each time step, so removals performed in the middle of a frame will not take effect until the beginning of the subsequent time step. If that is insufficient, then a custom solution would need to be used.
I used to override UpdateDuringForces, so that I could do some pre-calculations and possibly even change the ForceField's shape. Is there a way to do this in the new setup?
The ForceField class is pretty simple, so you could modify it if you wanted. I'll toss in a virtual PreUpdate method for the next development version. Alternatively, you could perform the same operations externally.
Kataan
Posts: 10
Joined: Tue Mar 22, 2011 10:57 am

Re: Compound body problems

Post by Kataan »

If you mean the contact point/bounding box drawing stuff, I suppose I could pull that into a BEPUphysicsDrawer helper class or something.
Keep it lean and mean! If we need to add bounding boxes we can, its not that much effort.

And there is always the option of a wrapper class if someone really wants that functionality and wants to hide it away.
Peter Prins
Posts: 54
Joined: Fri Mar 11, 2011 11:44 pm

Re: Compound body problems

Post by Peter Prins »

If you mean the contact point/bounding box drawing stuff, I suppose I could pull that into a BEPUphysicsDrawer helper class or something. That section isn't required to use the rest of the drawer, though.
Yes, that would be nice.

I'm almost done upgrading to v0.15.2, but I still have one problem. I have a class that implements the IDuringForcesUpdateable interface. In the Update method I use ApplyImpulse to apply a linear impulse to an entity. However, I cannot find the method to apply angular impulse.

Also, for some reason, if I look up the value of AngularMomentum it has a value of <NaN, NaN, NaN>. Also the InertiaTensor is filled with NaN. Could this have something to do with the fact that I set the InertiaTensor to {0, 0, 0} {0, 0, 0} {0, 0, 0,0001741448}? (I do this to make it so the object only rotates around the Z axis.)
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Compound body problems

Post by Norbo »

In the Update method I use ApplyImpulse to apply a linear impulse to an entity. However, I cannot find the method to apply angular impulse.
ApplyImpulse applies an impulse at a location in world space which then changes both the linear and angular momentum of the entity. To change only one of the two, it's best to set the LinearMomentum or AngularMomentum properties (or LinearVelocity and AngularVelocity, if that is more natural for the problem).
Also, for some reason, if I look up the value of AngularMomentum it has a value of <NaN, NaN, NaN>. Also the InertiaTensor is filled with NaN. Could this have something to do with the fact that I set the InertiaTensor to {0, 0, 0} {0, 0, 0} {0, 0, 0,0001741448}? (I do this to make it so the object only rotates around the Z axis.)
Make sure the LocalInertiaTensorInverse is being set and not the LocalInertiaTensor. Setting the non-inverse to something near the zero matrix will cause NaN's.
Peter Prins
Posts: 54
Joined: Fri Mar 11, 2011 11:44 pm

Re: Compound body problems

Post by Peter Prins »

That is actually the one I'm setting. The code is:

Code: Select all

entity.LocalInertiaTensorInverse = new Matrix3X3(
            0, 0, 0,
            0, 0, 0,
            0, 0, entity.LocalInertiaTensorInverse.M33);
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Compound body problems

Post by Norbo »

On second glance, getting NaN's in the read value for angular momentum and LocalInertiaTensor is expected given that value. The simulation will still function as expected, though. AngularMomentum will still be settable.

The NaN's will not infect the rest of the simulation under normal conditions because the inertia tensor inverse is the one used in actual calculations.
Peter Prins
Posts: 54
Joined: Fri Mar 11, 2011 11:44 pm

Re: Compound body problems

Post by Peter Prins »

If I want to apply an impulse I would normally do this:

Code: Select all

entity.AngularMomentum += impulse;
However, since AngularMomentum contains NaNs its values will remain NaNs, so nothing changes. Moreover, The angular velocity is updated as well, propagating the NaNs to the angular velocity, causing the physics engine to crash.

By the way, in v0.14.3 I never had problems with this. The line of code I used to apply the impulse was this:

Code: Select all

entity.ApplyAngularImpulse(impulse);
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Compound body problems

Post by Norbo »

I've updated the development version to improve infinite inertia handling: http://bepuphysics.codeplex.com/SourceC ... evelopment

While the NaN's were 'correct,' the new version inverts the inertia tensors adaptively and finds the largest relevant nonsingular submatrix. The result is that the AngularMomentum/(Local)InertiaTensor will no longer show NaN's, but instead 0's for the restricted elements. This isn't physically 'correct', but it avoids having to work around floating point special case numbers, and infinities are hard to fit into physics anyway :) The nonrestricted elements in the inertia tensor and momentum will be correct (instead of also NaN).

Conservation of angular momentum (MotionSettings.ConserveAngularMomentum) still can't be used with infinite inertia tensors, though. It's off by default and has never worked with infinite inertia 'correctly', but it's something to keep in mind.
Post Reply