physics
- Introduction
- Rigid bodies
- Static bodies
- Trigger bodies
- Ray cast
- Physics World
- Vehicle simulations
- Vehicle example
- Soft Bodies
- Cloth simulation
- Common pitfalls / troubleshoot
Armory is designed to work with any physics engine. Internally, a glue code is written which binds the physics simulation. This lets you pick the most suitable physics engine depending on project needs and makes Armory future-proof.
If no rigid body is detected in the scene, Armory skips including the physics module to save space and performance. To force the physics module, set Armory Project - Modules - Physics from Auto to Enabled.
By default, Armory is configured to use a full featured Bullet physics. If lighter engine is sufficient, Oimo physics is provided. With Oimo, triangle mesh shapes are approximated using convex hulls.
To pick active physics engine, set Armory Project - Modules - Physics Engine property.
A rigid body is a type of body that can be used to simulate physical interactions between solid bodies.
To start using rigid body simulations in Armory, they have to be enabled for Blender first. To do so, simply select the object that will interact in the physic simulation, then go to the Physics properties tab, on the Properties editor, and click on the Rigid Body button.
If you hit Play (default F5), the object should be immediately free falling out of view:
If this doesn't occur for any reason, you may want to give the troubleshoot section a look.
Fully simulated physical interactions with other rigid bodies. They are affected by gravity by default.
Objects that don't move during physical interactions with dynamic or kinematic rigid bodies. Not affected by gravity whatsoever.
Objects that are controlled and animated during physical interactions. They are not affected by the physical simulations themselves, but can affect other rigid bodies.
After you click Rigid Body, you will notice that an array of options will appear. These options allow configuring rigid bodies and are explained in details below:
Allow controlling the type of the rigid body when exporting.
-
Activemakes the rigid body to be exported asDynamicifAnimatedis disabled. -
Passivemakes the rigid body to be exported asStaticifAnimatedis disabled.
How much the rigid body "weighs". Important for simulations where more realism is expected, like realistic car movement using vehicle physics.
Controls whether the rigid body is Static when exporting. If disabled, rigid body will be exported as Static instead of Dynamic if Animated is disabled.
Controls whether the rigid body is exported as Kinematic.
Definition of the shape of the rigid body for the physical simulations. Can be either a primitive: Box, Sphere, Capsule, Cylinder, Cone, which are much better for performance, or Mesh or Convex Hull which are more precise on the shape.
Visual representations of primitives in Blender:
| Box | Sphere | Capsule | Cylinder | Cone |
|---|---|---|---|---|
 |
 |
 |
 |
 |
Non-primitives don't have a visual representation in Blender, but they are mostly based around the original mesh. For convex hull, a new mesh is generated at runtime which is a simplification of the original mesh, and it may look like something like this more or less, at least its outline:
Unlike convex hull, for mesh there is no simplified custom mesh generation, so it's imperative that you create a simplified and maybe even low poly version of the original mesh, to avoid major performance drops.
We can observe the difference between convex hull and mesh by just running a simple physical interaction test:
| Mesh | Convex hull |
|---|---|
 |
 |
Resistance of the object to movement. Note that other object's friction value affects the result.
Default friction (0.5) for the dynamic rigid body and the static one:
Default friction (0.5) for the dynamic rigid body and 0.0 for the static one:
Tendency to bounce after collision. The greater the value, the more elastic. Note that other object's bounciness value affects the result.
0.75 for both the dynamic rigid body and the static one:
0.25 for both the dynamic rigid body and the static one:
Along with rigid bodies, Armory also supports Rigid body constraints which lets you limit how a rigid body can move during a physics simulation. Say you only want the object to be able to move along the X & Y axis or lock/connect an object to another object.
Rigid body physics constraints can be added either through the Logic node editor or from the physics tab in the properties panel. This is not to be confused with "Object constraints" from the object constraints properties panel, which are currently not supported. A detailed explanation on how to properly add constraints and their types is elaborated in detail here
- If you want to spawn several instances of the same set of objects using rigid body constraints during runtime (and have them all be active at the same time) you will have to enable the
Relative Physics Constraintoption in the Armory tab of the Physics panel. In order for this to work, place all theRigid Bodiesto be constrained in a separateCollection. Then, connect theseRigid Bodieswith the constraints and enable theRelative Physics Constraintoption. Then, during runtime, to spawn an instance, spawn the collection containing theRigid Bodies. This will automatically add the required constraints between the newly spawned objects.
Its also worth mentioning that parenting objects together doesn't quite work as an alternative solution to rigid body constraints for connecting 2 physics bodies together. However you can parent objects that are not under the effect of any physics simulations as a child to a rigid body, and as a result, these children would move along with your physics simulated body like expected. An example use case for this would be using a separate collision mesh only for simulating physics on and a child mesh that's only for the renderer to draw.
https://github.com/QuantumCoderQC/ConstraintVehicleExample
Make sure your Blender objects that interact in physics simulations always have scale of (1.0, 1.0, 1.0) inside of Blender. Rotation and location may be arbitrary.
You can always apply the scale from within Blender by selecting the object, opening the Object menu entry and then navigating to Apply and then clicking on Scale, or simply hitting the shortcut Ctrl + A and then hitting the s key or simply selecting the option from the floating menu.
Generally any game refresh rate below 50 will cause bullet physics to become unstable resulting in objects moving in unpredictable ways "flying around" without being affected by any force other than gravity.
To demonstrate with a vehicle using rigid bodies, rigid body constraints and cylinder based wheels (movement is made using the apply torque node affecting the wheels):
- 49 Hz: https://vimeo.com/553039855
- 50 Hz: https://vimeo.com/553040233
The effects generally get worse with the refresh rate. Note that testing getting these results were only done for this particular scenario, more testing would need to be done to be sure that this cant affect refreshrates above 49 Hz. Testing was done in a packaged Krom game built in Blender 2.93 Beta & the armory build provided here: https://github.com/armory3d/armory/pull/2082.
Something that may be easy to forget is making sure the timeline is set to 0 upon launching the game. If its set to anything after 0, basically Blender will use the location of any objects as they are currently displayed in the scene and if you try spawning any objects from other scenes than the currently active scene in Blender when pressing "Play", these objects will have there positions predicted by where they would naturally be due to simulations of physics taking place before that frame.
Its worth mentioning that only the current frame in the active scene of Blender will be taken into account. So if you spawn an object from another scene during runtime, those objects will also be "predicted" based on the active frame in the active scene, not the scene that the object originated from.
A common result of this is that your rigid bodies may appear in places that you might not expect them to be in when pressing Play.