Very simple all-round camera controller. Weird jamming.

It's time for me to ask some questions here. The question is purely academic. I was making a simple all-round camera controller. I encountered a strange behavior. If you raise the camera as much as possible, it jams at the top. And it happens strictly in the height range from 1.564 to 1.746 (high_max). Of course, I invented a hack and rewrote it with a different approach, but I'm curious — is there a materialistic explanation for this mysterious phenomenon?

Godot_v4.3-beta1

extends Node3D


@onready var tilt = $Camera_orbit
@onready var zoom = $Camera_orbit/Camera

@export var high_max := 1.62 # Jamming at 1.564 to 1.746. At these values, add "- 0.01" to line 42.

var high_min := 0.0

var SENSITIVITY := 0.01


func _unhandled_input(event: InputEvent) -> void:
# Mouse R-button press for rotation.
	if event is InputEventMouseMotion and Input.is_mouse_button_pressed(MOUSE_BUTTON_RIGHT):
		tilt.rotation.y -= event.relative.x * SENSITIVITY

# Rotation clamp vertical.
		tilt.rotation.x = clamp(tilt.rotation.x - event.relative.y * SENSITIVITY, -PI/2, PI/6)

# Zoom W-mouse.
	elif event is InputEventMouseButton:
		match event.button_index:
			MOUSE_BUTTON_WHEEL_UP:
				if event.is_pressed():
					if zoom.position.z >= 0.3:
						zoom.position.z -= 0.1
			MOUSE_BUTTON_WHEEL_DOWN:
				if event.is_pressed():
					if zoom.position.z <= 2.0:
						zoom.position.z += 0.1

# Mouse M-button change height.
	elif event is InputEventMouseMotion and Input.is_mouse_button_pressed(MOUSE_BUTTON_MIDDLE):
# with jamming.
		if tilt.position.y >= high_min and tilt.position.y <= high_max:
			tilt.position.y += event.relative.y * SENSITIVITY
			if tilt.position.y < high_min:
				tilt.position.y = high_min
			if tilt.position.y > high_max:
				tilt.position.y = high_max# - 0.01
# w/o jamming.
		#tilt.position.y += event.relative.y * SENSITIVITY
		#tilt.position.y = clamp(tilt.position.y, high_min, high_max)

# Exit by ESC.
	if event is InputEventKey:
		if event.pressed and event.keycode == KEY_ESCAPE:
			get_tree().quit()

xyz Yes unless you cast your limit value to a 32 bit float beforehand, i.e. keep it as a Vector3 component.

My imagination is not working well at the moment, so I couldn't think of anything better:

@export var high_max_v3: = Vector3(0.0, 1.57, 0.0)

var high_max = high_max_v3.y

And, yeah, the jamming has stopped.

I always warn people that it will sneak and bite them in the ass sooner or later if they're not aware of how floating point works.

I already knew that trying to use a game engine to simulate real physics is naive and futile. Well this is an unnecessary confirmation of that. Games are not simulation, but only imitation.

But I mostly get waved off

I'll memorialize your warning

Actually, there are vague mentions of the problem in the documentation, but very nebulous and the proposed solution is not very elegant:

Note: Due to floating-point precision errors, consider using is_equal_approx instead, which is more reliable.

How risky is this code:

@export var high_min: = 0.0
@export var high_max: = 1.57

var high: = Vector2(high_min, high_max)

it is for separate input of vector components values. Then high.x and high.y will be compared component by component.

xyz If you continue to deal only with float32 numbers i.e. vector components

Yeah, that's right.

So that's the situation you need to watch out for.

Unfortunately, as I realized, programming is generally a field where you have to be extremely careful.

xyz if you redo your logic to eliminate this redundant check:

Yeah, I try to shorten the code as much as possible.

Which is exactly the same thing the clamp() does.

Using clamp() is of course shorter and more elegant, but now I wanted to understand the logic of setting and using vector components. And I think I almost understand it (or so it seems to me) with your help.

xyz than the most common issue of precision loss when converting between decimal and binary.

Just curious, do ternary logic computers have the same problem?