This component defines nodes to control the camera,
and some effects closely related to the camera.
NavigationInfo controls the camera behavior.
the initial camera position and rotation, and may be used to animate
LOD allows to implement level-of-detail,
where different versions of some object are displayed depending
on the camera distance.
Collision allows to use a simpler
geometry for collision purposes, or even to turn the collisions off
(like a fake wall hiding a secret room in games).
Billboard may be used to create sprites, as it aligns
geometry (flat or not) with respect to the camera.
For demos and tests of these features,
navigation subdirectory inside our VRML/X3D demo models.
These nodes define the initial camera position, rotation, and field of view.
Viewpoint makes a perspective projection (objects further away are smaller),
OrthoViewpoint makes an orthographic projection.
You can even animate their transformation and properties, to animate the camera.
Note: In Castle Game Engine you can also control the camera by Pascal code,
Viewport.Camera property that keeps a
See manual about controlling the camera.
Still, this X3D node is useful to set initial camera through e.g. Blender
(you can export to glTF or X3D and importing them will set initial camera properly).
view3dscene displays a nice menu allowing you to jump to any defined viewpoint, showing viewpoints' descriptions. Animating viewpoint's position and orientation (directly or by animating it's parent transformation) also works perfectly.
Note that merely adding a
OrthoViewpoint) node to the X3D model, with everything at default, changes how view3dscene and CGE interpret the model.
OrthoViewpoint), we determine center of rotation (important for proper "Examine" work) based on scene contents (bounding box middle).
OrthoViewpoint), we assume you have set proper
centerOfRotation. The default
centerOfRotation is just (0,0,0). This follows X3D standard.
You can set
true to explicitly request to automatically determine (based on bounding box middle) this center of rotation.
This field is a CGE extension.
TODO: We support most, but not all, X3D fields.
Fields not implemented yet:
As for animating viewpoints (and also possible
We do not support right now the notion of preserving user offsets
from navigation. Tracking them in the past required to have a special
treatment of camera transformation (initial vs current),
but it was too complicated too keep (as we wanted to make
TCastleCamera descend from
and it didn't seem useful for authors in reality. (Of course please report
if it is useful for you!)
When you animate the viewpoint (either by animating viewpoint position/orientation or by animating viewpoint transformation) right now we just change the current camera to match the viewpoint. User offsets are not retained.
Controls the navigation behavior (mode of movement, gravity, etc.) and the headlight.
Note: In Castle Game Engine you can also control the navigation by Pascal code. See manual about navigation. And you can control the headlight by just adding lights as camera children. Still, this node is useful to define defaults.
Details about supported fields:
avatarSize is honoured fully:
avatarSize item is the camera radius.
If you use view3dscene,
--camera-radius command-line option overrides
avatarSize item is the preferred height
above the ground.
is the tallest object over which you can climb.
If this is missing (or it has value <= 0) then there's no such limit, and you can climb as long as you can move forward. So you can climb the stairs with steps almost as high as your own height minus the camera radius. Simplifying (ignoring other effects, like head bobbing), you can say that avatarSize is by default like avatarSize - avatarSize).
See TCastleWalkNavigation.ClimbHeight API docs for more details about this.
speed field is supported, it sets
the speed in meters/second. Speed = 0.0 is also correctly
honored (user will not be able to move in Walk/Fly modes,
only to rotate).
typefield is supported. Navigation types fully supported are:
NONE. Inside the engine, the navigation paradigm is actually a little more flexible. You can fine-tune the rotations and gravity behavior by view3dscene Navigation -> Walk and Fly Settings menu.
As an extension, we also support new navigation mode
This is similar to the Examine mode, with controls comfortable
for viewing models that have a sense of floor/ground in the XZ plane,
and vertical axis in +Y. Implementation is not finished yet.
The presence of navigation type
ANY is ignored by
We always show controls to change navigation settings, hiding them
feels harmful to user.
Nice transitions between viewpoints are supported,
and (since view3dscene 3.13.0) making
See demo model navigation/transition_multiple_viewpoints.x3dv showing how to use it to make an animated transition between a couple of viewpoints.
and changing their exposed fields by events, of course works.
NavigationInfo node is present in the scene:
speedare calculated based on scene's bounding box sizes, to a values that will hopefully "feel right". We try to calculate them intelligently, because simply using
NavigationInfodefaults results in bad experience in many scenes.
headlightbehaves like true,
[EXAMINE, ANY], this follows
visibilityLimit may be ignored if shadow
volumes are allowed (We use frustum with z-far in infinity then.)
Allows to define various versions of the same object, with varying level-of-detail. An appropriate child is automatically displayed based on the current distance to the camera.
Note: Right now, the only thing that decides
"which level of detail should be used"
is the distance to the camera.
Which means that only the supplied
LOD.range controls which level is displayed.
forceTransitions value is simply ignored,
range is empty, we simply always use the first
The children of this node are automatically aligned with the camera. Two modes are possible: where the objects are rotated only around a specified axis, or where objects are rotated freely to match the camera.
Allows to define a simpler geometry for collision purposes, or even to turn the collisions off (like a fake wall hiding a secret room in games).
Most things work: grouping (
children property, in particular),
allows to control collision detection by honoring
collide in VRML 97) and
bboxCenter/Size is currently simply ignored, our engine
always calculates and updates the bounding boxes where needed.
TODO: collideTime and isActive out events are not implemented yet.
You can use this to create submenus in "Viewpoints" menu in
children are taken into account.
Also, you can use this node to hide some viewpoints from the menu:
displayed field also works.
TODO: size/center is not honored yet. Group is displayed
regardless of camera position. A possible workarond could be
to use a
ProximitySensor.isActive to the
Except this workaround will not work too, because changing
displayed field after the scene loading
doesn't change the menu for now.
TODO: retainUserOffsets is ignored.