Physics time step ?

Dec 4, 2011 at 9:17 PM
Edited Dec 4, 2011 at 10:17 PM

Will it be possible to fix the update rate of the physics ?

I'm working with :

            Graphics.SynchronizeWithVerticalRetrace = false;
            IsFixedTimeStep = false;

 

( The game won't be released with this fps but I like to work and always check the fps )

 And with a fps of about 500 the physics doesn't work correctly.
The possibility to handle the update frequency of managers would be apreciated !

Thank you !

 

Other little question :

On the blog of bepu I've read :

Stripped Down Character
Sometimes, you don't want your character to be a sphere. Cylinders, capsules or boxes are typically a better fit for a standing bipedal form.
In this case, you probably also don't want them falling over.
This can be addressed by setting the local inertia tensor inverse of an entity to all zeroes, which is equivalent to having infinite inertia.

 So I've tried to do this in the sceneobject representing the player :

 Collision = new Indiefreaks.Xna.Physics.Entities.BoxCollisionMove(this);
 collision.Entity.InertiaTensor = new Matrix3X3(float.PositiveInfinity, float.PositiveInfinity, float.PositiveInfinity,
float.PositiveInfinity, float.PositiveInfinity, float.PositiveInfinity,
float.PositiveInfinity, float.PositiveInfinity, float.PositiveInfinity);
It's not possible to set the inverse inertia tensor, so I tried with infinity but it doesn't seem to work : I can make my character rolling.
If someone has any idea... 
Coordinator
Dec 6, 2011 at 7:31 AM

I don't think there is an easy way to achieve the manager's update frequency since they're all called by the SceneInterface instance.

Moreover, if you are getting weird physics, try asking the question on BEPUPhysics forums since other guys may have related issues. Note that BEPUPhysics Space core class has an Update method which asks for the currently elapsed time thus, I suppose the physics are computed using delta time:
            Space.Update((float) gameTime.ElapsedGameTime.TotalMilliseconds);

On your StrippedDown Character, I don't have the time right now to look deeply into it but maybe you could consider creating your own BoxCollisionMove instance inheriting from BEPUEntityCollisionMove and setting on the constructor the LocalIntertiaTensor you want. Have a look at the BoxCollisionMove class in source code to see how to create your own Entity based CollisionMove ;)

Good luck

Dec 10, 2011 at 2:54 AM
Edited Dec 10, 2011 at 2:55 AM

Hey guys! Norbo from BEPU here :)

The property you should set to all zeroes to avoid rotation is the LocalInertiaTensorInverse.  Setting entity.LocalInertiaTensorInverse = new Matrix3X3(); would do the trick.

The entity.InertiaTensor was settable for obscure, rare, and fairly bad reasons.  I went ahead and removed the setter for that property in v1.1.0 to avoid future confusion.

BEPUphysics supports internal timestepping.  If you use the Space.Update(dt) method (as opposed to the parameterless Space.Update()), it is performing internal time stepping.  This means it accumulates the time provided in the parameter and takes possibly multiple steps of length Space.TimeStepSettings.TimeStepDuration to get as close as possible to 0 accumulated time.  There is always some time left over, though.  For smooth movement when using internal time stepping, you may need to use the interpolation systems in BEPUphysics.  More information is available in the Updating Asynchronously documentation.  Note that you don't need to be updating asynchronously to make use of internal time stepping and interpolation- it's just a common use case.

The parameterless Space.Update() method, in constrast, just performs a single full time step.  If your game's update rate is fixed, you can just use that method and avoid internal time stepping.

Note that the default Space.TimeStepSettings.TimeStepDuration is 1/60f.  Passing in the elapsed time in milliseconds with such a value will cause the simulation to run 1000x too fast- using a whole lot of resources in doing so. 

Coordinator
Dec 10, 2011 at 8:35 PM

Thanks Norbo to make an apparition here ;)

I'm using the delta based Space.Update() method call in the framework which was, from my point of view the best choice for developers since I thought they could use internal stepping or not.

