BEPUphysics

Posted: **Fri Mar 11, 2011 11:51 pm**

Hello,

I've made an Updateable that applies Impulses in the UpdateDuringForces(float dt) method. However the dt this method receives is always 0.01666667 (1/60). I'm sure I give my space a dt that I get from GameTime (and it's never 0.01666667). What am I doing wrong?

Also, I created a ForceField with an EntityForceFieldShape. However, None of the objects inside of the entity experience the force. It works perfectly fine with InfiniteForceFieldShape. I do move the entity every step in the UpdateDuringForces method, just before calling the same method from the base class. (This UpdateDuringForces also recieves a dt of 0.01666667, It seems my whole system is running with that value.)

I'm using XNA 4.0 and BEPUphysics 0.14.3

Peter Prins

Posted: **Sat Mar 12, 2011 1:41 am**

I've made an Updateable that applies Impulses in the UpdateDuringForces(float dt) method. However the dt this method receives is always 0.01666667 (1/60). I'm sure I give my space a dt that I get from GameTime (and it's never 0.01666667). What am I doing wrong?

The dt passed into space-updated components is the timestep duration (space.SimulationSettings.TimeStep.TimeStepDuration in v0.14.3, Space.TimeStepSettings.TimeStepDuration in v0.15.0). It's always the same because the engine takes fixed timesteps. If the timestep duration changed every frame, the engine would be less stable.

If you use internal time stepping, the engine will keep up with the elapsed time you pass into the Space.Update method by taking as many timesteps of fixed length as necessary. In v0.14.3 this is done by setting Space.SimulationSettings.TimeStep.UseInternalTimeStepping to true. In v0.15.0, using the Space.Update method that takes an elapsed time automatically causes it to take internal timesteps.

Also, I created a ForceField with an EntityForceFieldShape. However, None of the objects inside of the entity experience the force. It works perfectly fine with InfiniteForceFieldShape. I do move the entity every step in the UpdateDuringForces method, just before calling the same method from the base class.

It may be related to numerical issues freaking out the containment checking system. If the force field shape entity is gigantic, it will have a lot of trouble. There might be some other issues though. I'd probably need a repro case to check on it, though the built-in entity shape for forcefields is gone in v0.15.0. If you can, I'd recommend using a bounding volume-based forcefield shape instead.

There's a BoundingBoxForceFieldShape that can be pretty easily modified into a BoundingSphereForceFieldShape if that's what you need. Here's the source code for it:

Code: Select all

using System.Collections.Generic;
using BEPUphysics.Entities;
using Microsoft.Xna.Framework;

namespace BEPUphysics.ForceFields
{
    /// <summary>
    /// Defines the area in which a force field works using an entity's shape.
    /// </summary>
    public class BoundingBoxForceFieldShape : ForceFieldShape
    {
        private readonly List<Entity> affectedEntities = new List<Entity>();

        /// <summary>
        /// Constructs a new force field shape using a bounding box.
        /// </summary>
        /// <param name="box">Bounding box to use.</param>
        public BoundingBoxForceFieldShape(BoundingBox box)
        {
            BoundingBox = box;
        }

        /// <summary>
        /// Gets or sets the bounding box used by the shape.
        /// </summary>
        public BoundingBox BoundingBox { get; set; }

        /// <summary>
        /// Determines the possibly involved entities.
        /// </summary>
        /// <returns>Possibly involved entities.</returns>
        public override List<Entity> GetPossiblyAffectedEntities()
        {
            affectedEntities.Clear();
            ForceField.Space.BroadPhase.GetEntities(BoundingBox, affectedEntities);
            return affectedEntities;
        }

        /// <summary>
        /// Determines if the entity is affected by the force field.
        /// </summary>
        /// <param name="testEntity">Entity to test.</param>
        /// <returns>Whether the entity is affected.</returns>
        public override bool IsEntityAffected(Entity testEntity)
        {
            return true;
        }
    }
}

Posted: **Sat Mar 12, 2011 5:18 pm**

UseInternalTimeStepping seems to work well.

I also noticed that calling Space.Update(dt); with a dt of 0f crashes the program. It might be better that it just does nothing, because gameTime.ElapsedGameTime.TotalSeconds; is sometimes 0. I fixed it by adding if(dt>0).

I had to change where I use Internal properties and where I use the buffered properties to get it all to work, which made me wonder if I'm doing it right. I use Internal properties for calculating forces, because using the buffered (interpolated) properties makes the forces be applied slightly of-center, causing the objects to spin. This is in the overridden UpdateDuringForces, and for ForceFields CalculateInpulse. For drawing things (or actually only for moving the camera since I still use the Demo's model drawer) I use the buffered properties.

I was also wondering what the difference is between CenterOfMass and CenterPosition?

Yes, the entity I used for the force field is -very- large. (A sphere with radius of 400.) I tried the bounding box and it works.

On the subject of large entities, I understand that the physics system expects objects to be of sizes that lie in the area of a few meters. However, I want to create very large spaceships (sizes around a few 100's of meters). Is there a way to change the settings of the system to accommodate this? I would like not to have to convert my units to strange things like 100m's, 1000000m^3's and 100N's. Also, the same question for mass.

Is there a way to make the Space Not check collisions, and also (for memory efficiency) an Entity that has a Mass and an Inertia tensor, but no shape? Maybe I can do without a spatial subdivision structure as well, in this case.

Thank you.

Peter

Posted: **Sat Mar 12, 2011 10:33 pm**

I also noticed that calling Space.Update(dt); with a dt of 0f crashes the program. It might be better that it just does nothing, because gameTime.ElapsedGameTime.TotalSeconds; is sometimes 0. I fixed it by adding if(dt>0).

That's interesting; apparently it works fine in v0.15.0 though. A Space.TimeStepSettings.TimeStepDuration of 0 will still cause issues of course.

I had to change where I use Internal properties and where I use the buffered properties to get it all to work, which made me wonder if I'm doing it right.

A good rule of thumb is: if it's gameplay logic, use internal properties. If it's just visual, use interpolated properties. In v0.15.0, note that the Position/Orientation etc. properties exposed on the Entity itself are v0.14.3's "Internal" properties, and the interpolated properties can be accessed from within the Entity.BufferedStates property (so long as the Space.BufferedStates manager is enabled).

I was also wondering what the difference is between CenterOfMass and CenterPosition?

CenterOfMass is the location that the object rotates around in v0.14.3. CenterPosition is the center of the shape. This changes in v0.15.0; there is no longer a CenterOfMass property, just a Position property which is what the entity rotates around. Instead of offsetting the center of mass in v0.15.0, it's possible to offset the shape from the position using the LocalPosition in the entity's CollisionInformation.

On the subject of large entities, I understand that the physics system expects objects to be of sizes that lie in the area of a few meters. However, I want to create very large spaceships (sizes around a few 100's of meters). Is there a way to change the settings of the system to accommodate this? I would like not to have to convert my units to strange things like 100m's, 1000000m^3's and 100N's. Also, the same question for mass.

The best way is indeed to choose your units such that the objects in the simulation are of reasonable sizes. However, extremely large space ships may have relatively tiny projectiles as well. In this case, there are still a few options.

Some shapes pairs, like box-box, box-sphere, and sphere-sphere are numerically resilient. Large sizes won't make much of a difference to them. Triangle-convex pairs are also very resilient in the average case, though things colliding with the edges of triangles are a little more difficult when things are gigantic.

If you can restrict the large body interactions to these resilient pair types, then it should work out okay.

Another option is to compose large objects of multiple smaller objects. This is usually desirable for most large objects anyway, since they generally aren't giant boxes and spheres. The CompoundBody can be used for this. Note that a complicated compound body will run faster in v0.15.0 than v0.14.3.

v0.16.0 is also slated to include dynamic triangle meshes with a few other fancy features as well, so it would be possible to use collision mesh to represent the ship.

Mass is much more forgiving than size as far as numerical issues are concerned, especially if you aren't doing any complex stacking or articulated bodies involving the crazy-mass entities. Just avoid going too crazy and it will work fine.

Is there a way to make the Space Not check collisions, and also (for memory efficiency) an Entity that has a Mass and an Inertia tensor, but no shape? Maybe I can do without a spatial subdivision structure as well, in this case.

The CollisionRules of an entity can be changed to make it not collide with anything. Picking a 'personal' rule of NoPair (NoBroadPhase in v0.15.0) will prevent it from generating overlaps with other objects. More information can be found here: http://www.bepu-games.com/BEPUphysics/d ... tation.pdf

Entities do not support having no shape, but in v0.15.0 you can share some simple sphere shape amongst a bunch of uncollidable objects and it will have a similar effect. You can define the mass and inertia tensor manually by using the appropriate constructor.

By the way, v0.15.0 is coming very close to release. Most of the bugs should be gone by now if you'd like to try and use it. It's quite a bit faster and more stable than v0.14.3 in many situations. You can get the latest version here: http://www.bepu-games.com/forums/viewto ... f=9&t=1050

BEPUphysics

Delta Time

Delta Time

Re: Delta Time

Re: Delta Time

Re: Delta Time