Is it possible to log continuous data?

[A-Ivan]

Hi Adam,

First of all, great framework.

Is it possible to log continuous data with this framework? For instance if I want to log, every frame or at specific frequency or every x seconds, the position and rotation of a GameObject (say the user's HMD in a VR study)?

Similar to what is done in UXF's framework: https://github.com/immersivecognition/unity-experiment-framework/wiki/Tracker-system

https://github.com/immersivecognition/unity-experiment-framework

Thank you.

[AdamBebko]

Hi A-Ivan,

There's been a few people requesting that. And we've needed it for a couple projects as well. In the "Extras" folder of the bmlTUX package, there's a script called "Tracker" that is a basic implementation of this functionality. This is by no means polished off, but it's the base that I start from when I need such functionality. It should help you get started.

It's definitely on my radar to polish off a bit more carefully, but time is always the enemy. If you run into things that are missing with that script please let me know so when I have a chance to tackle it I can add it into the clean version.

Or if you make a nice version of it, feel free to submit it to be included in bmlTUX!

[AdamBebko]

One note to keep in mind, is that Unity basically caps your recording rate at the frame rate, which can be very imprecise, and can also vary considerable frame-to-frame. If you need more precise measurements, or accuracy greater than your framerate, there's a group at York University that developed a package that's great for hooking up external timers and trackers etc. It's called USE https://www.biorxiv.org/content/10.1101/434944v2.full?versioned=true

[A-Ivan]

Hi @AdamBebko

Great to know there is already a basic implementation, I will look into that. Do you know if there is an impact on framerate if multiple gameobjects are tracked using this "Tracker" script? I imagine that each of these tracked objects generates its own csv file and managing these each frame plus the main trial csv file at the end of the trial may impact the system.

Thanks for the note on the USE system, I heard of it but I haven't looked deeply into it yet, I think I won't need that level of precision just yet, but something good to keep in mind.

[AdamBebko]

In my experience, any computer able to run VR should be able to do this tracking on several game objects with no impact at all. My computer has an M2 SSD though, that might help. I ran an experiment that was tracking around 40 at the same time using a script not to different from this, and it didn't seem to affect anything. If you have a slower drive, I could potentially see some issues, so you might want to have objects alternate frames for tracking if you don't need the every-frame resolution. Maybe use something like this (pseudocode)

Say you have 2 objects, only write only one of them every frame

[SerializedField] int FrameToWrite = 0 or 1 (different for each tracked object)

if )modulus of frame#/2) == FrameToWrite then saveTracker()

then on any given frame only one of them would update its tracker.

[AdamBebko]

Another option is just to store data in RAM, and write at the end of the run.

[A-Ivan]

Interesting that you tracked 40 objects and didn't have a problem. I'll have to do a test and see, but it may not be an issue. Placing this on the LateUpdate may also help, I would need to test to see if there is any difference on framerate though.

UXF mentioned in their paper that they run the continuous data logging on a different thread than the main thread to overcome any issues with this, but I'm not sure exactly how that was implemented.

The RAM idea is also an option, maybe use a buffer and write to the file whenever a max amount of RAM has been used, just to be safe that storing too much data on memory won't impact the actual memory needed for the study itself.

The Toggle Toolkit used this buffer idea in their script, might be something to keep in mind - https://link.springer.com/article/10.3758/s13428-020-01510-4 https://github.com/kim-dotcom/toggleScript/blob/master/PathScript.cs

[AdamBebko]

I suspect you’re worrying too much about performance :). Each float only takes ~4 bytes. Even storing a million frames of a vector3 would only be ~12 Megabytes. It’s pretty tough to fill up 8+GB of ram with just a bunch of numbers. And considering modern hard drives can write at around a GB/s. But the real world is always a bit different than ideals. Only way is to test!

On Sep 28, 2021, at 2:28 PM, A-Ivan @.***> wrote:

Interesting that you tracked 40 objects and didn't have a problem. I'll have to do a test and see, but it may not be an issue. Placing this on the LateUpdate may also help, I would need to test to see if there is any difference on framerate though.

The RAM idea is also an option, maybe use a buffer and write to the file whenever a max amount of RAM has been used, just to be safe that storing too much data on memory won't impact the actual memory needed for the study itself.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BioMotionLab/TUX/issues/32#issuecomment-929516066, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKKFU43UDJWKMK2626I5DOLUEICNVANCNFSM5E4BATKQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[A-Ivan]

Yeah, that may be it :)

I'll test it out and see, this may just not be an issue anymore these days.

[AdamBebko]

As mentioned in another ticket, I have made big progress on this issue in our own experiments, and a basic version of that will be included in bmlTUX v3

[AdamBebko]

related to: #35

[AdamBebko]

I have finished a basic implementation of a continuous recorder. Sorry it took so long, new job is taking up all my time. And optimizing it for useable science was a bit difficult, since I wanted it to be able to be played back too. I've settled on a hybrid system.

JSON recordings are playback-able, but the recorder can also output CSV files that are more human- and stats- readable. The CSV files cannot be played back, so the JSON must be saved if playback is required.

Basically, it includes a Transform recorder component, and is extensible for any MonoBehaviour Component.

I just need to write up some documentation, but it's ready for inclusion in the package.

[A-Ivan]

No worries, I know how it is.

This is great. So basically there will be an option somewhere to choose if I want to only export a CSV file or export a CSV and a JSON file?

If there is anything I can do to help, let me know.

[AdamBebko]

No worries, I know how it is.

This is great. So basically there will be an option somewhere to choose if I want to only export a CSV file or export a CSV and a JSON file?

If there is anything I can do to help, let me know.

I really appreciate all the new feature requests and suggestions, but I fear I won't have the time to address all of them. If you want to submit pull requests, please feel free to! :D I can list you as a contributor in the author sections!

[A-Ivan]

Sure, I can work on some of them. There are some things I might need your help with, at least on knowing where things are.

For instance, in what script/object can I get access to the design file data? Both so I can add a button to its inspector and to access the variables (name, type, values) that the user has created?

Are you following any specific syntax/convention for naming variables/functions?

Should I always first make sure my pull requests are up to date with the main branch before I commit changes? Any other information I should know?

[AdamBebko]

Let’s move this to the discussion section. Why don’t you pick a feature you’d like to work on first and let me know there, and I can give you some pointers on how to move forward, and where to look. Maybe start with something smaller than design files :D those are the most complicated part of bmlTUX and is where most of the “Magic” happens behind the scenes.

Adam

On Jan 20, 2022, at 12:18 PM, Ivan Aguilar @.***> wrote:

Sure, I can work on some of them. There are some things I might need your help with, at least on knowing where things are.

For instance, in what script/object can I get access to the design file data? Both so I can add a button to its inspector and to access the variables (name, type, values) that the user has created?

Are you following any specific syntax/convention for naming variables/functions?

Should I always first make sure my pull requests are up to date with the main branch before I commit changes? Any other information I should know?

— Reply to this email directly, view it on GitHub https://github.com/BioMotionLab/TUX/issues/32#issuecomment-1017735954, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKKFU466EKQWAQ426VFHMV3UXA7WZANCNFSM5E4BATKQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.

[A-Ivan]

I created some discussion posts on some of the easier topics to start.

[AdamBebko]

Pushed to dev branch awaiting release