Class TCastleWalkNavigation

Return Camera.Direction vector rotated such that it is orthogonal to GravityUp. This way it returns Camera.Direction projected on the gravity horizontal plane, which neutralizes such things like raising / bowing your head. Result is always normalized (length 1).

Note that when Camera.Direction and GravityUp are parallel, this just returns current Camera.Direction — because in such case we can't project Camera.Direction on the horizontal plane.

Warning: this symbol is deprecated: use Viewport.Camera.SetWorldView, and set GravityUp, PreferredHeight, Radius and call CorrectPreferredHeight manually

Set the most important properties of this navigation, in one call. Sets camera properties (Translation, Direction, Up).

Given here AInitialDirection, AInitialUp, AGravityUp will be normalized, and AInitialUp will be adjusted to be orthogonal to AInitialDirection (see Camera.SetWorldView).

Sets also PreferredHeight and Radius. PreferredHeight may be adjusted to be sensible (by calling CorrectPreferredHeight(ARadius)). You can pass ARadius = 0.0 if you really don't want this PreferredHeight adjustment.

Warning: this symbol is deprecated: use Viewport.Camera.SetWorldView, and set GravityUp, PreferredHeight, Radius and call CorrectPreferredHeight manually

Alternative Init that sets camera properties such that an object inside Box is more or less "visible good". Sets InitialCameraXxx properties to make it look right, sets current CameraXxx properties to InitialCameraXxx. Sets GravityUp to the same thing as InitialUp. Sets also PreferredHeight to make it behave "sensibly".

If Falling, then this will force Falling to false without calling OnFallenDown. It's much like forcing the opinion that "camera is not falling down right now".

Note that if we will find out (e.g. in nearest Update) that camera is still too high above the ground, then we will start falling down again, setting Falling back to true. (but then we will start falling down from the beginning with initial falling down speed).

