テンプレート:Release Notes/2.49/Game Engine/Physics

Bullet Physics SDK update

• New generic 6dof constraint with run-time configurable limits, motors and springs to allow for physics-based vehicles, forklift, robots and ragdolls.
• Add support to lock individual axis during rigid body simulation, for translation and rotation. This makes it easier to do 1D or 2D physics (tetris, blockout) - set the physics type to rigid body and open the advanced popup.
• Added min/max linear velocity values which can prevent unstable physics by objects moving too fast. It can also be accessed by python to accelerate or throttle objects in their current direction.
• Improved dampening formula for dynamic and rigid objects, a value of 1.0 will not move the object at all.
• As usual, users can expect some different results with old files

Physics Integration

• GameObject "mass" attribute writeable & the setMass actuator.
• Dynamically update the coumpound parent shape when parenting or unparenting to a compound object.
• Recording physics no longer has problems with axis flipping
  

  fix for euler flipping

Sensor Object Type

New sensor object to generalize Near and Radar sensor, static-static collision capability.

A new type of "Sensor" physics object is available in the GE for advanced collision management. It's called Sensor for its similarities with the physics objects that underlie the Near and Radar sensors. Like the Near and Radar object it is:

• static and ghost
• invisible by default
• always active to ensure correct collision detection
• capable of detecting both static and dynamic objects
• ignoring collision with their parent
• capable of broadphase filtering based on:
  • Actor option: the collisioning object must have the Actor flag set to be detected
  • property/material: as specified in the collision sensors attached to it.
    Broadphase filtering is important for performance reason: the collision points will be computed only for the objects that pass the broahphase filter.
• automatically removed from the simulation when no collision sensor is active on it

Unlike the Near and Radar object it can:

• take any shape, including triangle mesh
• be made visible for debugging (just use the Visible actuator)
• have multiple collision sensors using it

Other than that, the sensor objects are ordinary objects. You can move them freely or parent them. When parented to a dynamic object, they can provide advanced collision control to this object.

The type of collision capability depends on the shape:

• box, sphere, cylinder, cone, convex hull provide volume detection.
• triangle mesh provides surface detection but you can give some volume to the suface by increasing the margin in the Advanced Settings panel. The margin applies on both sides of the surface.

Performance tip:

• Sensor objects perform better than Near and Radar: they do less synchronizations because of the Scenegraph optimizations and they can have multiple collision sensors on them (with different property filtering for example).
• Always prefer simple shape (box, sphere) to complex shape whenever possible.
• Always use broadphase filtering (avoid collision sensor with empty propery/material)
• Use collision sensor only when you need them. When no collision sensor is active on the sensor object, it is removed from the simulation and consume no CPU.

Known limitations:

• When running Blender in debug mode, you will see one warning line of the console:
  "warning btCollisionDispatcher::needsCollision: static-static collision!"
  In release mode this message is not printed.
• Collision margin has no effect on sphere, cone and cylinder shape.

Other performance improvements:

• Remove unnecessary interpolation for Near and Radar objects and by extension sensor objects.
• Use direct matrix copy instead of quaternion to synchronize orientation.

Adjustable Frame/Logic/Physics Rate

BGE: GUI control over frame rate, logic rate, physics rate and physics subrate.

Four new buttons in World settings to control frame rate:

• fps: Nominal frame rate in frame per second.
  Also sets the physics timestep = 1/fps
• phys: Maximum number of physics timestep per game frame in case the actual fps is less than nominal. This allows the physics to keep up with real time even if the graphics slows down the game.
• sub: Fixed number of simulation substeps per physic timestep.
  Improves the precision of the physics simulation. Useful for fast moving objects for example.
• log: Maximum number of logic steps per game frame in case the actual fps is less than nominal. This allows the logic system to follow the physics simulation.
  Upper bound = phys
  (setting the value higher than phys has no effect).
  On games with heavy logic system, it is useful to set this value to 1, to keep logic time under control.

All these values were already accessible from Python except phys:

• GameLogic.getMaxPhysicsFrame(): Gets the maximum number of physics frame per render frame.

• GameLogic.setMaxPhysicsFrame(phys): Sets the maximum number of physics timestep that are executed per render frame.
  Higher value allows physics to keep up with realtime even if graphics slows down the game.
  Physics timestep is fixed and equal to 1/tickrate (see setLogicTicRate)
  maxphysics/ticrate is the maximum delay of the renderer that physics can compensate.
  phys: integer