I built the current head 6fcfebe and was using it quite happily last night (the show cursor and always-on-top behavior was great for my use case! but today I can't. It now shows up as the active SteamVR app. So if I start a game, OVRDDP is killed, and if I start OVRDDP, the game gets killed. Simply running OVRDDP now shows up in the "Now Playing" box:

with just a generic now playing string identifier.

I honestly can't tell you what changed since last night. I was on the beta channel, but the beta hasn't changed in a few days (and the release, v1472685831, now matches the beta as of last night).

I also ran OVRDDP as Administrator the last time I ran it (I was having an unrelated issue and just thought I'd try it), and I believe that's the first time I ran this build as Administrator—I'd needed to run the 1.0.5 release as Administrator to get mouse clicks on Firefox to work, as we discussed, but that didn't seem to be the case with this build. Could something OVRDDP can do as Administrator while running, but not as a normal user, cause a pervasive change in future runs only? Because it did work the last time I ran it last night.

Just wanted to share that I created a guide showing step by step how to get overlay working with Elite Dangerous on the Oculus Rift. Your compatibility list shows this isn't possible, or really that no one (save for one user) has gotten it to work. I've been able to set this up on 2 different machines so I'm fairly confident the guide is correct and will work for anyone.

The link to the guide is:
https://www.reddit.com/r/EliteDangerous/comments/53j9ka/openvrdesktopdisplayportal_overlay_for_oculus?st=itafwp3c&sh=d94e0380

Feel free to use/post/share as you'd like.

Thanks for creating such a cool little app, being able to overlay a browser or video into VR is really sweet.

Currently it isn't possible to disable Grab/Scale interaction, but in 1.0.6 I would like to add the option to disable Grab and Scale individually. It is already possible to disable Click interaction, so this would make it possible to toggle on/off all of the current Overlay Interactions.

If you disable grab, you would no longer be able to "grab" and move the overlay from VR. Maybe this would also disable scaling, but perhaps I will implement scaling without allowing moving. Disabling "grab" would be nice once you get your overlays precisely where you want them, so you don't accidentally grab them while playing a game.

If you disable scale, you would no longer be able to "scale" the overlay from VR. Again, this would be nice once you get your overlays exactly the size you want them, so you don't somehow accidentally resize them while playing a game.

Both of these options should be saved on a per profile basis.

It would be nice if you could easily resize the window from the interface; The payoff will really come when in-VR interaction is added, and it becomes possible to resize the window itself directly from VR. Should definitely be possible, perhaps easy even.

These would function similar to the window cropping settings, but would actually resize the window.

I know there are a number of different ways to capture the screen and other applications, and I'll be looking into implementing them when I can. If anyone else wants to take a crack at it, feel free to fork the repo and test them out :).

Not sure what causes this yet, but I suspect it is these lines. This line typically prevents the Overlay from being aimed at from the backside, and works properly for World Overlays but seems to mess up with Controller based Overlays.

When you rotate the Overlay too far (I believe +/- about 30°) it no longer detects being aimed at. This is unfortunate and I think it will be easy to fix, but I don't have the time tonight and don't want to delay v1.0.6 any further.

(I don't know where to put feature requests, sorry if this is the wrong place.)

My use case: I would like to use VoiceAttack to start OVRDDP to bring in a particular window.

I'm currently researching how to get cmdline parameters in unity; if i can figure this out, I will submit a pull request; but I'm quite new to Unity.

Would it be possible to track the mouse cursor, and replicate it onto the overlay when the cursor is over it? If so, it would be a very useful feature for multitasking.

The last update to the controller manager here bugged out the detection and it reports every 10 seconds now when no controllers are detected :). Will be fixed in the next update.

This issue only applies to the source until v1.0.6.

To add onto #36, when the cursor is being shown because the desktop cursor moved over it (and not because a controller is currently aiming over it), it should hide after several seconds of no movement. It would of course appear again when you moved the cursor.

This will probably be another toggle under "Additional Settings".

It has been mentioned a few times now that certain games (ED in specific) spawn you in the wrong position when OpenVRDesktopDisplayPortal is already running. I assume this is related to #10, in which case I believe this is already fixed in my local source, but I can't be certain as I don't have ED yet and cannot test it myself.

The fix for now seems to be to start the game first, then launch OVDDP, and that seems to work. I believe this doesn't fix #10 though.

Fixing in a few minutes.. Mobile right now or I would have fixed already.

Hi,
I'm trying to use this app for development so I don't have to take the headset off every so often, and I was so close to a perfect setup. However I've encountered the following problem:

in Unity, if I choose "Tracking Universe Seated" and enter Play mode, OpenVRDesktopDisplayPortal will get confused about where the overlays/colliders* should be.

(*) Note that I'm using AlphaAndScale mode, so it might appear to be working OK with default settings. I've set it up so that the overlay is in front of me as a large monitor, that is small and transparent when I'm not looking at it, and enlarged and opaque when looking at it. Once I enter Play mode in my project, looking at the overlay no longer works, and after about 10 seconds the overlay gets shifted to another position.

Ideally, the overlay would always stay at the same spot.

I've tried running OpenVRDesktopDisplayPortal from source, with [SteamVR] prefab added to the scene and set to Seated as well, but it doesn't seem to help.

Not sure the cause for this, but occasionally I find that all of my Target Application configs have been deleted. It's especially odd because I've never found my profiles deleted and they use the same system, so there must be an error popping up somewhere that Unity isn't reporting. I thought I fixed this one already, but it still occasionally occurs.

I'll have to do some extensive testing to weed out the exact cause since it seems pretty random.

If anyone can find something repeatable that reliably causes the loss of target window configs, please let me know :o

Fixed in my local source, but inb4 bug report.

Are you planning on bringing this into the app at any point?
I love this app so much but it literally uses more cpu than OBS...
I have an i7 hexcore on windows 10 and can't use this to stream because it maxes out my cpu </3

/u/macdaddyb on reddit pointed out that Overlay Gaze detection doesn't work in Elite Dangerous. This has possibly been fixed in my local source already, but I'm waiting on some feedback before I push it to the repo, since I haven't encountered a game that does this yet, and do not own ED so I can't test it myself.

Pretty easy to explain. Set the window cropping to a large number like 12000 and it breaks the application. I had to delete my save data to fix it :P. Should be easy to add min/max checks in the future to make sure the cropping settings are actually capturing part of the window.

As suggested here on Reddit, it would be nice if the backside had a color or possibly some graphic (possibly a logo for OVRDDP?), so that you could tell where the overlay was even when it was turned around the wrong way :). Wouldn't work for curved overlays but OVRDDP doesn't currently utilize them anyway.

As hinted in the title, I think this should maybe only apply to World overlays or at least be configurable, since I like being able to put them on the back side of the controller and be unable to see them without turning my controller around :).

