Camera orientation and character direction

xyz

fatalox You're constantly assuming that the player will move along individual x, y or z components. This is only true if the coordinate system is not rotated. Once you rotate it you're moving along whole 3d vectors so doing it component-wise makes no sense anymore.

front = Vector3(camera_basis.z.x, 0.0, camera_basis.z.z).normalized()
right = camera.basis.x.normalized()
velocity = (right * input.x + front * input.y) * 10

xyz

fatalox Here's the example with added orientation. Only a couple of lines are added to the player script. Wanted player basis is calculated and interpolated to.

cam-movement.zip

3kB

fatalox

xyz Thank you i learn so much by looking this, i try to understand, correct me if I'm wrong.
So first you declared the variable onready to avoid an error on the wanted basis:

@onready var wanted_basis: Basis = global_transform.basis

Then you created the basis (wanted basis) using for waned_basis.x the mathematical production cross:

if input.length_squared() > 0:
   # contruct target orientation basis for player
   wanted_basis.z = (input.x * right + input.y * front)
   wanted_basis.y = Vector3.UP
   wanted_basis.x = wanted_basis.y.cross(wanted_basis.z)

Here you normalized the bases on an orthogonal model

   wanted_basis = wanted_basis.orthonormalized()

Finally, you applied the transformation to the basis to orient the direction of the mesh.

   # interpolate towards wated basis
   global_transform.basis = global_transform.basis.slerp(wanted_basis, 10 * delta)

It works, more or less, I think there is still a problem of fluidity but I do not think it concerns this transformation but the orientation of the camera and the application of direction.
It seems to move a horse, and the problem I think is because the application of direction by camera:

func _input(event):
   if event is InputEventKey:
      if event.is_pressed() and not event.is_echo():
         var b = $"../cam_placer".global_transform.basis
	 right = b.x.normalized()
         front = Vector3(b.z.x, 0.0, b.z.z).normalized()

This part of code I think needs to work in physics process delta but without interfering with the basis of the model.
At this point am I forced to move the camera to another scene to achieve this result?
Can applied mathematics create other magic to this model?
For example, is it possible to lock the basis (after smooth rotation), on the respective x/z angles? (0°,45°,90°,135°,180°,240°,270°,315°)
So that there are not too many inaccuracies the movement\camera direction on movement?
Sorry, I seem to have opened a pandora's box and perhaps the result I am looking for is unrealistic.
It's actually fun!

xyz

fatalox Yeah you got it mostly right. There is a room for finesse and smoothing in the movement of both camera and player, but this is a matter of tuning the timing/interpolations and is for another topic. The demo in principle solves the original problem of figuring out movement axes and proper player behavior in respect to them.

Not sure I understand what you want from the camera. Currently it just reacts to mouse directly. Good enough for a demostration I think. You can play further with easing/constraining and see if you can get what you have in mind.

As for applying this to your case, you can try to replicate the scene structure from the demo in your actual project. The only difference would be replacing the player node with CharacterBody3d and perhaps containing it in a separate scene. Camera could be as in the demo. Just insert a spring arm in the setup to handle occluders.

xyz

fatalox Well my initial example updated it each frame but you stated that this is exactly what you DON'T want. Anyway you now have code examples for both so I'm sure you'll be able to figure it out.

Also note that movement direction and mesh orientation should be two separate things. So the player always moves instantly on correct axes and the movement is not actually affected by the gradual mesh orientation animation. That way there won't be any confusing delays.

fatalox

I do a bit of cleaning and assign the best response, adding the final result to the initial post.
Thank you @xyz for the big help.
The code is solid for a third-person game with free camera (it can be improved with animations, but now I'm quite satisfied).

« Previous Page