This page has been translated automatically.
Video Tutorials
Interface
Essentials
Advanced
How To
Professional (SIM)
UnigineEditor
Interface Overview
Assets Workflow
Version Control
Working With Projects
Adjusting Node Parameters
Setting Up Materials
Setting Up Properties
Lighting
Sandworm
Using Editor Tools for Specific Tasks
Extending Editor Functionality
Built-in Node Types
Nodes
Objects
Effects
Decals
Light Sources
Geodetics
World Nodes
Sound Objects
Pathfinding Objects
Players
Programming
Fundamentals
Setting Up Development Environment
Usage Examples
C++
C#
UnigineScript
UUSL (Unified UNIGINE Shader Language)
Plugins
File Formats
Materials and Shaders
Rebuilding the Engine Tools
GUI
Double Precision Coordinates
API
Containers
Common Functionality
Controls-Related Classes
Engine-Related Classes
Filesystem Functionality
GUI-Related Classes
Math Functionality
Node-Related Classes
Objects-Related Classes
Networking Functionality
Pathfinding-Related Classes
Physics-Related Classes
Plugins-Related Classes
IG Plugin
CIGIConnector Plugin
Rendering-Related Classes
Content Creation
Content Optimization
Materials
Material Nodes Library
Miscellaneous
Input
Math
Matrix
Textures
Art Samples
Tutorials
Warning! This version of documentation is OUTDATED, as it describes an older SDK version! Please switch to the documentation for the latest SDK version.
Warning! This version of documentation describes an old SDK version which is no longer supported! Please upgrade to the latest SDK version.

Global Physics Settings

The Physics section of the Settings window allows you to adjust global physics-related settings: values set here will be applied to all physical objects in the scene.

Notice
To configure physics settings, open the Settings window by choosing Window -> Settings in the main menu and select Runtime -> World -> Physics section.

For more information on how to add physical properties to objects and set up physical interactions, see the articles in the Physics section.

Physics Settings

Global Physics Settings Window

The following settings are available:

Stable FPS

Toggles frame time stabilization on and off. In case the current Engine framerate is much higher than the fixed Physics framerate (e.g. 120 FPS vs 60 FPS), the physics won't be updated each rendering frame (e.g. it may update during every second frame). The resulting frame time will become unstable, shorter-longer-shorter-longer (render -> render+physics -> render -> render+physics...). This option ensures stable frame time for smoother user experience removing unwanted "hiccups" (however, the average framerate is decreased).

Notice
By default, this option is enabled. But you can disable it to increase average framerate in case the application is used for machine learning or for grabbing frame sequences (Video Grabber), when smoothness is not important.
Determinism

Toggles Deterministic mode on and off. Deterministic mode ensures that all contacts are solved in the predefined order and visualization of physics in the world is repetitive (on one computer). When this mode is enabled, the Engine performs additional sorting of bodies, shapes, and joints inside islands after building them.

Notice
  • Determinism is guaranteed if there are no missed frames, the same Engine version is used, and the CPUs perform SSE operations similarly. There may be differences between visualization of physics on different hardware (e.g., AMD and Intel).
  • Deterministic mode does not come for free, it may eat up 10-20% of the frame rate, and it also depends on the scene a lot.
Sync Engine Update With Physics

Toggles synchronization of the Engine FPS with the physics one.

Such FPS limitation makes it possible to calculate physics each rendered frame (rather then interpolate it when this option is disabled). In this mode, there is no twitching of physical objects if they have non-linear velocities. If the Engine FPS is lower than the physics one, this option has no effect.

Update Mode