This requires rewriting part of the system to accommodate companion overlays, but this was already planned for the future VR UI improvements.

Requested in a PM on Reddit is the ability to modify some of the UI elements, specifically the crop values, with the scroll wheel. Should be easy enough to implement.

Just letting anyone who is following the repo know about future changes.

In a future release I intend to add additional modes, such as an integrated Video Player, a turn counter (similar to how TurnCounterVR functions), possibly stats about your computer such as CPU/GPU temp, etc.

Each available 'mode' will be selectable via a dropdown similar to how the other dropdowns work. The current application mirror mode will be selectable and the application will default to it for the time being, but I may eventually rename the project when there are other substantial modes, and the default mode might be something different; though it will probably load up the last mode you used, to speed it up for users who only use one mode or another.

I'm also thinking about integrating OpenVRTwitchChat because it becomes difficult to maintain multiple sources that rely on the same base code that you are also maintaining :P. As I make upgrades to the HeadlessOverlayToolkit I'm currently having to push those upgrades (and make any code changes necessary for that specific repo) to three separate repos.

This issue will not remain open until I finish implementing these different modes, instead it will be closed when I implement "Multi-Mode" which will allow you to select from the available application modes.

If you disagree with me adding additional modes and you think I should keep this application strictly as an Application Mirror, please voice your concerns below.

