Framerate-independent tracking?

[JashoBell]

Hello,

I've been building a VR experiment with UXF, but have run into a potential issue implied by the title of this topic. I'm planning to use active markers (e.g., Optitrack, Worldviz PPT) to record positional data (e.g., reaching characteristics). Normally, these would sample at ~200 times per second, and much of the research I see using them holds to that standard. However, the rate at which position is sampled in Unity is tied to the framerate, with most HMDs running at 90fps.

Is there a way to decouple the sampling rate of the markers from the framerate, or sample a transform multiple times per frame? Alternatively, is my concern here overblown? Does it even matter?

I've spent a few days essentially spinning my tires in place trying to work out a solution to no avail. Coroutines evaluate once per frame, and other approaches (e.g., multithreading, the job system) don't allow me to access Unity methods (thus, the transform of the tracked object). However, I'm also relatively naive to Unity, so I thought I'd ask here.

Thanks,
Josh

[jackbrookes]

Hi Josh
I share your concerns - but don't really have a clear answer right now. I think it is theoretically possible, depending on the VR SDK you are using. For example, if you are using SteamVR, you may be able to call the underlying SDK functions that get the position of the hands, head or trackers from a different thread at a high frequency. To get around the Unity multithread limitations, you can add tracking data to a queue and evaluate it in a coroutine, and transform into Unity positions there. This is hypothetical, I think it would take a while to do this and is probably outside the scope of UXF since each SDK would require a different solution.

As to weather its needed - I guess it depends on your use case. For fast jerky movements, you can imagine 200, 500, 1000Hz being very useful. But for many experiments, 90Hz could be enough.

I recall there being some published experiments finding that ~100Hz is enough for most human movement data. Maybe @mwarb has an opinion?

Jack

[JashoBell]

I appreciate the quick response!

That's what I was starting to figure. Maybe possible, but a lot of work, SDK specific and almost definitely outside of my abilities at this stage.

I'll reach out to the company providing the marker-based tracking system to see if there's a simple way to access the positional data they're sending to Unity. For my present purposes I don't think I need them in the context of a Unity coordinate space, just in a form that I can calculate linear kinematics. So maybe I could set up a thread to sample those with time OnTrialBegin(), end it OnTrialEnd() and use UXF to add the values to a data frame? Might be a more tractable problem. But yeah, hypothetical.

Or, maybe I can use this to justify picking up the Valve Index and running it at 144hz.

I'd be interested in those publications if at hand, my Scholar-fu isn't working in this instance!

Thanks,
Josh

[JashoBell]

I ended up solving this problem! In short, I created a new Tracker class that alters a few of the methods from the parent class, opening up a separate thread during trials to sample position data from VRPN outside the Unity API. I put up an example at JashoBell/rapid-sampling-for-unity-experiments for anyone interested in navigating the same issue. It probably won't be plug and play, but hopefully will give a good head start. I might work to clean the project up over time, but that might not be for a few months. Let me know if I need to give credit to UXF differently than I am, I am very new to this.

[jackbrookes]

Looks great!