Update mode to be used for physics:

  • Before Rendering — physics update (along with the spatial tree update and user callbacks) is executed in the Main thread just before rendering is performed (render). The number of physics ticks executed before the rendering frame here is defined by the physics and the Engine framerates. This mode is the most clear and straightforward (everything is executed safely in a strictly determined order) with no frame lag (results of physics calculations are applied in the current frame). But, on the other hand, this mode is the slowest as there are no asynchronous parallel calculations (everything's in the Main thread). Use this mode in case the time lag is unacceptabe for your application (you need all physics calculations to be applied in the current frame) and you want maximum simplicity and strictly determined order of execution for user code (physicsUpdate and physics callbacks).
  • Async Rendering — physics update is performed asynchronously to rendering. In case of several physics ticks per one rendering frame (when the Engine framerate is lower, or catching up is performed), only the first one is executed in parallel, then the physics module waits for the completion of the rendering process, returns to the Main thread and executes the rest of the physics ticks. There is a frame lag (results of physics calculations are applied in the next frame) and there is some ambiguity regarding the time, when user code (physicsUpdate and physics callbacks) is to be executed in case of several physics ticks per one rendering frame (some part is executed before rendering while the other just after it). This mode is the fastest one and is used by default.
Missed Frame Lifetime

Lifetime for missed frames, in milliseconds. This value defines how long missed frames are to be kept in the catch-up buffer.

In case the current Engine framerate is lower than the fixed Physics framerate, some of the physics frames get skipped and the simulation starts looking like in a slo-mo effect (e.g., if the target physics framerate is 60 FPS, when the Engine updates at 30 FPS, the simulation will look 2 times slower). The Physics module will try to catch up everything missed later, when possible (e.g. when the Engine framerate grows higher, while waiting for GPU to complete rendering). The missed frames are kept in a buffer for some time (lifetime), as it expires the frame is removed from the buffer and becomes lost forever.

Notice
Setting too high values may result in significant memory consumption in case of low hardware capabilities (no catching-up performed with a growing number of missed frames).
Distance Distance from the camera, from which physical interactions will not be calculated. All physics-based nodes freeze if the distance between them and the camera is bigger than the Physics distance. The distance is measured from the camera to the node's bound.
Limited Physics distance
Physics Distance = 40 units
Infinite Physics distance
Physics Distance = inf
Budget Physics simulation time budget in seconds.
FPS Fixed frame rate used to simulate physics. Physics frame rate is independent of the rendering one.
Notice
If physics takes more than the assigned time budget, further calculations are delayed. These calculations shall be performed during the subsequent rendering frames, making physics simulation look like in a "slo-mo" mode. The default budget is 50 ms, but it can be increased, as necessary.
Scale Scale factor to speed up or slow down the physics simulation time, i.e how frequently physics is simulated (for example, slowing down of body's velocity). Only physics ticks are affected, while everything else is rendered at a normal speed.
Iterations The number of iterations for physics during one physics tick. Each iteration the full cycle of physics simulation is performed:
  • updatePhysics() from the world logic is called
  • collision detection is calculated
  • joints are solved
Notice
High number of iterations increases stability, but also results in a higher load. If physics takes more than set in the time budget, next iterations are automatically delayed and moved to the next rendering frame.
Linear damp Damping of objects' linear velocities. This value is added to the linear damping set individually for each object.
  • The higher the value, the faster objects stop moving along the straight line.
Angular damp Damping of objects' angular velocities. This value is added to the angular damping set individually for each object.
  • The higher the value, the faster objects stop their rotation.
Max linear velocity The maximum possible linear velocity.
  • This value is compared to the maximum linear velocity set for each body, and the lowest value serves as a threshold to clip the actual linear velocity, if necessary.
Max angular velocity The maximum possible angular velocity.
  • This value is compared to the maximum angular velocity set for each body, and the lowest value serves as a threshold to clip the actual angular velocity, if necessary.
Frozen linear velocity Linear velocity at which the object becomes frozen, if it keeps both of its velocities (angular and linear) lower than the freeze velocities.
  • This value is compared to the Frozen linear velocity set for each body, and the highest value serves as a threshold to compare actual velocity with.
Frozen angular velocity Angular velocity at which the object becomes frozen, if it keeps both of its velocities (angular and linear) lower than the freeze velocities.
  • This value is compared to the Frozen angular velocity set for each body, and the highest value serves as a threshold to compare actual velocity with.
Frozen frames The number of frames, during which an object should keep both its angular and linear velocities under the specified level to become frozen.
Penetration factor The factor used to define the rebounding force in case of penetration.
  • The minimum value of 0 means there is no rebounding by contact penetration.
  • The maximum value of 1 means objects rebound with the maximum possible impulse.
Penetration tolerance Distance in units indicating how deep one object can penetrate another to be rebounded.
Gravity Three coordinates of the vector used to define a gravity. It creates a world-wide uniform force field. Gravity is applied at the center of mass of each body (except for dummy body) to calculate its acceleration.
  • Normally gravity vector should point downwards, i.e. have negative value along the Z axis.
  • The higher the value along one of the axes, the stronger gravity presses in the specified direction.

Watch an overview of the global physics settings in our video tutorial on physics.

Last update: 2023-06-23
Build: ()