Tracking settings refactor by zmerp · Pull Request #3060 · alvr-org/ALVR

zmerp · 2025-10-21T14:40:10Z

I'm making this PR early for feedback. Please check the settings.rs file. CI failures are normal since I did not bother with any other file

Some notes:

As part of this PR I will add a tracker mapping system
Hand skeleton and buttons will be send to the proper OpenVR device, regardless of the mapping defined in the Inputs tab
The split of sources/inputs and outputs/sinks will require adding and updating presets to make it usable

alvr/session/src/settings.rs

The-personified-devil · 2025-10-21T17:40:36Z

alvr/session/src/settings.rs

+    #[schema(suffix = "m")]
+    position_offset: [f32; 3],


This should probably be in mm instead.

The-personified-devil · 2025-10-22T12:35:04Z

alvr/session/src/settings.rs

-    ))]
-    pub detached_controllers_steamvr_sink: bool,
+#[derive(SettingsSchema, Serialize, Deserialize, Clone, Copy)]
+pub enum OutputTrackerType {


Honestly not a fan of this being two different enums, I think we'd be fine just ignoring the tracker if it's set to genericX

I know but I think it's for the best. It's confusing for the user being able to select invalid configurations. And surely people will still do the wrong thing even with 10 different warnings

The-personified-devil · 2025-10-27T18:15:59Z

alvr/session/src/settings.rs

+                content: vec![
+                    tracker_mapping_default(
+                        InputTrackerTypeDefaultVariant::LeftDetachedController,
+                        OutputTrackerTypeDefaultVariant::LeftFoot,


This interface doesn't protect against assigning two inputs to one output, ig we could always just error on that, but maybe explicitly listing all different outputs and having a selection for each is better? Sure it's more verbose, but idk

Sometimes you may want this. And you see an example right here. Both detached controllers and generic trackers are mapped to left and right feet. This is because different platforms have different inputs, but we want to be able to use all of them with the same server settings configuration

That feels more like something that should be sorted out by a preset system that allows swapping between user configs, than to allow double inputs that need to be resolved at runtime. And when resolving at runtime either we decide once and then commit or we need some way to select prioritization of the active input.

Hell, having an explicit list of outputs that's active at all times would also enable that.
Just have a fixed list of outputs and a vector of inputs for each one and then that would automatically have prioritization by placement in the list.

Ideally this would come with a nice full body graphic where you can just click on the output to modify the inputs in a dedicated sub-menu, but maybe it also looks fine when fitting it in the normal alvr settings scheme (tho for that I think you kinda need a build to actually look at it, shouldn't we be able to build the dash mostly independent of the other crates consuming the settings?).

This is also a matter of whether we want to make an input or output centric system (i.e. mapping fixed inputs to variable outputs vs mapping variable inputs to fixed outputs). I'm aware that the current solution is actually neutral, but I don't think that's a very "human" way to deal with it.

It should be "output centric", i think, because there are multiple sources that can produce the same kind of trackers, and also output trackers are linked to SteamVR which are harder to deal with because you cannot unregister them at runtime

The idea of the body graphic is nice. I thought about this before. It would just be quite some work though. And also it would mean that the outputs are not in a list so it would be awkward and verbose on the server-side code. But instead we could just keep the output vector and hide with the body graphics

The-personified-devil · 2025-10-27T18:22:25Z

alvr/session/src/settings.rs

-    pub enable_vive_tracker_proxy: bool,
-
-    pub face_tracking: Switch<FaceTrackingConfig>,
+    pub enabled_trackers: Vec<SteamvrTrackerConfig>,


So this is essentially another layer for enabling/not enabling the trackers?

This seems like a pretty clunky system and likely needs a preset on the page to reset it back to default to be non-hostile to use.
Apart from that a fixed interface for all the trackers would maybe be more intuitive?
Nevertheless I think this needs some more help strings

Yeah, here you can actually properly enable/disable trackers regardless of the data source. But these can't be changed without a steamvr restart because of SteamVR limitations. And yes there will be a body tracking preset. One glaring limitation is that we cannot have a preset selectively remove an element in the list, so we would have to set all elements at once. So this means that if we have a body tracking preset (Enabled/Disabled), we cannot have a controller enabled/disabled preset also (unless we allow to have always some controller devices that can be ignored by not sending data to them)

Honestly a steamvr tab for ostensibly steamvr only stuff is a good idea, but with things like tracking that are tied in so deeply with the rest of the system I think separating it out is a bad idea.

I think we can handle monado/steamvr stuff with another schema flag that gets interpreted based on which thing is selected to launch. Or we just fully build one dash for steamvr and another one for monado, but I'd avoid that if possible.

I think we can handle monado/steamvr stuff with another schema flag that gets interpreted based on which thing is selected to launch

This was my idea also. A Monado build will not have the SteamVR tab and viceversa. But still, i think it's bad to put the list of enabled trackers in the Input tab, because it contains the SteamVR-specific extra properties field. How should we deal with this? Should we make yet another separate vector in the SteamVR tab just for the openvr configs per-tracker?

But if we go with this idea, should we make the input/source tracker optional? I'm not sure if there is a proper usecase for this

zmerp · 2025-10-29T13:44:06Z

Following your suggestions, after the changes I made, I think we don't need any extra presets. (of course it would be nice to have the human body graphic for tracker assignment, but it's too much to ask atm). about head and controller tracking, I decided to make them enabled implicitely regardless of the trackers mapping setting (HMD always enabled, controllers enabled with their own separate setting, basically as before)

zmerp · 2025-11-23T04:50:27Z

Writing this down so I don't forget: for the body and face tracking settings, do not have a Switch for the source configurations. Let's enable a source only when we have at least one sink using it. This will also apply to marker tracking in an upcoming PR.

WIP

d2740e2

zmerp requested a review from The-personified-devil October 21, 2025 14:40

The-personified-devil requested changes Oct 27, 2025

View reviewed changes

Address some comments

edd1e18

Uh oh!

Conversation

zmerp commented Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zmerp Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zmerp Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zmerp commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zmerp commented Nov 23, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

zmerp commented Oct 21, 2025 •

edited

Loading

zmerp Oct 27, 2025 •

edited

Loading

zmerp Oct 28, 2025 •

edited

Loading

zmerp commented Oct 29, 2025 •

edited

Loading