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 🙂
New physics (and related) features:
New components, available in both editor and code, to control the physics.
- Family of components descending from abstract
Just add to any
TCastleSceneor a primitive like
TCastleSphere) some collider in the editor (the rigid body will be automatically added too), and observe that it’s affected by
- 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.LinearVelocityon the bullet object to something non-zero.
New components have also additional features, like:
TCastleCollider.AutoSize(by default true) that sets many collider properties automatically. You can alternatively use
TCastleCollider.CalculateSizecalls explicitly. Or just set properties like
TCastleCollider.TCastleSphereCollider.Radiusand more explicitly.
TCastleCollider.Translation(adjusted automatically if
TCastleCollider.Rotation(adjusted automatically if
TCastleCollider.SizeScale(not adjusted by
TCastleCollider.AutoSize, this is a feature — it can scale the collider calculated by AutoSize)
Colliders are also visualized. Juse use “Physics->Show Colliders” menu item.
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).
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.
Third person navigation:
TCastleThirdPersonNavigationcomponent 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.ChangeTransformationproperty. By default is has
ctAutovalue, 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.
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.
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.Animatedis now really only an “optimization hint” passed to Kraft (determines if we should set body as
false). It has no other effect on CGE code functioning.
In particular, we allow changing TCastleTransform from code regardless of whether
Previously we only had
TCastleAbstractRootTransform.PhysicsRayCastallows to use it without starting from any particular
TCastleRigidBody) and it didn’t return
Also examples/viewport_and_scenes/collisions/ was extended to show
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 “
Editor adjusts to dark theme (if you request it from your OS) better.
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;
Finally, physics objects also support joints to connect and constrain rigid bodies.
For now, the old physics components (
TCollider) still exist, and the way to assign them still works (
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!
TCastleTransform.Collidesnow 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).