Solium - personal research and development

DaveTheCoder

xyz No it didn't. You're using operator == on floating point numbers.

Proper replacements:
https://docs.godotengine.org/en/4.5/classes/class_%40globalscope.html#class-globalscope-method-is-equal-approx
https://docs.godotengine.org/en/4.5/classes/class_%40globalscope.html#class-globalscope-method-is-zero-approx

xyz It's like chanting for bugs to come to you in the future.

😆

kuligs2

DaveTheCoder

THanks for noticing,

As you can see one is rotation and the other is input dir.. copy paste error

	# DEBUG VALUES ON SCREEN
	var vel = "Velocity len: %.2f" % velocity.length()
	debug_ui.update_label("velocity",vel)
	var inpt_dir_string = "Input dir: %.2v" % input_dir
	debug_ui.update_label("inputdir",inpt_dir_string)
	var rotation_y_string = "Input dir: %.2v" % rotation

xyz As I said. No rotations, no atans. Work directly with a basis that stores the orientation at all times. Deducing orientation from velocity is not wise in any case.

Ill see what i can come up with today..

xyz It's like chanting for bugs to come to you in the future.

Yes that happens to me alot, but its not like im chanting on purpose..
debug_ui.update_label("rotation_y",rotation_y_string)

kuligs2

Asked a duck to fix for me, but it dont work as i wanted it to.. back to square one..

Atleast didnt waste too much time "prompting", interesting that the character material changes when transforms are working..

kuligs2

OK so something like this?

func _physics_process(delta: float) -> void:

	input_dir = Input.get_vector("action_move_left", "action_move_right", "action_move_forward", "action_move_backward")
	direction = (player_camera.transform.basis * Vector3(input_dir.x, 0, input_dir.y)).normalized()

	if direction:
		var up := Vector3.UP
		# Recompute orthonormal basis: forward, right, up
		var forward := -direction   # Godot's Basis.forward is -Z (so basis.z = -forward)
		var right := up.cross(forward).normalized()
		var corrected_up := forward.cross(right).normalized()
		var target_basis := Basis(right, corrected_up, forward).orthonormalized() 
		
		# Convert basis to quaternion, keep in mind scale is lost
		var a = transform.basis.get_rotation_quaternion()
		var b = target_basis.get_rotation_quaternion()
		# Interpolate using spherical-linear interpolation (SLERP).
		var c = a.slerp(b,0.2) # find halfway point between a and b
		# Apply back
		transform.basis = Basis(c).orthonormalized()

Idk.. feels not right.. no errors.. but playing feels too slippery..

xyz

kuligs2 Do you rotate character body or the rig? Or both? Ideally, you don't want to rotate the body, only the visual representation.

And that code looks vibe coded. You don't really need to use quaternions. Godot can interpolate bases. You also should always use global basis. transform.basis is Godot 3 code. Godot 4 exposes basis directly. Spend more time with Transform3D class reference and less with prompting.

Oh and interpolation towards wanted basis should happen always, not only when controls are held down. Otherwise the interpolation may stop halfway when player releases the controls. It should also be framerate independent.

kuligs2

xyz funny you say "vibe coded", its actually from godot documentation.. https://docs.godotengine.org/en/4.5/tutorials/3d/using_transforms.html#interpolating-with-quaternions i guess they use vibers to create docs. no wonder its sometimes not too clear to understand. The quternion class was giving me erros and error said i need to use get rotation so i modified that part.

And i apply these transforms on Character3D node, why would i want to rotate only visual node? How the hell would i move the character node if only visuals are moving?

kuligs2

kuligs2 And i cannot set the transform all the time because, if direction is zero then it throws me errors.

if direction:
		var up := Vector3.UP
		# Recompute orthonormal basis: forward, right, up
		var forward := -direction   # <-----------------------------------------------------------------
		var right := up.cross(forward).normalized()
		var corrected_up := forward.cross(right).normalized()
		var target_basis := Basis(right, corrected_up, forward).orthonormalized()

xyz

kuligs2 And i apply these transforms on Character3D node, why would i want to rotate only visual node? How the hell would i move the character node if only visuals are moving?

Only move character body, only rotate visual representation. But this is not issue here.

xyz

kuligs2

