Choosing The Physics System Suitable For Your Project
Click Project -> Project Settings -> Feature Crop -> Physics System in the editor's menu bar, to select the appropriate physics engine for development according to the project requirements. The default physics engine is bullet（ammo.js）, and the physics engine can be switched at will during the development process.
If there is no need to use any physically related components and interfaces, uncheck the Physics System checkbox and the package will be smaller when published. However, it should be noted that if the checkbox is unchecked, the project cannot use physically related components and interfaces, otherwise errors will be reported at runtime.
Physics Engine Types
Collision Detection: builtin
builtin only has the function of collision detection. Compared with other physics engines, it has no complicated physical simulation calculations. If your project does not require the physical simulation of this part, you can consider using builtin, which will make the size of game's package smaller.
If you use builtin for development, please note the following:
- builtin only has events of type trigger.
- isTrigger in Collider component is a trigger regardless of whether the value is true or false.
Physics Engine: cannon.js
cannon.js is an open source physics engine, which uses js language to develop and implement more comprehensive physics functions, if your project needs more complex physical functions, then you can consider using cannon.js. The size of the cannon.js module is 141KB.
Physics Engine: bullet (ammo.js)
It should be noted that currently the ammo.js module has a size of about 1.5MB.
Physics Engine: PhysX
PhysX is an open source real-time commercial physics engine developed by Nvidia. It has perfect functional characteristics and extremely high stability, as well as excellent performance.
The PhysX currently supported in Cocos Creator is version 4.1 and is allowed to be used on most platforms. PhysX physics is recommended for better physics performance when publishing to native platforms, especially when publishing to iOS.
However, due to the large package size of the PhysX (about 5MB) and some limitations of its own, it is not well supported on some platforms, including:
- Various mini game platforms with package size restrictions.
- Android x86 device.
Some newer platforms and devices, such as HarmonyOS devices, will be supported in the future. Please pay attention to the update announcement. Apple M1 (Silicon) architecture devices are already supported in v3.4.0.
In addition, the ByteDance platform provides the underlying native physics functionality, so this functionality can also be run in ByteDance Mini Games. For specific details, please refer to publish ByteDance Mini Games.
Physics Engine Performance
Mainly for various Mini Games platforms and native platforms, and compare Bullet and PhysX:
- On native and ByteDance Mini Game platforms, using PhysX can get the best performance.
- On various Mini Game platforms, use Bullet to get the best performance.
Physics Engine Differences
Different physics engines have different internal designs and algorithms, so there will be some different behaviors under the same parameters. These differences are mainly:
dampingproperty on RigidBody components
The damping term is different because PhysX uses different damping algorithm models. But this difference has been eliminated internally. To synchronize the damping value previously set in PhysX, refer to the following code to convert:
const dt = PhysicsSystem.instance.fixedTimeStep; const newDamping = 1 - (1 - oldDamping * dt) ** (1 / dt);
factorproperty on RigidBody components
This is caused by the fact that PhysX physics only fixes the degrees of freedom of the rigid body, and does not provide a scaling factor for the rigid body velocity, that is, the
Angular Factorproperties in the rigid body component only have a fixed effect on PhysX physics. This difference will be removed internally.
The physics material in PhysX supports static friction coefficient, dynamic friction coefficient and elastic coefficient. Compared with the PhysicsMaterial resources in Cocos Creator, it lacks the dynamic friction coefficient. The coefficient is currently consistent with the static friction coefficient. The difference in this part cannot be Provide expressions for conversion.
In addition to the points mentioned above, there are also differences in other algorithms, such as differences in numerical integration methods, LCP solving algorithms, solution accuracy, etc., so there will always be different effects, but these are not easy in actual project development. Perception.