I have a task that can be somewhat performance heavy but is not necessarily essential for it to update at a fixed frequency. Is there a way to determine how much time has elapsed in the current physics tick (i.e. how much time it has taken other nodes to perform _physics_process)? This way I can check whether I have enough time budget left to run the task or punt it to the next update.

    Get the initial time in ready() and the time per frame in process(), subtracted from both. Or set the time to 0 in ready() and increment it in process().

    kuligs2 My understanding is I cannot run it on another thread since it needs access to the physics space. If I'm wrong then great!
    Jesusemora Delta provides the timespan of the last physics tick. I need elapsed time of the current physics tick up to my desired _physics_process call

          tucono

          You mean something like that?

          func _physics_process(delta: float) -> void:
	var start = Time.get_ticks_usec()
	for i in 1000000:
		var a = sqrt(1493)
	var end = Time.get_ticks_usec()
	var total = end - start
	print(total)

          Or in milliseconds: get_ticks_msec()

              trizZzle That's not quite what I want.
              Say we have 4 nodes in our scene tree. At the start of the physics frame, my understanding is that the physics_process of each node is called in a sequence. So <node1>.physics_process() is called, then <node2>.physics_process(), <node3>.physics_process, and finally <node4>._physics_process().

              My performance-heavy processing is in node 4. However, the prior 3 nodes were doing work themselves, so the time budget I actually have to work with is (<physics_frame_time> - <node1_physics_time> - <node2_physics_time> - <node3_physics_time>).

              In other words, assuming 16 ms of total physics frame time with each prior node consuming 1 ms of time, my remaining time budget for <node4>._physics_process() is 12ms. So what I want is a way to determine how long every other node has taken in _physics_process prior to my performance-critical node so I can determine if I have enough cpu budget to run the calcs.

              Now, if I can reliably call the 3D world state in the physics server from another thread (with minimal blocking from any other thread polling the physics server), then I don't think I need to worry about my frame time budget for the node.

              • Toxe replied to this.

                  tucono A couple of thoughts.

                  First of all I don't think this is sustainable or even advisable. What if your scenes at some point in development or game state are so busy that there will never be enough time budget to run your expensive code?

                  And how do you know how long it will take to run?

                  Also keep in mind that _physics_process() is not like _process() and is not guaranteed to be called every single frame. It is totally possible that _physics_process() will be called 2 or 3 times in a row in a single normal frame and then not again for the next 2 frames.

                  Can you make this expensive code reentrant and then only do a little bit of work every physics frame instead of all at once? Then you could just slowly nibble away at it every frame.

                  If not then maybe you should just try running it for example every 30th or 60th physics frame (so roughly once a second) and if that physics frame takes a longer time then see if that is even noticable.

                  But if you really want to keep your initial idea: You can change the process_physics_priority so that you could have one node that acts as a kind of watchdog and has the highest priority and is guaranteed to get called first. That node could take the current time, knowing that this is when physics processing started. And then put your expensive code into a node that has the lowest priority so it will get called last. Then you could check how much time has passed and decide what to do.

                  But I have no idea if this priority is taken into account for the whole scene tree or if it only respected among the nodes of one scene.

                  https://docs.godotengine.org/en/latest/classes/class_node.html#class-node-property-process-physics-priority

                      Toxe I've already got a partitioning system across physics ticks to reduce the processing per tick. However, there's a remote chance (as you've said, when the scene is extremely busy) that I can't get the partition that I wanted completed while remaining within my time budget. While I can track how much of my current 'slice' I've accomplished thus far during a tick, I don't know how much has been processed prior and thus how much time I have left for everything else.
                      This does bring the question of whether I can force the node to be processed last, in which case I can ensure I don't leave any other critical task remaining while processing (although I'll still need a way to keep track of my time budget).

                      On the other hand, if the physics server can be called from a separate thread without blocking other threads, then I would be able to simply dedicate a thread to this task which bypasses worrying about all other _physics_process calls.