Right now, we do all the dt computation based on the timestamp of the last head tracker message, because of the recommendation of the vrj docs. However, there are a few issues here:
tracking not necessarily synced with frame rendering/lower resolution timing
can make things appear to stop working when real trackers stop sending messages (simulated ones always do, so that's no issue)
I think the primary reason for the vrj doc recommendation is the fact that input data is automatically cluster synchronized, so it's simple. However, esp. with vrj 3.0 syncing stuff across the cluster is not too tough.
Thus, I think it's worth it to make a clock object that grabs a good-resolution system clock on the primary node during preframe and is set up to be cluster-synced so that late preframe has a nicer dt.
In theory, this shouldn't be very vrjlua dependent, so might be better maintained in util-headers.
Right now, we do all the dt computation based on the timestamp of the last head tracker message, because of the recommendation of the vrj docs. However, there are a few issues here:
I think the primary reason for the vrj doc recommendation is the fact that input data is automatically cluster synchronized, so it's simple. However, esp. with vrj 3.0 syncing stuff across the cluster is not too tough.
Thus, I think it's worth it to make a clock object that grabs a good-resolution system clock on the primary node during preframe and is set up to be cluster-synced so that late preframe has a nicer dt.
In theory, this shouldn't be very vrjlua dependent, so might be better maintained in util-headers.