var global_basis_wanted: Basis = global_basis

func _physics_process(dt):
	
	# get input vector
	var input_dir = Input.get_vector("action_move_left", "action_move_right", "action_move_forward", "action_move_backward")

	if not input_dir.is_zero_approx():
		# input vector in 3d
		var input_dir_3d = Vector3(input_dir.x, 0.0, input_dir.y)
		# project input vector onto camera global basis to get movement direction in global space
		var direction = (player_camera.global_basis * input_dir_3d)
		# horizontalize movement diretion by projecting it to horizontal plane
		direction = direction.slide(Vector3.UP).normalized()
		# build wanted orientation basis
		global_basis_wanted = Basis(Vector3.UP.cross(-direction), Vector3.UP, -direction).orthonormalized()
	
	# interpolate curent basis towards wanted basis
	global_basis = global_basis.slerp(global_basis_wanted, INTERP_SPEED * dt)
	# normalize the basis to avoid floating point error accumulation
	global_basis = global_basis.orthonormalized()

Short version:

var global_basis_wanted := global_basis

func _physics_process(dt):
	
	var input = Input.get_vector("move_left", "move_right", "move_forward", "move_backward")

	if not input.is_zero_approx():
		var dir = (player_camera.global_basis * Vector3(input.x, 0.0, input.y)).slide(Vector3.UP)
		global_basis_wanted = Basis(Vector3.UP.cross(-dir), Vector3.UP, -dir).orthonormalized()
	
	global_basis = global_basis.slerp(global_basis_wanted, dt * INTERP_SPEED).orthonormalized()

Remove the prefix "action" from action names. Action names are always used in context, so why state the obvious and make your code needlessly verbose and repetitive.

kuligs2

xyz So this code should rotate the visual node, right? It seems that its almost what i had already, only you check if input dir, while i check if direction.. why i use direction is because sometimes character might be in air or have inertia.. ill try your solution and report back. Thanks.

Also:

xyz Remove the prefix "action" from action names. Action names are always used in context, so why state the obvious and make your code needlessly verbose and repetitive.

I have it renamed because i have custom keybinds that are bound in code. Leaving the default names would conflict with the default project settings, which i dont want to touch, because those are defined usually through UI and after months of work i tend to forget where i have bound what button. Having a script that autoloads and rebinds "My actions" to the keys i have defined is much more reliable way to not get bugs later ..
Maybe the defaults are named differently, but thats besides the point, naming dont matter atm.

Here is my autoload

input_actions.gd

extends Node

var key_controls = {
				"action_move_right": [KEY_RIGHT, KEY_D],
				"action_move_left": [KEY_LEFT, KEY_A],
				"action_move_forward": [KEY_UP, KEY_W],
				"action_move_backward": [KEY_DOWN, KEY_S],
				"action_jump": [KEY_SPACE],
				"action_crouch": [KEY_CTRL],
				"menu_main": [KEY_ESCAPE],
				"tab_out": [KEY_TAB],
				"action_sprint": [KEY_SHIFT],
				"action_pickup": [KEY_E],
				"action_enemy_follow": [KEY_F],
				"action_savegame": [KEY_R],
				"action_loadgame": [KEY_T],
				}
var mouse_controls = {
				"action_mouse_left": [MOUSE_BUTTON_LEFT],
				"action_mouse_right": [MOUSE_BUTTON_RIGHT],
				"action_mouse_middle": [MOUSE_BUTTON_MIDDLE],
				"action_mouse_w_up": [MOUSE_BUTTON_WHEEL_UP],
				"action_mouse_w_down": [MOUSE_BUTTON_WHEEL_DOWN],
				}

func _ready():
	add_key_inputs()
	add_mouse_inputs()
	pass # Replace with function body.

# Called every frame. 'delta' is the elapsed time since the previous frame.
func _process(_delta):
	pass

func _unhandled_input(_event):
	if Input.is_action_pressed("menu_main"):
		# Quits the game
		get_tree().quit()
	if Input.is_action_pressed("tab_out"):
		# Quits the game
		if Input.mouse_mode == Input.MOUSE_MODE_CAPTURED:
			Input.mouse_mode = Input.MOUSE_MODE_HIDDEN
		else:
			Input.mouse_mode = Input.MOUSE_MODE_CAPTURED
	pass