Right now if you attempt to scale the overlay down enough with the controllers, you eventually pass 0 scale and head into the negative values. When this happens, the overlay becomes flipped and mirrored. I can't see any reason you would want this, and IIRC negative values are disallowed in the Input fields anyway. Negative (and probably really small) values should be prevented and will be in v1.0.6.

This issue only applies to the source until v1.0.6.

To add onto #36, there should be an option to force the window on top when you move the cursor over it.

This one might be annoying because the target application will always jump on top when you move the cursor over it's position, but also might be a lot better when you're using KB+M while in VR, since you won't have to alt+tab until you find the right window to send input to.

Working on this in my local source. There are a few different ways to implement this, so I'm trying to figure out which one is the most reliable before I push anything to the repo.

Following up on #19, I still intend to add an optional outline for the overlay, visible in VR. Should be relatively easy, and I'll try to add it when I have a chance. You should be able to change the color of the outline.

Not sure why this is happening, but it is :P

I was definitely able to rotate it fully around previously without bugging it out, so I must have derped something between then and now.

Not a serious issue, but can be annoying when it doesn't want to mirror back the right way.

Currently the save system only saves the top four input boxes, and on a per application basis (when you target the same application again it will load the same offsets as you had set for it previously).

I intend to incorporate the profile system from OpenVRTwitchChat but decided to skip them for the time being to get the application released faster since it isn't vital to the operation. I will probably add this in the next few days (possibly tomorrow).

Hey,

In regards to your capture framerate I suggest you might want to consider scraping the framerate from the target window and use that or the user selected framerate (whichever is lowest).

For example, Capturing Chrome at over 60FPS is nearly pointless, especially if the window is only rendering at 5 FPS or something. A lot of Windows applications have their framerate tied to updates. So if the window is doing nothing it will only render at maybe even 1FPS, but as soon as you do something it will jump up to process that action.

This might help prevent unnecessary rendering.

Hi,
my only use case for this app is having my full desktop in VR, and that's the only option that's missing 😄 I have a kludgy workaround right now that works good enough, and I saw that you mentioned you've tried full desktop capture but it worked bad. I figured it might actually work better than my workaround, so, if you still have that, can you please push that to a separate branch?

My workaround is to open OBS and enlarge its Filters window to maximum size, and have OpenVRDesktopDisplayPortal capture that window. I run that at 1.5x supersampling and it works good enough for me (i7, GTX 1070).

