Class TCastleWalkNavigation

Return Direction vector rotated such that it is orthogonal to GravityUp. This way it returns 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 Direction and GravityUp are parallel, this just returns current Direction — because in such case we can't project Direction on the horizontal plane.

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

Set the most important properties of this navigation, in one call. Sets initial camera properties (InitialPosition, InitialDirection, InitialUp), sets current camera properties to them (Position := InitialPosition and so on).

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

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.Init, and set 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 Position 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 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.

If PreferGravityUpForRotations or PreferGravityUpForMoving then various operations are done with respect to GravityUp, otherwise they are done with respect to current 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 calls Up will be gradually fixed, so that Direction and Up and GravityUp are on the same plane. Also 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 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 Up, and next horizontal rotation will be done versus new 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 Direction, and also between -GravityUp and 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 Direction length. 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 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. Updated by using Height call. For normal TCastleNavigation descendants, this means using OnInternalHeight callback, which is handled by TCastleViewport if you assigned TCastleViewport.Navigation to this navigation.

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.

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.

Rotation keys speed, in radians per second.

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 Input).

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 uses OnInternalHeight 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 Position above the ground on PreferredHeight height.

• When current height is too small — Position 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.