This is useful to call if you just changed Camera.Translation because e.g. the player teleported somewhere (or e.g. game levels changed). In this case you just want to forget the fact that camera was falling down — no consequences (like lowering player's health, fadeout etc.).

Returns just JumpMaxHeight * PreferredHeight, see JumpMaxHeight for explanation.

The PreferredHeight slightly modified by head bobbing and crouch. It can be useful for collision detection between camera and something.

This makes a visual effect of camera falling down horizontally on the ground. Nice to use when player died, and you want to show that it's body falled on the ground. This works by gradually changing Camera.Up such that it gets orthogonal to GravityUp.

Warning: this symbol is deprecated: use Viewport.Camera.UpPrefer

Change up vector, keeping the direction unchanged. If necessary, the up vector provided here will be fixed to be orthogonal to direction. See TCastleTransform.UpPrefer for detailed documentation what this does.

Correct PreferredHeight based on Radius and on current HeadBobbing.

Exactly what and why is done: if you do any kind of collision detection with some Radius, then you should make sure that RealPreferredHeight is always >= of your Radius, otherwise strange effects may happen when crouching or when head bobbing forces camera to go down.

Exactly, the required equation is

MinimumRealPreferredHeight :=
  PreferredHeight * CrouchHeight * (1 - HeadBobbing);

and always must be

MinimumRealPreferredHeight >= RealPreferredHeight

Reasoning: otherwise this class would "want camera to fall down" (because we will always be higher than RealPreferredHeight) but your OnMoveAllowed would not allow it (because Radius would not allow it).

This method will make sure that this condition holds by eventually adjusting (making larger) PreferredHeight. Note that for Radius = 0.0 this will always leave PreferredHeight as it is.

If PreferGravityUpForRotations or PreferGravityUpForMoving then various operations are done with respect to GravityUp, otherwise they are done with respect to current Camera.Up.

With PreferGravityUpForRotations, this affects rotations: horizontal rotations (Input_LeftRotate and Input_RightRotate) and rotations caused by MouseLook. Also vertical rotations are bounded by MinAngleFromGravityUp when PreferGravityUpForRotations.

Note that you can change it freely at runtime, and when you set PreferGravityUpForRotations from False to True then in nearest Update the Camera.Up will be gradually fixed, so that Camera.Direction and Camera.Up and GravityUp are on the same plane. Also Camera.Direction may be adjusted to honour MinAngleFromGravityUp.

With PreferGravityUpForMoving, this affects moving: horizontal moving (forward, backward, strafe), and vertical moving (Input_Jump and Input_Crouch when Gravity is False). E.g. when PreferGravityUpForMoving then forward/backward keys are tied to horizontal plane defined by GravityUp. When not PreferGravityUpForMoving then forward/backward try to move you just in the Camera.Direction. Which is usually more handy when e.g. simulating flying.

• When there is no "natural" up-or-down feeling in the scene, e.g. outer space environment without any gravity, then you may set PreferGravityUpForRotations as False and you should leave PreferGravityUpForMoving and Gravity to False.

• With PreferGravityUpForRotations the "feeling" of GravityUp is stronger. Raising/bowing the head doesn't mess with "the general sense that there's some vertical axis independent of my movement, that doesn't change, and affects how I move".

  Without PreferGravityUpForRotations, we quickly start to do rotations in an awkward way — once you do some vertical rotation, you changed Camera.Up, and next horizontal rotation will be done versus new Camera.Up.

  If your GravityUp is good, then you generally should leave PreferGravityUpForRotations to True. Unless you really want the player to feel movements as "awkward", e.g. when you want to simulate this "outer space without any gravity" feeling.

• If your GravityUp is good, then you generally should set PreferGravityUpForMoving just like Gravity.

  E.g. when the player is flying / swimming etc. he will probably prefer PreferGravityUpForMoving = False, because this way he will not have to press Input_Jump and Input_Crouch. Simply pressing Input_Forward and Input_Backward and doing rotations will be enough to move freely in 3D space.

  When gravity works, PreferGravityUpForMoving = True is better, otherwise player would unnecessarily try to jump when looking up.

This sets the minimal angle (in radians) between GravityUp and Camera.Direction, and also between -GravityUp and Camera.Direction. This way vertical rotations (like Input_UpRotate, Input_DownRotate) are "bounded" to not allow player to do something strange, i.e. bow your head too much and raise your head too much.

This is used only when PreferGravityUpForRotations is True and when it's <> 0.0.

This must be always between 0 and Pi/2. Value of Pi/2 will effectively disallow vertical rotations (although you should rather do this in a "cleaner way" by calling MakeClear on Input_UpRotate and Input_DownRotate).

Initial speed of falling down. Of course this is used only when Gravity is true.

Note that while falling down, the camera will actually fall with greater and greated speed (this adds more realism to the gravity effect...). Note that this is always relative to Camera.Direction length. Camera.Direction determines moving speed — and so it determines also falling speed. The default DefaultFallSpeedStart is chosen to be something sensible, to usually get nice effect of falling.

You can change it at any time, but note that if you change this while Falling is True, then you will not change the "current falling down speed". You will change only the falling down speed used the next time.

When falling down, the speed increases. Set this to 1.0 to fall down with constant speed (taken from FallSpeedStart).

Are we currently falling down because of gravity.

Make a nice dizzying camera effect when falling down. This adds temporary camera rotations simulating that you rotate randomly and helplessly when falling down.

Of course this is meaningfull only when Gravity works.

Note that changing it from True to False doesn't immediately "cancel out" this effect if it's currently in progress. It only prevents this effect from starting again.

When Gravity works and camera height above the ground is less than PreferredHeight, then we try to "grow", i.e. camera position increases along the GravityUp so that camera height above the ground is closer to PreferredHeight. This property (together with length of Camera.Direction, that always determines every moving speed) determines the speed of this growth.

How high can you jump ? The max jump distance is calculated as JumpMaxHeight * PreferredHeight, see MaxJumpDistance.

We are in the middle of a "jump" move right now.

Scales the speed of horizontal moving during jump.

How fast do you jump up. This is the time, in seconds, in takes to reach MaxJumpDistance height when jumping.

Is player crouching right now.

True when the effect caused by FallOnTheGround is stil in motion.

This is True when gravity works (that is Gravity is True), and player is standing stable on the ground. This is set in every Update.

You can use this e.g. to make some effects when player is on some special ground (standing or walking), e.g. hurt player when he's standing on some toxical ground.

See also

IsWalkingOnTheGround

This is True when gravity works (that is Gravity is True), and player is standing stable on the ground, and player is moving horizontally.

This is True when gravity works (that is Gravity is True), and player is standing stable on the ground, and player is moving horizontally. In other words, this is like "IsOnTheGround and (s)he's walking". This is set in every Update.

The intention is that you can use this to make some "footsteps" sound for the player.

Last known information about whether camera is over the ground.

These are updated continuously only when Gravity is True.

We do not (and, currently, cannot) track here if AboveGround pointer will be eventually released (which may happen if you release your 3D scene, or rebuild scene causing octree rebuild). This is not a problem for navigation class, since we do not use this pointer for anything. But if you use this pointer, then you may want to take care to eventually set it to Nil when your octree or such is released.

Warning: this symbol is deprecated: use Input_LeftRotate

Warning: this symbol is deprecated: use Input_RightRotate

Change the MoveSpeed.

Jumping and crouching (when Gravity = True) or flying up / down (when Gravity = False).

Move forward, just like Input_Forward would be pressed.

Move backward, just like Input_Backward would be pressed.

If True then all rotation keys (Input_RightRotate, Input_LeftRotate, Input_UpRotate, Input_DownRotate) will work 10x slower when Ctrl modified is pressed.

Do we check what key modifiers are pressed and do something differently based on it?

If True then all keys work only when no modifiers or only shift are pressed. Additionally when Ctrl is pressed (and AllowSlowerRotations) then rotation keys work 10x slower. Also Increase/DecreasePreferredHeight work only when Ctrl pressed. Other keys with other modifiers don't work. We allow shift, because to press character "+" on non-numpad keyboard (useful on laptops, where numpad is difficult) you probably need to press shift.

If False then all keys work as usual, no matter what modifiers are pressed. And rotation keys never work 10x slower (AllowSlowerRotations is ignored), also Increase/DecreasePreferredHeight are ignored.

Warning: this symbol is deprecated: use TCastleThirdPersonNavigation for real 3rd-person navigation

Horizontal rotation can rotate around a vector that is RotationHorizontalPivot units forward before the camera. This is a poor-mans way to implement some 3rd camera game. Note that when non-zero this may (for now) move the camera without actually checking OnMoveAllowed.

We may make a "head bobbing" effect, by moving the camera a bit up and down.

This property mutiplied by PreferredHeight says how much head bobbing can move you along GravityUp. Set this to 0 to disable head bobbing. This must always be < 1.0. For sensible effects, this should be rather close to 0.0, for example 0.02.

This is meaningfull only when TCastleWalkNavigation.Gravity works.

Controls head bobbing frequency. In the time of HeadBobbingTime seconds, we do full head bobbing sequence (camera swing up, then down again).

Note that if you do a footsteps sound in your game (see stPlayerFootstepsDefault or TMaterialProperty.FootstepsSound) then you will want this property to match your footsteps sound length, things feel and sound natural then. Also, often it sounds better to record two footsteps inside a single sound file, in which case the footstep sound length should be twice as long as this property. For example, record 2 steps inside a 1-second long footstep sound, and set this property to 0.5 a second (which is a default in fact).

The tallest height that you can climb only used when TCastleWalkNavigation.Gravity is True. This is checked in each single horizontal move when TCastleWalkNavigation.Gravity works. Must be >= 0. Value 0 means there is no limit (and makes a small speedup).

This is reliable to prevent user from climbing stairs and such, when vertical walls are really vertical (not just steep-almost-vertical).

It's not 100% reliable to prevent player from climbing steep hills. That's because, depending on how often an event processing occurs, you actually climb using less or more steps. So even a very steep hill can be always climbed on a computer with very fast speed, because with large FPS you effectively climb it using a lot of very small steps (assuming that FPS limit is not enabled, that is CastleWindow.TCastleApplication.LimitFPS or CastleControl.LimitFPS is zero).

Remember that user can still try jumping to climb on high obstactes. See TCastleWalkNavigation.JumpMaxHeight for a way to control jumping.

For a 100% reliable way to prevent user from reaching some point, that does not rely on specific navigation settings, you should build actual walls in 3D (invisible walls can be created by Collision.proxy in VRML/X3D).

Rotation keys speed, in radians per second.

Moving speeds. MoveHorizontalSpeed is only for horizontal movement, MoveVerticalSpeed is only for vertical, and MoveSpeed simply affects both types of movement. Effectively, we always scale the speed of movement by either MoveHorizontalSpeed * MoveSpeed or MoveVerticalSpeed * MoveSpeed.

We move by distance MoveSpeed * MoveHorizontalSpeed (or MoveVerticalSpeed) during one second. So if you leave MoveHorizontalSpeed = MoveVerticalSpeed = 1 (as default), MoveSpeed expresses the speed in nice units / per second.

Default values for all these speed properties is 1.0, so you simply move by 1 unit per second.

Minimum and maximum values for possible MoveSpeed that user can make, using Input_MoveSpeedInc, Input_MoveSpeedInc. Note that code can still set MoveSpeed to any value, however small or large, these limits only apply to user changing speed by Input_MoveSpeedInc, Input_MoveSpeedInc.

Speed (radians per pixel delta) of rotations by mouse dragging. Relevant only if niMouseDragging in Input, and MouseDragMode is mdRotate or mdWalk. Separate for horizontal and vertical, this way you can e.g. limit (or disable) vertical rotations, useful for games where you mostly look horizontally and accidentally looking up/down is more confusing than useful.

Moving speed when mouse dragging. Relevant only when (MouseDragMode is mdWalk) and (niMouseDragging in UsingInput).

What mouse dragging does. Used only when niMouseDragging in Input.

This unlocks a couple of features and automatic behaviors related to gravity. Gravity always drags the camera down to -GravityUp.

Summary of things done by gravity:

• It performs collision detection with parent TCastleViewport to get camera height above the ground.

• It allows player to jump. See Input_Jump, IsJumping, JumpMaxHeight, JumpHorizontalSpeedMultiply.

• It allows player to crouch. See Input_Crouch, CrouchHeight.

• It tries to keep Camera.Translation above the ground on PreferredHeight height.

• When current height is too small — Camera.Translation is moved up. See GrowSpeed.

• When current height is too large — we're falling down. See Falling, OnFall, FallSpeedStart, FallSpeedIncrease, FallingEffect.

• It does head bobbing. See HeadBobbing, HeadBobbingTime.

While there are many properties allowing you to control gravity behavior, most of them have initial values that should be sensible in all cases. The most important property you need to set yourself is PreferredHeight. Everything else should basically work auto-magically.

Note that Gravity setting is independent from PreferGravityUpForRotations or PreferGravityUpForMoving settings — PreferGravityUpXxx say how the player controls work, Gravity says what happens to player due to ... well, due to gravity.

Height above the ground, only used when TCastleWalkNavigation.Gravity is True. The Camera.Translation tries to stay PreferredHeight above the ground. Temporarily it may still be lower (e.g. player can shortly "duck" when he falls from high).

This must always be >= 0. You should set this to something greater than zero to get sensible behavior of some things related to TCastleWalkNavigation.Gravity.

See CorrectPreferredHeight for important property of PreferredHeight that you should keep.

Preferred height when crouching. This is always mutiplied to PreferredHeight. This should always be <= 1 (CrouchHeight = 1 effectively disables crouching, although it's better to do this by calling MakeClear on Input_Crouch).