func create_key_action(action_name:String,keycode:int):
	InputMap.add_action(action_name)
	var k = InputEventKey.new()
	k.keycode = keycode
	InputMap.action_add_event(action_name,k)
	pass

func add_key_inputs():
	var ev
	for action in key_controls:
		if not InputMap.has_action(action):
			InputMap.add_action(action)
		for key in key_controls[action]:
			ev = InputEventKey.new()
			ev.keycode = key
			InputMap.action_add_event(action, ev)
			
func add_mouse_inputs():
	var ev
	for action in mouse_controls:
		if not InputMap.has_action(action):
			InputMap.add_action(action)
		for key in mouse_controls[action]:
			ev = InputEventMouseButton.new()
			ev.button_index = key
			InputMap.action_add_event(action, ev)

kuligs2

xyz var global_basis_wanted: Basis = global_basis

func _physics_process(dt):

# get input vector
var input_dir = Input.get_vector("action_move_left", "action_move_right", "action_move_forward", "action_move_backward")

if not input_dir.is_zero_approx():
	# input vector in 3d
	var input_dir_3d = Vector3(input_dir.x, 0.0, input_dir.y)
	# project input vector onto camera global basis to get movement direction in global space
	var direction = (player_camera.global_basis * input_dir_3d)
	# horizontalize movement diretion by projecting it to horizontal plane
	direction = direction.slide(Vector3.UP).normalized()
	# build wanted orientation basis
	global_basis_wanted = Basis(Vector3.UP.cross(-direction), Vector3.UP, -direction).orthonormalized()

# interpolate curent basis towards wanted basis
global_basis = global_basis.slerp(global_basis_wanted, INTERP_SPEED * dt)
# normalize the basis to avoid floating point error accumulation
global_basis = global_basis.orthonormalized()

Also, after you have walked in a direction, the velocity does not reset back to 0 and the character keeps sliding when there is no input.

	if not input_dir.is_zero_approx():
		# input vector in 3d
		var input_dir_3d = Vector3(input_dir.x, 0.0, input_dir.y)
		# project input vector onto camera global basis to get movement direction in global space
		direction = (player_camera.global_basis * input_dir_3d)
		# horizontalize movement diretion by projecting it to horizontal plane
		direction = direction.slide(Vector3.UP).normalized()
		# build wanted orientation basis
		global_basis_wanted = Basis(Vector3.UP.cross(-direction), Vector3.UP, -direction).orthonormalized()
		
	else:
		velocity.x = move_toward(velocity.x, 0.0, speed)
		velocity.z = move_toward(velocity.z, 0.0, speed)

Also, i dont get why dont you need to rotate no the whole character3d node but only visual node?

xyz

kuligs2 So this code should rotate the visual node, right?

No, it rotates whatever you want it to rotate. You can just use it in your current setup where you rotate the whole body. I was just saying that rotating the representation only is a better option, for reasons I won't go into now but you may encounter them later. You can make properly functioning rig either way.

I wrote the example off the top of my head without testing it, so I might have left something out or made a typo or two. It was only meant to demonstrate how to handle the orientation in principle, not as a complete movement code. The main thing that you were conceptually missing with your current approach is this: update target basis only when there's input, but interpolate towards it always.

I can write you the full scaffold but you'll owe me a beer then and you won't learn as much 😉

xyz

kuligs2 naming dont matter atm

Naming always matters. It's one of the key things in programming.

xyz

kuligs2 Also, i dont get why dont you need to rotate no the whole character3d node but only visual node?

If you have a lathed collider like capsule, cylinder or sphere you gain nothing from rotating the body. Its orientation is irrelevant. Keeping its basis aligned with the world basis is less confusing. It introduces less entropy into the system.

If you insist on rotating it, what should its basis be aligned with; velocity or where the dude is looking? What would be the difference? There's none, so why bother rotating it in the first place.

kuligs2

xyz so why bother rotating it in the first place.

I havent tackled the weapons, but i would think that weapons would be part of the character node and its important where they are aiming in order to land a hit on target (melee).

But maybe attaching them to hand bone would negate this, idk.. im not expert in these things.. on first hand it makes sense to rotate character as It is what you want to do when moving in directions.

