RayCast3D collision detection issue in simple demo scene

[ericsnekbytes]

Tested versions

Reproducible in Godot 4.3.stable.official, 77dcf97

System information

Godot v4.3.stable - Windows 10.0.22631 - Vulkan (Forward+) - dedicated Quadro T2000 - Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 Threads)

Issue description

This simple scene demonstrates using a RayCast3D on a "turret" to test for obstructions/line-of-sight to players (entire script and scene pictured below + attached) . Ray casting fails after the player's position has been modified, despite the player position and raycast target_position matching. If this is expected behavior, it will at least be nice to document and explain why this is happening, so that others can learn from it (possible related issue here)...

Steps to reproduce

Run the scene, look at the console output and confirm collision detection failures in part (B).

Minimal reproduction project (MRP)

Project attached (simple 1-script demo scene started from a blank project).

raycasttest.zip

[smix8]

All the force_raycast_update() does is updates the ray positions and casts a new ray to update all the Node internals. It can not force any update on the actual physics space.

[ericsnekbytes]

Can you elaborate? I would love to gain a deeper understanding (root causes and first principles, designing around this), but I don't know how to reason about this...so if you can share any conceptual model, or maybe any resources you know about that might help, that would be greatly appreciated...

I vaguely understand that the player's position in space is stale/not updated, but that's about it...

[smix8]

Nodes are just handles for convenience so users can click and poke something. They are not necessary in sync with what happens inside the actual servers that do all the work as nodes are usually just one-way command-pushers to servers.

Commands to a server are not executed immediately. Each server has its own sync point for commands and parks all user commands in a command queue to be consumed later.

In case of a RayCast3D node what they are is basically an expensive (because convenience has a cost) version of using PhysicsRayQueryParameters3D on the PhysicsDirectSpaceState3D.intersect_ray() function. When you do a force_raycast_update() on the node all you do is forcing an update of the parameters, you are still querying the same old physics space state.

The physics space state is only updated after the next PhysicsServer3D step and sync. The physics is a stepped process with its own sync points. So in scripts and physics_process() you just push update commands to physics to be executed later and that is why you can't change something about physics and expect an immediate result.

Physics is always stepped and delayed, that is just how a physics system works that needs to sync all the objects. You would need to use actual trigonometry function for line of sight checks without any delay instead of using physics.

[ericsnekbytes]

Thank you for taking the time to help and provide guidance :) From my own journeys through the docs, I'm only dimly aware of how the servers work, but your explanation is helpful in building up a mental model of how my _physics_process snippets actually execute. I'm left with some new questions (and maybe you or another dev can chime in...and I don't know if these questions are conceptually valid or not, just curious):

• I've avoided using RIDs and PhysicsDirectSpaceState3D so far because most of my needs have been met by the node-based APIs. Do you have any tips or other wisdom for interchanging/working with low level RIDs and the typical end user Nodes (like CharacterBody3D, CollisionBody3D etc.)?

• Is there a way to tell that all physics processing has finished? A signal, maybe, or some kind of post-processing step/call? Seems like there's been some discussion here...

• The command queue for physics that you mentioned, are there docs/diagrams for any of that, that you're aware of? Other than reading engine source, I haven't found anything like this (basically anything else you would care to share or muse about this subject I would love to read)...

Thank you, both <3 (@smix8 @AThousandShips ) !!

[smix8]

I've avoided using RIDs ...

The mentioned PhysicsRayQueryParameters3D object can be used with the PhysicsDirectSpaceState3D.intersect_ray() function without interacting directly with the server and RIDs. The PhysicsServer does not even have an exposed server API for ray queries, it is all wrapped inside the PhysicsDirectSpaceState3D.

You commonly use the parameters when node transform updates would be problematic, e.g. when you need to do a lot of raycasts in the same physics step or just dont want to clutter the SceneTree with so many extra raycast nodes.

Is there a way to tell that all physics processing has finished?

Physics processing is finished when the next _physics_process() gets called or the next SceneTree physics_frame signal gets emitted.
Or when _process() starts, because the frame related process() gets called after the physics loop is done for this iteration of the main loop.

The command queue for physics that you mentioned, are there docs/diagrams for any of that

Not really, that is so engine low-level that looking at the engine source code and flow becomes the better doc.