Summary of the New Physics Capabilities

Posted on by michalis

Physics hinges
Physics 3D shooter
Physics asteroids demo
Physics in 2D platformer
Physics explosion
Physics 3D demo

At the beginning of December we merged a big work on physics (and many related features) and later we merged another big work on physics joints (another big merge, 363 commits). It’s time to provide to you some readable summary of all the improvements 🙂

I also wrote a nice documentation about physics. And remember that we feature a lot of physics examples.

New physics (and related) features:

  1. New components, available in both editor and code, to control the physics.

    Just add to any TCastleTransform (usually to TCastleScene or a primitive like TCastleBox, TCastleSphere) some collider in the editor (the rigid body will be automatically added too), and observe that it’s affected by

    • gravity
    • collisions with other objects

    There are lots of options to tweak how things behave. See API docs for documentation.

    Hint: If you’re like me, the first thing you will want to make is a “bullet” that hits something with some speed, so that you can see how it behaves on collision. To make a bullet, just set TCastleRigidBody.LinearVelocity on the bullet object to something non-zero.

  2. New components have also additional features, like:

  3. Colliders are also visualized. Juse use “Physics->Show Colliders” menu item.

  4. There’s a new “Physics Simulation” mode available in the editor. Start it to make physics work. You can click around and modify the design even while the physics is running — this is a feature, albeit a bit dangerous one: the design is restored to the original state when physics stops.

    This is a great way to test how physics behaves without the need to actually run the game.

    Remember that it only runs physics simulation. In the future, more components may behave differently in this simulation. But it doesn’t run your project’s code (unless you put it into a custom component added to the project).

  5. There is a new API to apply forces from code. This can be used to simulate forces other than gravity. For example wind or explosion.

    See demo physics_forces to test out various method to apply forces.

    See demo physics_persistent_forces_components to see example forces components we can make. This is like Blender’s forces to make wind etc.

  6. Third person navigation:

    TCastleThirdPersonNavigation component got a significant upgrade that enables it to change transformation through physically-aware methods. By using physics to “drive” the navigation you get much more natural (physically-correct) movement and jumping.

    The way we change transformation is controlled by new TCastleThirdPersonNavigation.ChangeTransformation property. By default is has ctAuto value, which provides the most recommended way: if you have physics components (TCastleRigidBody, TCastleCollider) on avatar, we change using velocities, otherwise (this is backward-compatible) we change transformation directly.

    See TCastleThirdPersonNavigation.ChangeTransformation and TChangeTransformation docs for more details.

    third_person_navigation example was remade to use physics for movement. You can test various ChangeTransformation values.

    Going forward, we want to remake all our navigations to use physics. In particular, TCastleWalkNavigation (to walk/fly) will get a similar option soon too.

  7. Changing the transformation (like TCastleTransform.Translation) of an object affected by physics is now more reliable. You can do it even if TCastleRigidBody.Dynamic=true (although you should refrain from doing it every frame — the entire point of TCastleRigidBody.Dynamic=true is that you allow physics to affect it).

    TCastleRigidBody.Animated is now really only an “optimization hint” passed to Kraft (determines if we should set body as krbtKinematic or krbtStatic, when Dynamic = false). It has no other effect on CGE code functioning.

    In particular, we allow changing TCastleTransform from code regardless of whether TCastleRigidBody.Animated = true or false.

  8. We have new and powerful methods TCastleAbstractRootTransform.PhysicsRayCast and TCastleRigidBody.PhysicsRayCast. They return TPhysicsRayCastResult packed with information.

    Previously we only had TCastleRigidBody.PhysicsRayCast (new TCastleAbstractRootTransform.PhysicsRayCast allows to use it without starting from any particular TCastleRigidBody) and it didn’t return Point, Normal information.

    Also examples/viewport_and_scenes/collisions/ was extended to show PhysicsRayCast.

  9. The editor has now big buttons to

    • play / stop physics simulation
    • play / stop the application

    from the CGE header. Stopping the application (this also applies to “Run -> Stop External Process”) is also more robust now (we make sure to kill the final application, not only build tool process, in case of “castle-engine run“).

  10. Utility FindAllBehaviors (see physics_explosion for demo)

  11. Editor adjusts to dark theme (if you request it from your OS) better.

  12. We define new useful methods to override on behaviors, making behaviors more useful:

    procedure ParentAfterAttach; virtual;
procedure ParentBeforeDetach; virtual;
procedure WorldAfterAttach; virtual;
procedure WorldBeforeDetach; virtual;

  13. Finally, physics objects also support joints to connect and constrain rigid bodies.

  14. Deprecation notice:

    For now, the old physics components (TRigidBody, TCollider) still exist, and the way to assign them still works (TCastleTransform.RigidBody, TRigidBody.Collider, TCollider.Create(const AParent: TRigidBody)).

    But, as the relation of old and new physics components can be a bit confusing, I would like to remove them rather sooner than later, likely before the 7.0 release. Please upgrade your physics usage to new components ASAP, and let us know on forum/Discord if you have any questions about how to upgrade!

    The TCastleTransform.Collides now has no effect on physics. Previously it had inconsistent effect on physics (TCastleTransform.Collides prevented collisions when exactly this TCastleTransform had a rigid body+collider, but TCastleTransform.Collides of parent didn’t matter).

Start the discussion at Castle Game Engine Forum