Class TCastleBillboard

This item has no description. Showing description inherited from TCastleBehavior.CanAttachToParent.

Check can this behavior be added to NewParent. When this returns False, it has to set also ReasonWhyCannot. When overriding this, you can use e.g. this code to make sure we are the only behavior of given class:

function TCastleBillboard.CanAttachToParent(const NewParent: TCastleTransform;
  out ReasonWhyCannot: String): Boolean;
begin
  Result := inherited;
  if not Result then Exit;

  if NewParent.FindBehavior(TCastleBillboard) <> nil then
  begin
    ReasonWhyCannot := 'Only one TCastleBillboard behavior can be added to a given TCastleTransform';
    Result := false;
  end;
end;

This item has no description.

This item has no description.

This item has no description. Showing description inherited from TCastleBehavior.BeforeRender.

Event called right before rendering the parent TCastleTransform. Override this if you have to adjust the parent transformation strictly before the rendering.

Compared to adjusting the parent transformation in e.g. Update, adjusting the parent transformation here has advantages:

1. There's no 1-frame delay between moving the thing that causes the change (like camera) and updating the thing that reacts to it (like a transformation with a billboard).

2. We adjust transformation before rendering each occurrence of TCastleTransform in the viewport tree. This matters if given TCastleTransform may occur multiple times in the viewport tree, directly or through TCastleTransformReference.

3. We adjust transformation before each render, so things are OK if given TCastleTransform is present in multiple viewports (see https://castle-engine.io/multiple_viewports_to_display_one_world).

For example, adjusting the TCastleTransform done by the TCastleBillboard is done using this method. The transformation in this case is determined by the camera and parent's parent transformation. The transformation has to be applied without any delay (even a 1-frame delay would be visible, as artifacts caused by billboard not perfectly aligned with the camera would be visible – blending sort along camera direction in sort3D is not perfect if billboard doesn't exactly match camera direction). And the transformation with billboard may be present in multiple viewports and/or multiple times in the same viewport tree.

This item has no description. Showing description inherited from TCastleComponent.PropertySections.

Section where to show property in the editor.

Axis around which the billboard rotates to face the camera. The rotation is free in 3D (with undefined up vector) when this is zero.

When non-zero, this axis is set as TCastleTransform.Up.

Similar to X3D TBillboardNode.AxisOfRotation. By default +Y (that is, (0, 1, 0)).

Note that this axis is expressed in the coordinate system of "parent of our parent" transform. That is, if you have instance X of a TCastleTransform, with TCastleBehavior attached, and it is a child of TCastleTransform instance Y, then you can rotate Y and it effectively rotates also the billboard's axis of rotation. The billboard still works correctly (it will rotate the X to look at camera as much as possible, though it cannot change rotation on Y).

See MatchCameraDirection for details how this axis affects object transformation.

Whether the billboard direction should match the camera direction (True, default) or direction from camera to the billboard origin (False).

The difference between these 2 settings is subtle.

• When True, all billboards in the scene have the same orientation (if they have the same AxisOfRotation). They just follow camera orientation. Billboard orientation is unrelated to billboard position, and unrelated to camera position.

  Strafing (moving camera) left/right doesn't change the billboard orientation. Moving billboard left/right doesn't change the billboard orientation.

  This may look better or worse – really depends on what you want to achieve.

  The major advantage of this approach (and the reason why it is the default) is that blending sorting for objects with thin layers, like on Spine models, can be made perfectly reliable, even in 3D.

  • When AxisOfRotation is zero (on all billboards) then TCastleViewport.BlendingSort set to sort3D will be perfect. It will work even if camera can make free rotations (downward and upward) in 3D.

    sort3D is also a good choice if AxisOfRotation is non-zero, but your camera "up" is locked (you don't let player to rotate downward or upward) to the same direction.

  • When AxisOfRotation is +Y (0,1,0) (on all billboards) then TCastleViewport.BlendingSort set to sort3DVerticalBillboards will be perfect. It will work even if camera can make free rotations (downward and upward) in 3D.

  • Many other possibilities can be accounted for using sortCustom and TCastleViewport.OnCustomShapeSort event. If only your AxisOfRotation is consistent for all billboards, you can implement something similar to sort3DVerticalBillboards to account for given up vector.

• When False, billboard orientation adjusts to the direction from camera to the origin of the billboard transformation. This means that the billboard position affects the billboard orientation, e.g. billboards on the edge of the field of view will have a different orientation than in the middle of the view.

  This is consistent with X3D Billboard, https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/navigation.html#Billboard .

AxisOfRotation 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 AxisOfRotation directly.

See also

AxisOfRotation

Axis around which the billboard rotates to face the camera.