Object Speeds, Velocities and Bounciness

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
cincoutprabu
Posts: 15
Joined: Mon Jan 12, 2015 11:59 pm

Object Speeds, Velocities and Bounciness

Post by cincoutprabu »

Hi, basically the question is how to create a lightweight object with required bounciness. I understand that there are properties like KineticFriction, StaticFriction and Bounciness for Material applied to an entity. I have played around these properties along with gravity, linear and angular velocities, but not able to achieve desired bounciness for different real-world materials like rubber, hollow rubber, plastic, hollow plastic, etc. Practically, objects of different materials dropped from same height will bounce back to different heights (for example hollow rubber will bounce more than solid rubber). Adjusting the Material.Bounciness property helps to achieve different bounce-back heights, but looks like this property is not directly proportional to the bounce-back height. For example, the typical expectation would be like Bounciness of 0.5 would make the object bounce back to 50% of the original height on first bounce, and 0.9 would make the object bounce back to 90% of the original height on first bounce (original height means the height the object is dropped from). But currently, even the bounciness of 0.99 has the bounce-back height of 70% to 80% only. Not sure whether I can achieve this "directly proportional" result by modifying the BEPUphysics code. Another problem with bounciness=0.99 is bounciness effect is not getting reduced or fading away fast enough when the object is moving at a speed (LinearVelocity in Z direction). LinearVelocity in Y direction also helps in adjusting the bounciness but applying this have adverse effects on distance traveled by the object; higher LinearVelocy-in-Y-direction drastically reduces the distance traveled in Z direction which means object bounces more number of times in less distance.

The typical gravity value of -9.81 makes the object move and bounce very slow in the world. Multiplying the gravity n times has good result in increasing the speeds and bounces, but wondering whether adjust gravity is the right solution to achieve this. Also, the Mass property doesn't seem to have any effect on bounce-back heights; object of mass=1 appears to behave similar to object of mass=100 or mass=1000.

My scene is very simple with all of them are static models except one dynamic model (MobileMesh). We know that static models have infinite mass and hence bounciness of all static models are set to 1. The dynamic model is a sphere which will be moving around the scene based on user inputs. All static and dynamic models are set to default KineticFriction (0.8f) and StaticFriction (1.0f) values. Properties like bounciness, gravity, linear velocities appear to have same effect on solid and hollow sphere models (solid rubber ball vs hollow rubber ball). This means the solidity/hollowness of objects also appears to have no effect on object speeding and bouncing behaviors.

Wondering whether camera speed matters here. Currently camera speed is set to 10 (the same Camera class from GettingStartedDemo).

Finally, the problem is we have a handful of properties to adjust the speeding and bouncing behaviors of objects, but getting them to achieve the desired real-world behaviors seems very tricky and not able to settle with a correct combination or correlation of all these properties. Also, some combinations of these values (especially that applies more downward force on the object) produces weird results like object missing the collision detection phase resulting in dynamic model passing thru the static model and escaping the scene altogether. Wondering whether I'm missing something basic or whether I'm not using some other important properties to achieve the desired behaviors.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Object Speeds, Velocities and Bounciness

Post by Norbo »

Adjusting the Material.Bounciness property helps to achieve different bounce-back heights, but looks like this property is not directly proportional to the bounce-back height.
The bounciness coefficient scales the impact velocity to get the bounce velocity, which is not linear with bounce height. Consider launching two balls straight up into the air, one at 10m/s and the other at 20m/s. The one launched at 20m/s will fly four times higher, not two times. (Wolfram alpha has a handy little tool to compute these sorts of problems.)

That said, also make sure that the final coefficients are actually what you expect. Note that both materials in a collision are taken into account when computing a collision pair's material properties. First, the MaterialManager.MaterialInteractions dictionary is checked to see if the material pair has any directly specified coefficients. If not, it falls back to the MaterialManager.MaterialBlender, which takes both materials and computes the resulting coefficients. The default blender is multiplicative. Check the CoefficientsDemo in the BEPUphysicsDemo for an example of a custom MaterialBlender and how it affects bounciness.

There are also other factors which will influence the bounce magnitude:
1) LinearDamping removes energy directly, slowing the bouncing object down. Set it to zero if you don't want the object to lose energy.
2) CollisionResponseSettings.Softness is nonzero by default, which damps collisions. Set it to zero to remove the damping effect. (Nonzero softness is useful for stabilizing difficult to solve situations, like heavy objects stacked on light objects, but most things still work fine when it is set to zero.)
3) Integrator error. The combination of discrete collision detection and a relatively long time step relative to the motion (or oscillation) of an object can introduce error both while in the air and when it hits the ground. This can be mitigated by decreasing the time step duration and, in extreme cases, enabling continuous collision detection, but there will always be some error.

Technically, it's also possible to set bounciness values above 1. You may be able to get behavior closer to what you want even in the presence of these influences. It's definitely a nonphysical hack, but if it works, it works :)
The typical gravity value of -9.81 makes the object move and bounce very slow in the world. Multiplying the gravity n times has good result in increasing the speeds and bounces, but wondering whether adjust gravity is the right solution to achieve this.
The appearance of "moon gravity" is most often caused by objects being large relative to gravity, relative to expectations. So, either shrink objects or increase gravity.