Additionally, would adding an option to have the overlay be curved help with performance in this case (since it'd go through that fast code path mentioned in OpenVR docs)?

Hello. I'm using version 1.0.6 of this program, and I seem to be having an issue. When I put a Youtube video in fullscreen, then target it and lock the aspect ratio, the window does not change size in VR after resizing it in the program. According to the instructions for this program, I should be able to do that, unless I misunderstood them.

Would be nice if there was some Haptic Feedback for certain actions; this will be an option that can be turned off and saved on a per-profile basis.

I'm thinking Haptic Feedback will occur for:

• Aim at Overlay
• Touch Overlay
• While Scaling (a light rumble every 0.1 scale changed?)

Anything else that should have Haptic Feedback?

Haptic Feedback should occur in the controller doing the action, so for aiming/touching only that controller applies, but for scaling I'm thinking both controllers should have feedback.

In addition to the manual refresh button the application should periodically update the list automatically. Also it should detect when an application closes and automatically switch to the default SteamVR texture or something.

It would be very nice if the target application's audio could be tunneled into VR and routed out through virtual speakers or through the overlay for spatial audio. This would require low level system drivers to create a virtual audio device, which the target application would require support for selecting the audio device. It might also be possible with certain applications to set the windows default device, start the application (and begin playback), then switch the default back to the correct device. Certain programs can be tricked into playing on a specific device this way even if they don't support selecting the output device directly.

The best way to implement this might be to use a third party program such as VirtualAudioCables to create a virtual device for the target application to play to. This route might require some setup, but certain third party programs like VAC have been developed pretty much for exactly what would be needed. It would be kind of shitty to require an additional (non-free) third party application for a specific feature, but I think this is the fastest and most straight forward way to implement this for the users that really want this feature.

It's on the todo list, but no ETA.

Not sure what I bugged out here, but working to fix it.

It would be nice if the list of profiles was already populated with handy setups, and I'll see about adding some when I have the chance.

Feel free to post your favorite settings in the comments down below. Would be nice if you could upload a picture or short gif of the overlay in action, as well as a screenshot of the config in the desktop window.

This one your not going to like. Have you used big screen betavr? Basically you hold a grip button on your screen and you can move it, or hold it and click up or down on track pad for distance or left or right for curvature. It might be primetime ready if this were configurable IN Vr with your controllers. Totally unstandable if not ^_^

Another would be- you know how you can set it to look at it and it will scale and alpha? Could you make it so the screen would dodge your direct vision? As in get out of the way so I can see over there lol. I suppose you could set the alpha 1 to 0. Idk, what do you think?

The last one is the scale and alpha need +- buttons.

Any way to set the app to launch with specific games and connect a profile to load with certain games?

Mouse simulation should support middle clicking as well as scroll wheel and click+drag. I was having a hard time figuring out how to simulate click+drag on a background window with the Win32 API (mouse press+move+mouse release doesn't seem to simulate a click+drag automatically), so that might not make the cut, but I would like to at least add middle click and scroll support before the next release.

I mentioned this on Reddit and while this would certainly be a very ambitious feature, I figured I'd drop it here in case you want to leave it as a item that might one day be interesting:

You could have a "virtual tablet" in VR by putting all the controls on a single controller. One button (grip, perhaps?) would activate interaction. Swiping on the trackpad would move the mouse pointer around within the overlay. The trigger would click, a trackpad click would be a right click, and two fingers swiping could be the scroll action. (Multifinger gestures would let you do things like a two-finger tap for middle click and leave the menu button for something else interesting.)

Playing around a bit with the Vive controller, it seems like this might be most comfortable with the Vive controller held with the trigger in, with clicking not registering until the trigger is clicked in. (It also seems like it might be most comfortable to use it stably--since wobble could be a problem--with the controller held sideways--in your left hand, with the controller pointing right, with your right finger doing the "mousing".)

I'm using the newest 1.0.5.1 alpha (binary release) on Windows 10AU with Vive. I can get the overlay to work, but for the apps I've tried (Firefox and Notepad++), I can only move the mouse sprite around, I can't click. This is regardless of the interaction mode I choose. Besides interaction mode, window, and binding (I've been using controller), I haven't adjust any settings at all.

I've tried this both while running Elite: Dangerous and while just sitting in the default SteamVR environment without any other app running. Any info I can give you to help? The output log is attached.
output_log.txt

As requested on Reddit, I will eventually add an alternate mode that tracks the number of times the HMD has done a full rotation. I already did some experimenting with this and it seems to work great. According to /u/SoTotallyToby, TurnCounterVR is not reliable, so I will do my best to implement a reliable turn counter when I have nothing else to do.

This probably won't make v1.0.6 but perhaps v1.0.7.

Internally, World and Screen based overlays have been offset by +1 on the Z axis, because at the world center (0, 0, 0), Screen overlays are not visible because they are at the same depth as the HMD, and not in front of it. To work around this, way back before v1.0.0 I offset the Overlay by +1 on the Z axis so that it was always visible by default. Unfortunately, this lead to some trickiness in changes for v1.0.5, so I dropped the +1 offset.

I never bothered to drop the +1 offset before because it wasn't causing any harm, but now I believe we should drop the offset and default Screen overlays to having an actual Z value of 1 instead. This breaks compatibility with older profiles, because they will all be offset by -1, so I'm adding a patch to the system that will attempt to add +1 to Screen overlays when they are first created (and first loaded for older saves), subtract 1 when switching to Controller or World overlays (so they are at the proper position), and add +1 back to them when switching back to Screen. The patch will also need to add +1 to old World Overlay saves, but newly created World Overlays should default to the world center.

As a result, the Z number should change, but it's location should end up the same.

This should be the last major change before I run final testing on v1.0.5, and release.

Although some changes must be made to the save system as well thanks to changes in 34349ba, but these two things I think are the last changes for this release.

I haven't tested this application yet, but I noticed one thing from your description:

Note: Overlays will always draw ontop of other game geometry. This is less noticable if you attach them to the controller since things rarely come between you and the controllers. Otherwise you may want to attach them to the screen, or put them on a wall behind you or up in the sky.

Did you know that there is also a type of overlay called a Dashboard overlay? Dashboard overlays will show up as a tab in the SteamVR dashboard, so it is much more convenient when you don't want the window in front of you all the time.

Not sure if this actually effects the position/rotation of the display, but I noticed that loading with the panel closed causes it to load an extremely close, but still technically incorrect number (e.g., 5 loads as 4.99999..). Not sure why this happens but I assume Unity doesn't like me changing the value of a disabled UI element.

I think this is still a thing and don't want to forget to fix it. When you load a controller profile and the selected controller isn't available, I believe the Overlay defaults to Screen. Instead, when the Left Controller is selected and only the Right Controller is found, it should select the Right Controller, and vice versa.

I don't think I ever patched this, and it is useful for people who only use one controller or the other for whatever reason.

If the other controller is turned on, maybe it should automatically switch back to the other controller (which would have been the one it would have attached to in the first place)? At this point though I think there's a decent chance the controllers would have been misidentified, since SteamVR only assigns roles when both controllers are connected and tracking, and if no roles are found OVRDDP assigns them automatically (hence the Swap Controllers button, for when OVRDDP has assigned them incorrectly to the way you are using them, where as SteamVR will automatically reassign roles if you put them down for a few minutes and pick them back up. I could set OVRDDP to automatically update the roles when SteamVR reassigns them, but I think I like it better as Manual for now)

Currently the Overlay uses Bilinear filtering but the Capture itself is using Point filtering (which means it isn't using filtering). Someone on Reddit requested I add the ability to change the quality settings, which I intend to do. Wouldn't actually increase the quality but might make it look a bit nicer.

Coming in next release. Adds the option to lock the resolution so the window will be resized automatically to the selected resolution if it is resized to anything else.

Just adding this before it is suggested elsewhere.

Currently the system is only designed to utilize a single Overlay, but it would be nice to have additional Overlays that are not necessarily attached or at the same position/rotation to the primary overlay. For now I will refer to these as Companion Overlays since they are not the main focus of the program, and are just meant to ease accessibility and accommodate UI elements, as well as a few other things such as #29.

This is mostly a note to self, but also of course being used to track progress on the Repo.

Reducing garbage creation/collection might cause bugs, but definitely improves performance. This will probably be in the next release.

Edit: GDI stuff garbage is pretty significant (20% approx of application time). I now get 100+FPS average (up from 60-80 average) with a 485x285 video @ 24FPS capture (w/ Direct Capture) pic. I have an FX-6300 and an R7 265.

1. Keyboard hotkeys for each slider and +/-.
2. I don't know what alpha means but I'm guessing it's transparency? Better label?
3. The slider values are really extreme and your Vr pip (picture in picture) fly off into somewhere, very far.
4. + and - on each side of sliders for finer control
5. An option to have a bold outline and maybe a color of outline around pip may be nice for some environments.
6. This app is not listed yet in r vives "applications" list (at the bottom). Only your twitch chat viewer. https://www.reddit.com/r/Vive/wiki/index#wiki_applications.3A

Keep up with the updates my friends and let r vive know, hopefully get some more donations!
Thanks!

The last issue I mentioned—for mouse & keyboard games, it would be nice to be able to use the physical mouse as the pointing and clicking interface for the overlay. But like in the Steam desktop overlay (now—for a couple of months, this was not the case at least with the beta channel of the Steam client), the pointer doesn't appear when you move the mouse, though things like hover tips and feedback highlighting are obviously passed through.