Class TCastleCollider

Default for Density.

Default for Mass, zero means "use Density instead".

Default for Restitution.

Default for Friction.

Minimum collider thickness used by AutoSize in 3D mode (when Mode2D = False). Changing this only affects new size calculations.

Minimum collider thickness used by AutoSize in 2D mode (when Mode2D = True). This is used for axis other than Z (like X, Y, or collider radiuses that affect size in a few axis). Changing this only affects new size calculations.

Minimum collider thickness used by AutoSize in 2D mode (when Mode2D = True) for Z. This is used only by TCastleBoxCollider now, as only that collider has specific size in Z. Changing this only affects new size calculations.

Use this for "stored" for properties that are auto-calculated when AutoSize.

Total scale, accumulated from all parents TCastleTransform.Scale (converted to scalar following Mode2D) and collider SizeScale.

Notify associated TCastleRigidBody that Kraft shape needs to be recreated. This may in turn call TCastleCollider.InitializeKraft and TCastleCollider.CreateKraftShape.

Called when the collider size has changed and needs to be updated.

Only one TCastleCollider behavior can be added to a given TCastleTransform so we check that here.

Sets AutoSize = False, unless this is called inside InternalAutoSize or at loading. Call this when something changes collider size explicitly, e.g. TCastleSphereCollider.Radius changes.

Recalculate collider size. Do not be concerned about AutoSize here, just update collider properties. The default implementation resets Translation and Rotation.

Notify this collider that given TCastleTransform changed. It can provoke AutoSize recalculation (if Parent changed) or other reactions (e.g. mesh update, if TransformChanged corresponds to Mesh).

Create collider visualization.

Destroy collider visualization.

Recalculate collider size using parent bounding box, only if AutoSize says we should recalculate. Ignored if not AutoSize.

Calculate collider size to reflect parent bounding box now. This works regardless of AutoSize value, and doesn't change AutoSize value. The idea is that you can call it when

1. You have AutoSize = False and want to adjust size to bounding box at specific moment.

2. You have AutoSize = True but still want to force recalculation right now, because AutoSize doesn't do it too eagerly (see AutoSize description).

See also

AutoSize

Automatically calculate collider properties that determine collider size based on the parent transformation bounding box.

Local collider translation, relative to parent TCastleTransform. Note that CalculateSize and AutoSize mechanisms set it automatically.

Local collider rotation, relative to parent TCastleTransform. Note that CalculateSize and AutoSize mechanisms set it automatically.

Automatically calculate collider properties that determine collider size based on the parent transformation bounding box.

When this is set, properties like TCastleSphereCollider.Radius or TCastleBoxCollider.Size are automatically updated to the best values to match collider size with the parent TCastleTransform.LocalBoundingBox.

Note that even when this is True, the collider size recalculation is not done too "eagerly", i.e. the collider size is not recalculated on every possible change. For example, if you animate a TCastleScene, then bounding box may change every frame (note: it depends on the technique; e.g. glTF models with skinned animation have a complete bounding box of the animation precalculated and constant; but X3D models morphed using CoordinateInterpolator have bounding box changing every frame).

But it would be bad to change the collider size (even at design-time) every frame. That's because changing the collider size may imply (for the underlying physics engine) recreation of internal srtuctures and reinitialization of the collision state. So in the ideal case, the collider size should just stay constant once the object has been added to some TCastleViewport and it may interact with other physics bodies.

You can always manually force recalculation of the collider size using the CalculateSize method.

Density (per volume) in kg, this implicitly determines mass (volume is automatically calculated by the physics engine). If you instead prefer to explicitly set mass, set Mass property to something non-zero.

Mass in kg. When non-zero, this overrides the automatically calculated mass from the volume and Density.

Larger restitution means that on collision, this object behaves more elastic. Reasonable values are between 0 (inelastic) and 1 (elastic). See https://en.wikipedia.org/wiki/Coefficient_of_restitution .

Larger friction means that it is harder for body to slide alongside another object.

Local collider size scale.

This is particularly useful if AutoSize mechanism calculated too large box. For collision purposes, you sometimes want a collider that is a bit smaller than the bounding box/sphere around the object. Maybe it should even be too small at certain places, but then it will make a better fit overall.

You can achieve this (and still keep using AutoSize) by adjusting this property e.g. to 0.9 to have collider be 90% of what AutoSize calculated.

This is not reset by CalculateSize and AutoSize mechanisms (in contrast to Translation, Rotation) because the idea is that user adjusts the auto-calculated size this way.

Make various features (in particular automatic size calculation caused by AutoSize) better adjusted to 2D models, where the user-visible shape is in XY and the Z coordinate (position in Z, thickness in Z) should have little or no effect on the result.

More precisely, when this is True:

1. AutoSize estimates collider 3D sizes (because internally Kraft colliders are always in 3D) based on geometry sizes only in XY dimensions. So it ignores how thin or thick is you geometry along the Z axis.

2. AutoSize assumes a bit larger "minimum thickness" for 2D, because typical 2D worlds use larger units. Moreover, it assumes even larger thickness in Z, to avoid too thin boxes (that would not be detected as collidable). See AutoSizeMinThickness, AutoSizeMinThickness2D, AutoSizeMinThickness2DDepth.

3. Non-uniform scale (coming from accumulated TCastleTransform.Scale on all our parents) is handled differently. When Mode2D = True, the non-uniform scale is converted into a scalar using Approximate2DScale, so it only looks at XY coordinates. When Mode2D = False, the non-uniform scale is converted using Approximate3DScale, so it looks at all coordinates.

4. In the future, esp. if we integrate with other physics engines like Box2D, it is possible that some colliders in 2D mode will have a shape much more suitable in 2D. "Suitable in 2D" ideally means "Z coordinate is ignored". This means that a 2D collider should (ideally) behave as if it is infinite in Z.

   For example a 2D sphere collider may effectively be an infinite cylinder. That is: it should be a circle in XY, but extruded into infinity in -Z and +Z. This is not right now how the TCastleSphereCollider behaves with Mode2D = True, but it may be in the future.

Translation that can be visually edited in Castle Game Engine Editor, Lazarus and Delphi. Normal user code does not need to deal with this, instead read or write Translation directly.

See also

Translation

Local collider translation, relative to parent TCastleTransform.

Rotation that can be visually edited in Castle Game Engine Editor, Lazarus and Delphi. Normal user code does not need to deal with this, instead read or write Rotation directly.

See also

Rotation

Local collider rotation, relative to parent TCastleTransform.