ive got no idea how it works, im not getting any wiser from that doc page :/

current state of my test level been doing mostly environment work, some sound design and added crouching. i got 2 more animated weapons finished but i need to figure out an inventory weapon switch first

@cybereality said: Looks amazing! Nice job.

tnx man! did u get a chance to look at the PhysicsRayQueryParameters3D? im stumbled by it

I got it working. It was kind of confusing and took me an hour. You probably wouldn't have got it.

extends Node3D

@onready var camera : Camera3D = get_node("PickCam")
@onready var ball : MeshInstance3D = get_node("Ball")

func _input(event):
	if event is InputEventMouseButton and event.pressed and event.button_index == 1:
		var ray_length = 1000.0
		var from = camera.project_ray_origin(event.position)
		var to = from + camera.project_ray_normal(event.position) * ray_length
		var space = get_world_3d().direct_space_state
		var phys = PhysicsRayQueryParameters3D.new()
		phys.from = from
		phys.to = to
		var result = space.intersect_ray(phys)
		if result.has("position"):
			ball.position = result.position
			print("position = " , result.position, " - normal = ", result.normal)

tnx ! will try it out tomorrow

i got it sort of working...

how to add a layer mask to the raycastQuery? cause now im also shooting at the player

the reticle screen position seems to be taken from the upper left corner, i cant seem to change this by messing with the GUI

and my decal instantiate code is wrong, im probably doing something wrong with the lookat from position code

const ray_length = 1000
@export var reticle_path: NodePath
@export var impact_normal : PackedScene
@export var force = 20.0
@export var damage = 50.0
@onready var reticle = get_node(reticle_path)

func firebullet():
	#it takes the left upper corner point of the reticle?
	var screen_pos = reticle.get_global_transform_with_canvas().origin
	var camera = self
	var from = camera.project_ray_origin(screen_pos)
	var to = from + camera.project_ray_normal(screen_pos) * ray_length
	var space = get_world_3d().direct_space_state
	
	var phys = PhysicsRayQueryParameters3D.new()
	phys.from = from
	phys.to = to
	var result = space.intersect_ray(phys)

	if result:
		var collider = result.collider
		var n = result.normal
		var p = result.position
		#print(p)
		#print(collider)
		#print(n)
		
		#this is a godot4 decal scene>
		var impact = impact_normal.instantiate()
		collider.add_child(impact)
		impact.global_transform.origin = p
		impact.look_at_from_position(p, p - n, Vector3.UP)
		
		if collider is RigidDynamicBody3D:
			collider.apply_impulse( p - collider.transform.origin , - self.global_transform.basis.z * force)

fixed collision mask

phys.collision_mask = 1

so the crosshair sprite is 64*64 do i need to subtract 32 from x and y of screen pos to get the dead center? or wont that work with screen scaling?

I'm in Miami for a week, for this AI conference, so I don't have access to my computer. Unless I can try to get Godot running on my Steam Deck, it's unlikely I can test anything.

@cybereality said: Unless I can try to get Godot running on my Steam Deck, it's unlikely I can test anything.

Isn't it available via steam?

@DJM said:

@Calinou said:

i need that subviewport bug fixed to make em look good

Have you tried scaling the weapon model in a non-uniform manner (to squish it towards the camera origin)? This can simulate a similar look without the performance implications of using a secondary viewport.

yes ive tried scaling on z axis to fake shorter FOV but that only looks good when the weapon isnt moving alot. for example when the weapon rotates upwards in an animation the scaling begins to look very weird(squashed) and noticable. also, it doesnt fix weapon world clipping

I've seen a trick where one uses a second camera that is closer to the weapon, and only letting the closer cam view the weapon. It will fake looking closer to the player.

@Nerdzmasterz said:

@DJM said:

@Calinou said:

i need that subviewport bug fixed to make em look good

Have you tried scaling the weapon model in a non-uniform manner (to squish it towards the camera origin)? This can simulate a similar look without the performance implications of using a secondary viewport.

yes ive tried scaling on z axis to fake shorter FOV but that only looks good when the weapon isnt moving alot. for example when the weapon rotates upwards in an animation the scaling begins to look very weird(squashed) and noticable. also, it doesnt fix weapon world clipping

I've seen a trick where one uses a second camera that is closer to the weapon, and only letting the closer cam view the weapon. It will fake looking closer to the player.

yes thats what i also usually do but the second cam and subviewport is currently broken godot4 alpha. but ive seen its fixed on github, so i hope it will be in the next alpha

Fair enough. I personally don't use bleeding-edge versions as they can be a bit buggy.

I enabled desktop mode, which is just KDE Linux. Godot runs fines, but it's impossible to get any work done without a mouse and a keyboard.

@cybereality said: I enabled desktop mode, which is just KDE Linux. Godot runs fines, but it's impossible to get any work done without a mouse and a keyboard.

no problem ive got time

@cybereality said: I enabled desktop mode, which is just KDE Linux. Godot runs fines, but it's impossible to get any work done without a mouse and a keyboard.

I would have thought that the touchpad would be at least borderline ok for mouse and testing the game on steamdeck one would likely rely more on the analogs. But the keyboard is likely a must yeah. So an usb-c dongle adapter and maybe one of those rubbery foldable keyboards might work? Something like this: https://www.amazon.com/Sungwoo-Foldable-Silicone-Keyboard-Waterproof/dp/B0179N39KS

The movement on the trackpad is good, but clicking is not. When you click, you press the touchpad, which makes it move slightly resulting in you clicking on something else (same with right-click). I have to look into it more, but it doesn't look like the scroll wheel works, either. You can make custom key bindings, someone on Twitter is working on it, so that may make it usable, the defaults are too hard to work with. And the keyboard is pretty good for a touch screen, it's just not ideal for coding.