(Side note: if the chosen simulation scale is far from the default tuning designed for ~0.5-10 units and ~10 gravity, behavioral issues can show up. If you suspect this sort of issue, try adjusting the engine's tuning variables using something like the ConfigurationHelper.ApplyScale function in the BEPUphysicsDemos.)

It may also be that the simulation is being stepped too slowly. For example, if the Space.TimeStepSettings.TimeStepDuration is 16.6ms but only one time step is executed per 33.3ms of real time, then the simulation will appear to run at half speed.
Also, the Mass property doesn't seem to have any effect on bounce-back heights; object of mass=1 appears to behave similar to object of mass=100 or mass=1000.
This is expected behavior. Gravity applies a uniform acceleration to all objects regardless of mass, and bounce velocity is just impact velocity * bounciness.
This means the solidity/hollowness of objects also appears to have no effect on object speeding and bouncing behaviors.
This is expected behavior; all entities are rigid bodies that cannot deform, so being hollow or not has no effect on bounciness. Linear velocity is also not affected by solidity.

Solidity configuration can change the object's inertia tensor, but this is relevant to rotational behavior, not bounciness and linear velocity.
Wondering whether camera speed matters here. Currently camera speed is set to 10 (the same Camera class from GettingStartedDemo).
Nope, the physics simulation is completely isolated from rendering.
Also, some combinations of these values (especially that applies more downward force on the object) produces weird results like object missing the collision detection phase resulting in dynamic model passing thru the static model and escaping the scene altogether.
While I wouldn't recommend applying extra impulses just to get the desired bounce, this specific 'tunneling' issue is caused by discrete collision detection and fast motion relative to the time step duration. If you needed to resolve this kind of issue, decrease the time step duration and step more frequently, or turn on continuous collision detection (Entity.PositionUpdateMode = PositionUpdateMode.Continuous).

Also, if the object in question is a MobileMesh, collision detection in extreme cases would likely be more robust (and definitely faster) if it were replaced with a simple primitive (SphereShape, BoxShape, etc.).
cincoutprabu
Posts: 15
Joined: Mon Jan 12, 2015 11:59 pm

Re: Object Speeds, Velocities and Bounciness

Post by cincoutprabu »

Thanks for taking time to read the problem and for the reply & suggestions. The exceptional support makes BEPUphysics special !! Let me try the suggestions and see.
cincoutprabu
Posts: 15
Joined: Mon Jan 12, 2015 11:59 pm

Re: Object Speeds, Velocities and Bounciness

Post by cincoutprabu »

Hi, tweaking the mentioned properties and settings helped adjust the speeding and bouncing behaviors to great extent. But the object is not coming to a rest after moving and bouncing around the scene. In other words, after moving and bouncing around, it comes to a 'rest' position but keeps on jumping in the same position (x and z remains constant, but y keeps changing rapidly). The change in y was very fractional though but the bouncing was even visible from a distance. And this behavior was there before the tweaking also. Not sure whether the game logic should keep track of the movement (x,y,z changes) and use properties like IsAffectedByGravity to forcibly bring object to rest.

As a side note, the moving object is a simple sphere instead of a MobileMesh, with bounciness as 0.85. Thanks again for help!!
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Object Speeds, Velocities and Bounciness

Post by Norbo »

The continued minibounces are caused by the integrator's time steps being too long relative to the oscillation frequency. This is a fairly fundamental sampling problem, but the engine sidesteps it by arbitrarily damping bounces below a velocity threshold defined by CollisionResponseSettings.BouncinessVelocityThreshold. Increasing the threshold's value should eliminate the continued oscillation.

The fact that the default value was not high enough to eliminate the issue in your simulation implies other scale-related variables may also be suboptimally tuned. CollisionResponseSettings.BouncinessVelocityThreshold is one of the variables changed by the ConfigurationHelper.ApplyScale helper function in the BEPUphysicsDemos; you may want to try using the function to address all the tuning factors at once.
cincoutprabu
Posts: 15
Joined: Mon Jan 12, 2015 11:59 pm

Re: Object Speeds, Velocities and Bounciness

Post by cincoutprabu »

Thanks again!! ConfigurationHelper.ApplyScale method with appropriate scale value has solved the minibounces problem.

Another quick question was whether the physics simulation and thereby the game speed (moving objects in the entire scene) will vary based on hardware. For example, the settings like TimeStepDuration and scale values (like the one used for ConfigurationHelper.ApplyScale method) chosen for one hardware (the development machine) will work seamlessly in all target hardwares or whether any calculations or assumptions has to be made based on hardware specs like CPU cores and installed RAM. Note: Only PCs are intended, no XBox or windows phones.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Object Speeds, Velocities and Bounciness

Post by Norbo »

Behavior should be consistent across all platforms; scale and TimeStepDuration should not need to be modified.

There are two issues to watch out for on other platforms:
1) Performance. The CPU needs to be fast enough to run the simulation, or it will fall helplessly behind. Similarly, make sure the game only steps the simulation as often as is necessary, or else people with fast CPUs would end up speedrunning everything.
2) Floating point nondeterminism. While it's technically possible to make the engine run deterministically with some effort on a single computer, different CPUs can produce different results for floating point operations. This makes it difficult to implement something like deterministic lock step networking on variable hardware targets.
Post Reply