Maybe my assumption was wrong and I should add a small property to my BEPUPhysics Space wrapper to let the developer choose between fixed timestep or not? What would be your advice for an open choiced API?

Dec 11, 2011 at 1:52 AM
Edited Dec 11, 2011 at 1:53 AM

It might be a good idea to offer a property to activate/deactivate internal time stepping.  Using internal time stepping without the buffers works fine from a stability and physics standpoint, but if the interpolation buffers (or an equivalent process) are not used, the ever-so-slight graphical jumpiness will show up.

One possibility is to wrap the complexity of internal time stepping fully.  If the "UseInternalTimeStepping" property (or whatever it's called) were true, then Space.Update(dt) should be called and the Space's interpolation buffers should be enabled.  While the interpolation buffers are enabled, anything graphical referring to entity position and orientation should make use of the values in the buffer instead of the entity's direct properties.

You can get the states on a per-entity basis by using Entity.BufferedStates.InterpolatedStates.  If the interpolation buffers are off, the properties will fall through to the usual Entity.Position and Entity.Orientation properties.

There are some complexities to consider though.  Interpolated values are not 'true' values that reflect the current simulation state, but rather an arbitrary smoothing system for graphics.  If a user wishes to create a system which relies on the true, uninterpolated states, they would need to go through the entity's direct properties.

I would guess that defaulting the property to using the Space.Update() without internal time stepping would be a good idea.  Game.IsFixedTimeStep set to true while running a single time step of fixed length each update is probably easier for most users to understand at first.

Coordinator
Dec 11, 2011 at 8:17 AM

I'll have a look at it further on. For next release, I'll simply add the property and call one or the other Update() signature depending on developer's choice. For v1, I'll have a deeper look and see if I can come up with something better and automated to expose interpolation buffer properties to the game entities whenever they make sense.

Thanks again

Coordinator
Dec 11, 2011 at 11:26 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Dec 11, 2011 at 4:35 PM
Edited Dec 11, 2011 at 4:54 PM

Thank you guys.

In fact my problem was in part because of another bug :
I just replaced  
   Space.Update((float) gameTime.ElapsedGameTime.TotalMilliSeconds);

by

  Space.Update((float) gameTime.ElapsedGameTime.TotalSeconds); 

Because the time tested by the Space class is in seconds !

For the localIntertiatensor it's another story :

in the BepuEntityCollisionMove class :
            if (CachedCollisionObjectScale != CollisionObjectScale)            {                OnCollisionObjectScaleChanged();                CachedCollisionObjectScale = CollisionObjectScale;            } 
this call a change of the shape which happened after I set the LocalInertiaTensor to 0.
So the LocalInertiaTensor is rebuild and maybe some others usefull settings !

( I'm working with the svn v0.8.0.0 version of the engine and I think IGF Physics v0.8.3.0 Runtime Binaries isn't used - if not it would be great to include the fix to this version)


Coordinator
Dec 11, 2011 at 5:23 PM

Is it really using seconds? I believe I remember the samples were passing milliseconds...

Dec 11, 2011 at 5:27 PM
Edited Dec 11, 2011 at 5:27 PM

Space.cs :

            TimeStepSettings.AccumulatedTime += dt;
            for (int i = 0; i < TimeStepSettings.MaximumTimeStepsPerFrame; i++)
            {
                if (TimeStepSettings.AccumulatedTime >= TimeStepSettings.TimeStepDuration)
                {
                    TimeStepSettings.AccumulatedTime -= TimeStepSettings.TimeStepDuration;
                    DoTimeStep();
                }
                else
                {
                    break;
                }
            }
 

 

TimeStepSettings.TimeStepDuration default value equals 1/60 so I let you imagine the problem when dt is given in milliseconds !
Coordinator
Dec 11, 2011 at 7:53 PM

Ok. Kind a strange that in my computer there was no issue running the Ace on Steroids example. Maybe because I set the Application.IsFixedTime property to true...

Coordinator
Dec 11, 2011 at 7:55 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Dec 15, 2011 at 10:46 PM

Everything is ok with v 0.9.0.0.

Good job.