As for the update thing... well idk, why would i want to update the transform each frame even when its not moving? Isnt this just waste of processing resources? Thats how i was thinking, and for what it was it was working with my code. And it works with your code aswell, pretty much the same thing, only it updates the transform outside the conditional - if direction/input.

Feels wise the movement didnt change, maybe codewise it feels better? Idk. Thanks. Sure i understand that this was just an example snippet/concept.

xyz

kuligs2 As for the update thing... well idk, why would i want to update the transform each frame even when its not moving?

Eh, dude. Think! If the input vector is zero it doesn't mean the thing is not moving. You have smoothing/inertia/interpolation which does the moving. Technically, you can stop interpolating when the interpolation target is reached but then you constantly need to check whether the target is reached. You'll execute some code each frame either way so you may as well just interpolate always.

Try increasing your smoothing times and you'll see that if you interpolate only when there's input, your interpolation will inevitably stop halfway if you release the input quickly in the middle of interpolation.

You yourself earlier complained that is feels "sticky" or whatever when your code interpolated only if there is input. You want to interpolate whenever there's something left to interpolate, or to simplify the code - just do it at all times. The computational cost is negligible. You already do that with the velocity vector anyway.

xyz

kuligs2 but i would think that weapons would be part of the character node and its important where they are aiming in order to land a hit on target (melee)

Weapons have visual and non visual representations as well. Visual representation will follow player's visual representation and functional representation will do whatever it needs to do to sell the illusion of shooting, depending on game type and mechanics.

xyz

kuligs2 Here's the complete example. It lets you toggle all interpolation via a flag. You should first implement the logic in your system like that - without interpolation. When you get that working properly, add interpolation on top of it.
The orientation basis that's manipulated can be either body itself or just the visual representation. It doesn't really matter.

extends CharacterBody3D

@export var speed_max: float = 2.0
@export var move_inertia: float = 0.2
var speed_wanted: float = 0.0
var speed: float = 0.0
var move_dir: Vector3 = Vector3.ZERO

@export var orient_inertia: float = 0.3
@onready var basis_wanted: Basis = global_basis

@export var inertia_enabled: bool = true


func _physics_process(dt):
	var input = Vector2(Input.get_vector("left", "right", "up", "down"))
	if input.is_zero_approx():
		speed_wanted = 0.0
	else:
		move_dir = (%cam.global_basis * Vector3(input.x, 0.0, input.y)).slide(Vector3.UP).normalized()
		speed_wanted = speed_max
		basis_wanted = Basis(Vector3.UP.cross(-move_dir), Vector3.UP, -move_dir).orthonormalized()
		
	if inertia_enabled:
		global_basis = global_basis.slerp(basis_wanted, dt / orient_inertia).orthonormalized()
		speed = move_toward(speed, speed_wanted, dt / move_inertia)
	else:
		global_basis = basis_wanted
		speed = speed_wanted
		
	velocity = move_dir * speed

	move_and_slide()

That's all there is to it.

kuligs2

Tinkering more, ive noticed that there is a problem. Most notably when walking into a wall, the camera starts to spazz out, even tho its not colliding with anything.

Idk, why.. the camera setup is pretty much the same as per godot docs. Camera is inside the springarm3d and the springarm3d is inside another node you control to rotate it ..

Maybe its related to when character hits a wall, the speed is not zero, and that little oscilation is making the springarm to flop around too fast and so it spazzes out?

Also, ive been thinking, how to make sure when you hit a wall with character that you dont move the character in the direction of the wall or any other obstacle, not relying on the engine with just collision event that stops you from moving?

Or maybe there is another way to handle this?

Ofc i would want to be able to step over the ledges or ramps or something like that but if there is something that is above some pre determined height, i would like to stop, and not move/change state to walk, even tho the input is pressed.

My thought was to use is_on_wall() to check that, but not sure if that would solve the problem i face with the camera.

kuligs2

Interestingly when removing collision shape from SpringArm3D you dont get this effect. So i guess i fixed the camera..

In the past, since like godot 4.0, the camera would be clipping through the walls if the spring arm didnt have collision shape, now its other way around... smh..

Before i had this:

Characther still bobbs when you force input/direction against wall. But its not as violent as was before

« Previous Page Next Page »