IVRCompositor: ShowMirrorWindow removed in 1.7.15

[DougalDC]

"IVRCompositor:

• Disabled the following functions: ShowMirrorWindow(), HideMirrorWindow(), and IsMirrorWindowVisible(). These are no longer support with the new VR View window."

we need similar functionality to this re-enabled again on the new window, as now our users will need to go to the steamvr applet to manually enable the vr view, and who knows if they will know how to do that.

The only other option is for every app to have to implement its own companion vr view, and that will add latency to the apps, and should not be needed as the compositor is already doing that work.

Dougal

[sergioberg]

Or just add similar debug comman like for legacy mirror: vrmonitor://debugcommands/legacy_mirror_view_toggle Which works great. Let it be called vrmonitor://debugcommands/mirror_view_toggle for example

[DougalDC]

thanks Sergio, that sounds good for developers, but for me, it is more of an issue of automatically bringing it up when the app starts, rather than opening through a browser. as for an end user, i think the browser method is even more convoluted than using the steamvr applet to open it.

[sergioberg]

You can create proccess cmd.exe in your code, and run "сmd.exe /c vrmonitor://debugcommands/legacy_mirror_view_toggle"

[DougalDC]

sure, but its a bit of a cludge, and it will open a new browser tab, and then ask the user if it should open in steam vr, so not as elegant as just calling ShowMirrorWindow(), and CompositorBringToFront() in the code after init.

[sergioberg]

and it will open a new browser tab, and then ask the user if it should open in steam vr

nope

[DougalDC]

really? ok, let me try that out, I always assumed the browser style requests went through the current browser. I still think it should be put back into the api though, there really was no valid reason to remove it.

[DougalDC]

ok, so i tried 2 ways,

1. std::system("сmd.exe /c vrmonitor://debugcommands/legacy_mirror_view_toggle");

2. CreateProcess("cmd.exe", "/c vrmonitor://debugcommands/legacy_mirror_view_toggle", NULL, NULL, TRUE, 0, NULL, NULL, &info, &processInfo)

neither of which opened the window,

however, if i drop "vrmonitor://debugcommands/legacy_mirror_view_toggle" into my browser, then it asks to open steamvr, and opens the vr view window fine..

do you see anything obviously wrong?

[sergioberg]

I use C# my code: System.Diagnostics.Process.Start("vrmonitor://debugcommands/legacy_mirror_view_toggle");

[DougalDC]

ok, thanks for the hints, i'll check out a bit more, but i am in c++.

[sergioberg]

Try without cmd.exe I just initially forgot how I implemented it.

[TheDeveloperGuy]

::ShellExecuteA(NULL, "open", "vrmonitor://debugcommands/legacy_mirror_view_toggle", NULL, NULL, SW_SHOWNORMAL);

However, "legacy" does imply that it's a "currently supported, but probably not for long" debug command.

I don't believe popping up the (debug) mirror window is a good user experience, as you're not in control of it, and providing an app mirror is not its purpose. You're probably going to have to spend the (minimal) amount of time that it would take to implement this yourself at some point, might as well make that now. If you're worried about performance, make it async.

[DougalDC]

Thanks, yes, understand this is re-using something that is now legacy, but this is just in discussing a workaround for the moment. This issue is a request is for the window opening functionality to be brought back with the new vr view window.

I use the mirror view, because it works a lot better than I can do with our engine, the compositor is running a lot faster (our engine can be highly detailed, so framerates can drop quite low) , and shows the overlays, (we use an overlay attached to the hmd, as a helmet style HUD for instance, plus a dash style one for app control), i cannot see any of that without re-doing the same work the compositor is already doing, and that makes no sense at all.

[TheDeveloperGuy]

Ok, the ShellExecute should work (and is how you open those kinds of addresses - it only invokes the web browser for types that are registered to it). Yes, if you're using SteamVR overlays you will need to get the compositor output. There's probably a reason (it may even be good) that this was removed, you'll have to hope a Valve dev joins in...

[DougalDC]

Thanks, yes, the shellexecute method works, that's great for a workaround ftm, thank you both. Now lets hope a Dev picks up this issue and gives us the ability to do similar with the new window, preferably before the legacy one is deprecated!

[aleiby]

The legacy mirror window was complicit in a full system deadlock we were seeing when interacting with other software (e.g. OBS for streaming). The only solution was to move the window to another process. I would recommend against using it for your preview.

If you want the texture that was previously used for this, you can call IVRCompositor's GetMirrorTextureD3D11 or GetMirrorTextureGL. The latter requires locking and unlocking the texture for access each frame, while the former just gives you a render target view to work with. These interfaces are what SteamLink uses for streaming VR and contains the dashboard, chaperone, etc. There is some minimal additional overhead when these interfaces are used as the provided texture is not updated otherwise.

Older versions of the SteamVR Unity plugin also used this (although it was added right around the time we switched to native integrated rendering, so not many games ever shipped with this support): https://github.com/ValveSoftware/steamvr_unity_plugin/blob/v5/Assets/SteamVR/Scripts/SteamVR_GameView.cs#L35

I'm reluctant to allow apps control over the new headset view as users may have set it up already the way they prefer. I suppose if they've hidden it, we could may have an app pop it up for the duration of their session. Alternatively, we could maybe pop up a permission dialog on request and store the result as a per-app setting.

[DougalDC]

Hi Aleiby, I'm not hung up on using the legacy window, its use is just a workaround, it is fine to move forward and use the new safer view, we just need a function to open the window, nothing more. I like the new view, it looks good, and has better configuration than the old. I am not asking to change any settings at all, so the user can retain the view they want and settings they want. Our App, is not a game, it is for construction & engineering, and we have multiple views & viewers at any one time, the mirror view is needed for the people not in vr to see what is going on with the vr user. Using the textures is an idea (I have previously tried this, but the textures were blank/not working at the time, so i moved on) , but then we would still be limited to the framerate of the app, rather than the smoothness of the real HMD view produced in the compositor, IMO the mirror view will always be better than what the app can achieve.