RigidBody
RigidBody is a customizable solid object supporting collision detection and realistic physics simulation.
You can use your favorite 3d modeling application to create new rigid-bodies and add them to the RigidBody object library.
Your own 3d models are used by the RigidBody object as a reference to implement collision detection or determine mass distribution (which ultimately determines physics behavior). Please see this document for details.
Run-time, a RigidBody object is usually invisible and its visual aspect is provided by a SkinMesh attached to it. However, in the Virtual Editor (and run-time, mainly for debug purposes) it is visualized via a placeholder-mesh.
The RigidBody can act either as a static object (for example a terrain or the walls in a dungeon) or as a dynamic object (a car body, an airplane fuselage, a bullet, a falling rock etc). Please see Total Mass parameter (below) for more.
The RigidBody object will be subject to physics laws as soon as the project is started. For example, if it is dynamic and it is linked to a G-Force and a Terrain object, it will fall and rebound realistically.
After adding a RigidBody object to your project, you can configure it by double-clicking it in the Object List.
If this option is not checked, the rigid-body will only perform physics simulation when the object is shown by another object, like for example EventOnInput.
Note that physics is enabled by showing the object, instead of starting it, because being enabled, for a RigidBody object, doesn't just mean that its physics simulation is performed, but also that its placeholder geometry is rendered run-time. But see Display placeholder geometry for more.
Check this option to visualize the rigid-body's placeholder model, run-time. Note that the model is not shown if the object is disabled (see Enabled at start).
In the Virtual Editor you can only hide the placeholder mesh by right-clicking the item in the Object List.
When this value is non-zero, and the RigidBody object is linked to a SkinMesh which is bone-animated, the rigid-body will be attached to the SkinMesh's bone specified by the ID.
This feature can be used, for example, to achieve collision-detection and physics for a foot kicking a ball. See the example project called SkinMeshBoneRigidBodyDemo.3dr.
The bone ID must be a positive, non-zero integer. The first bone in the model is 1, the second 2 and so on. What bone corresponds to a certain ID depends on how the animated model was originally designed.
Note: the position of the attached RigidBody object is relative to the bone position when the animated model is in its initial pose. This may not be the default pose you see in the Virtual Editor. To see the initial pose of all animated SkinMesh objects in the scene, hold the [F] key pressed.
Note: this parameter can be modified run-time by using a script (see 'Internal Parameters' section, below). This allows you to detach the RigidBody object (bone ID = 0) or switch target bone. Note that this feature is only supported for RigidBody objects that are attached to a bone when the project starts.
If you attach the RigidBody object to a path by linking it to a Path object then it will try to follow the pre-defined course.
Note that the relative speed along a specific portion of the path depends on the number of nodes defined along the segment. In particular, the more nodes are defined, the slower the speed. This property allows you to accurately program speed variations.
When the RigidBody is attached to a bone or a Path, it will tend to follow the bone/path. You must tweak the Force intensity and Torque intensity factors to achieve an accurate following behavior for your specific object.
The remarkable advantage in mixing bone/path following with physics this way (instead of using SkinMesh object's bone/path following functionality for example) is that your object can interact realistically with the environment (collisions, forces, joints) while traveling along the pre-defined bone/path course.
This simplified 'solid' volume is faster to process. It is automatically created from the bounding sphere of the placeholder mesh and it is recommended over the spg/coo-based version where accuracy for collision detection and simulation is not required.
NOTE: setting masses too low can cause unstable simulations, especially when multiple RigidBody objects are connected by using Joint objects to form complex systems. Messes below 1.0 are usually not recommended, unless bodies are very simple, like for example single spheres.
IMPORTANT! Setting this value to -1 will make the object static (infinite weight). This is typically used for scenery elements, like terrain, buildings, trees and so on.
NOTE: if the RigidBody is box/sphere-group based and its mass is -1, then its position can be set dynamically (run-time), for example by using a script (iObject...Set() functions), to achieve paddles and similar objects that affect the environment but aren't affected by it. For an example please see the demo project called PaddleDemo.
Note that when two objects collide, the actual restitution is the average of the restitution factors of the two objects.
Note that when two objects collide, the actual friction is the average of the friction factors of the two objects.
On collisions, excessive speed or spin may cause inaccurate physics simulation, severe frame-rate drops and even crashes. To achieve solid simulations, set these parameters to the lowest values allowed by your game design.
This option allows you to hide all SkinMeshes linked to the RigidBody, when the RigidBody object is hidden and show them when the RigidBody is shown.
This feature is typically used with the 'HIDE ON CONTACT' option currently supported by the EventOnContact object, allowing you to control visibility of individual RigidBody objects and all their SkinMeshes by using one single EventOnContact object and no scripting.
For information about the remaining controls, please click here.
This object includes functionality allowing you to create/set/destroy RigidBody object clones run-time by using iObjectImposter*() script functions or the Imposter object. For examples of usage, please see the sample projects named RigidBodyImposters.3dr and ImposterObjectRBDemo.3dr (in 3D Rad, press Ctrl+O to visualize the list of available demo projects).
The clones (imposters) are identical to the master RigidBody object but perform physics simulation independently.
Collision detection and response is enabled between each imposter and all objects in the scene that are linked (ticked on the Object List) to the master RigidBody object.
Collision detection and response are also enabled among the imposter objects themselves (that is, all clones will perform collision detection with all other identical clones in the group).
Furthermore, if RigidBody objects are linked (collision enabled), imposters you create for them will perform collision detection (that is, collision detection between imposters from different RigidBody objects will be supported).
Because imposters are true internal clones derived from the master data structures (not, recreated by reloading the .spg/.coo files), they are fast to create and take advantage of the maximum processing power provided by NVidia PhysX.
NOTE: imposters are supported for both dynamic (box/sphere-group based) and static (polygon-based) RigidBody objects.
NOTE: if the master RigidBody has the 'display geometry' option enabled, its imposters are rendered by using a clone of the master's visual. In order to also visualize an imposter's shadows however, the master RigidBody object needs to have one defined and the iObjectImposterShadowEnable() script function will have to be called for the imposter.
NOTE: hiding a RigidBody imposter will remove it completely from the simulation. When shown back, physics simulation for it will resume at the location where it was when hidden, but without any residual kinetic energy (that is, if an imposter was falling due to gravity force, when shown again, it will resume falling from a still state).
NOTE: a new script function called iObjectImposterGet() will also be provided to allow you to retrieve individual imposter positions run-time. This will be useful for example to 'attach' imposters from other object types (like SkinMesh, Particles etc) to individual RigidBody imposters.
NOTE: physics property changes (like to friction, restitution etc) applied to the master after imposters have been created are not automatically transferred to imposters.
NOTE: if the master RigidBody is linked to a G-Force object, the gravity acceleration applied to it will also be applied to all the imposters individually as well. Keep in mind however that if the master RigidBody moves out of the area of influence of the G-Force object, the accleration will no longer be applied to the imposters, even if they are still within the area of influence of the G-Force object. This behavior also dictates that, when gravity is set to radial mode for the G-Force object, the actual acceleration applied to individual imposters will be determined by the master position relative to the G-Force object, not the individual imposter object position.
The following internal parameters can be accessed by using event objects like EventOnValue or Script: