Tracker Mapped Rotation input under Devices is missing float3 inputs

[ohzee00]

Describe the bug?

When opening up the Device -> Trackers, the Mapped Rotation float3 input is not able to be seen.

Please look in additional context for possible factors.

To Reproduce

I can reproduce this on my machine but I am not aware of how this happened but for me I am:

1. Loading up Resonite with -ResetDash (to make sure no old settings or otherwise are affecting this, I have confirmed even with a saved dash this still persists)
2. Opening Settings -> Device -> Trackers list
3. Seeing that Mapped Rotations does not have any input

Expected behavior

For me to see a Mapped Rotation float3 in my device settings.

Screenshots

This is showing a userspace inspector that is focused on the Mapped Rotation datafeeditem, right above it is the Mapped Position datafeeditem, note that it does not have the same datafeed as Mapped Position despite both being float3s:

Resonite Version Number

2024.4.24.33

What Platforms does this occur on?

Windows

What headset if any do you use?

Desktop, Quest Pro

Log Files

DESKTOP-V75BHJO - 2024.4.24.1426 - 2024-04-25 08_06_40.log

Additional Context

I can reproduce this on my machine in the past few restarts, with and without trackers.

When I first booted up Resonite with the device settings I was able to see the Mapped Rotations setting, ironically I was booting up into Resonite this late into the night for a bug that involved the very same setting defaulting to 0, 0, 0 when opening it up in the settings menu.

The only thing that changed between the past session where it worked is that I didn't correctly turn off my Quest pro touch controller when booting into Steamlink, thus making it show up as a tracker that steamvr sees (even shows the same in Resonite settings as a tracker I can look at). I have made sure to restart steamvr/steamlink and correctly turn off that controller so it doesn't show up, however the problem persists.

Reporters

Ohzee

[5H4D0W-X]

I think the rotation is a floatQ even though its Euler representation is shown in an editor. The UI is simply missing a template for a floatQ editor so it's falling back to the empty item

[ohzee00]

I think the rotation is a floatQ even though its Euler representation is shown in an editor. The UI is simply missing a template for a floatQ editor so it's falling back to the empty item

Aw hell, I forgot rotations are floatq, I do recall seeing the setting before as a float3 input just like how inspectors do it. You might be right though, if others could chime in and check it themselves I would really appreciate it. I'm currently in bed and about to pass out so I can't do further testing.

[Frooxius]

This is currently intentional. There was one made, but it was causing problems, with the tracker rotations being reset. We'll have to revise this before we implement this one.

I'm also considering if we should show the position/rotation at all or just have those be hidden settings, or perhaps ones that are visual only (meaning you can't edit them).

I don't know how useful being able to edit them through this would be to people.

[shiftyscales]

I'm not certain how useful it is for the values to be exposed to the user for manual editing at all, @Frooxius. That's part of what the T-pose/calibration process does well.

Once the avatar is edited/has its proxies offset properly, all the user should ever need to do is to T-pose/calibrate their tracker position and rotations.

---

I have had occasions where the tracker wasn't mounted in the exact same place between sessions, e.g. it rotated slightly on the track straps I was using, but either physically correcting the rotation on the tracker itself, or T-posing were all that was necessary to get the devices/tracking back in line.

---

I think it'd be a good idea for them to be visual only if they are exposed at all. I can't imagine it would be easy to manually input valid/accurate values in a way that is more reliable/consistent than just doing some form of calibration/T-pose setup.

---

In my experience with full-body, that is something users don't seem to quite understand- e.g. if they wear their hip tracker on a different part of their hip, or rotated differently, it causes the tracking in Resonite to be off until they T-pose again.

I most often see users instead jump straight to the step where they modify their avatar's proxies with the calibration tool instead, and either forget to save the changes they made to their avatar, or otherwise wear their trackers in a slightly different position/rotation the following session.

---

This causes them to perpetually have to keep calibrating since they don't understand how the system works/they don't understand that there are effectively two separate calibrations that exist- one globally, and a second one per-avatar.

[ohzee00]

This is currently intentional. There was one made, but it was causing problems, with the tracker rotations being reset. We'll have to revise this before we implement this one.

I'm also considering if we should show the position/rotation at all or just have those be hidden settings, or perhaps ones that are visual only (meaning you can't edit them).

I don't know how useful being able to edit them through this would be to people.

Funny enough that is how I found this issue, to find the one you listed here and make a replication case for it. I do agree, it is very strange to have something like a floatq being exposed to edit manually when that is really difficult to do so, position I can more understand however.

I think with Shifty's suggestion, making them visual at least would be good or at the very least have some indicator that it is not a glitched visual. Which could be solved by the description explaining it not being editable compared to the position.

[Frooxius]

The position & rotation are a unit - it doesn't make sense to edit one without editing the other.

We'll probably just make both of them just visual indicators for informational purposes and not editable.

The only use-case for editing them is if you write down the values and then write them back, but I feel there's better approaches for stuff like that anyways.

[ohzee00]

Fair, I can see that approach working too. I guess if a user is particularly stubborn they can make their templates for settings to either expose it or a facet that touches those exact things

[5H4D0W-X]

I think that access to raw values like this is one of Resonite's main "selling points", and since UI elements can now be dynamically hidden by other elements, I think it would be best to have a "Show raw transforms" toggle that reveals the (still editable) position/rotation.

The only use-case for editing them is if you write down the values and then write them back

I disagree, I think things like manually lining up foot trackers would be a useful application of direct access to these values.

[shiftyscales]

If the calibration step is working properly/the user uses it correctly, there shouldn't ever be a need to key in exact values, @5H4D0W-X.

If it is to fine-tune/calibrate a particular avatar- having access to the calibrated tracker positions doesn't resolve that- as the proxies on the avatar should be adjusted/repositioned instead.

[5H4D0W-X]

What about non-avatar objects? There has been discussion about officially integrating the ability to track arbitrary objects and apart from the transforms in settings, there aren't any official ways to calibrate/adjust that sort of thing that I know of. With a tracked camera for virtual production for example, a visual alignment wouldn't be enough and manual offsets would help a lot. Putting those offsets in settings, not on the virtual object attached to the tracker, means that adjustments are saved and synced automatically across sessions and restarts

[shiftyscales]

For tracking non-avatar objects, there is issue #1828, @5H4D0W-X. Please keep discussion on-topic.