search

dantman / elite-vr-cockpit

A SteamVR Overlay providing a virtual throttle and joystick and holographic buttons for ship functions, with custom integration into Elite Dangerous
Other
326 stars 37 forks source link

Unable to detect Elite Dangerous and high GPU usage #28

Closed Thevgm01 closed 6 years ago

Thevgm01 commented 6 years ago

Apologies if this doesn't fit the format (this is my first time using Github). I've been having some bizarre issues while trying to get the program to work. The main issue is that the program is unable to detect that Elite Dangerous is running (except for one time, which I'll explain later). The secondary issue is that VR Cockpit uses 100% of my GPU whenever it is running, even if ED isn't.

System info:

Things I've tried:

Here's what it looks like when I try to launch Elite VR Cockpit, followed by ED: ed_running As you can see, even though ED is running, it can't seem to find it. No error messages or anything. The log file in my AppData folder doesn't have anything strange either.

Now this is where it gets weird. There was a single time where it was able to detect ED. I had launched ED and loaded up the first training mission, and then I started VR Cockpit. It recognized the game and immediately began spewing "Permission Denied" errors. After several seconds, I closed VR Cockpit and snagged the output log (see below). For the PID part on line 504, I do remember checking to see if the number was the same as ED's PID, and in that case it wasn't. VR Cockpit hasn't done anything like that since. weird_output_log.txt

That weirdness happened with v0.1.1 of VR Cockpit, so maybe it has to do with something you fixed already, but I thought I would include it just in case.

Now for the 100% GPU part. This is what happens when I run VR Cockpit without ED running: cockpit_gpu

Interestingly, every couple seconds "Elite VR Cockpit.exe" will stop responding and will only use 50%: cockpit_gpu_not_responding

When I run ED, VR Cockpit will use whatever percentage is NOT used by ED, so I still end up with 100% GPU usage.

If you need me to try anything or give you any files, I'd be happy to help.

EDIT: I tried updating my graphics card drivers. VR Cockpit still doesn't seem to work, but there's slightly different output now. It writes "Init_ShuttingDown" as the first log entry. output_log.txt

dantman commented 6 years ago

Init_ShuttingDown sounds like an error sent by OpenVR, likely when the overlay tries to init. For that part I can't think of anything except something is wrong with SteamVR in that case if SteamVR is still running.

I notice your Task Manager lists "Elite:Dangerous Executable". What is the filename of ED's .exe file?

Someone else mentioned performance. Perhaps I need to see if Unity's profiler could be of any help. Perhaps also force Unity to turn down setting because the overlay isn't running as a game.

Thevgm01 commented 6 years ago

Task Manager tells me that it's "EliteDangerous64.exe" located in C:\Program Files (x86)\Steam\steamapps\common\Elite Dangerous\Products\elite-dangerous-64\EliteDangerous64.exe

Also I saw that I missed some lines in the weird_output_log.txt file, and it turns out it did include the PID stuff. I updated the original post with the new file, in case that would be helpful.

dantman commented 6 years ago

I guess I'll have to catch the ArgumentException when the process ID can't be found. But that won't actually fix the problem.

I'm not sure why it's getting PID 7260 from OpenVR but not being able to lookup the process info about that PID.

Thevgm01 commented 6 years ago

I was able to fix the Init_ShuttingDown message by manually starting SteamVR before VR Cockpit. Unfortunately, that didn't help VR Cockpit detect ED.

If you need me to use the Unity debugger or anything like that, just let me know.

dantman commented 6 years ago

You could debug.log the pid and p.ProcessName and see how they compare to PIDs of processes on your system.

https://github.com/dantman/elite-vr-cockpit/blob/v0.2.0/Assets/Scripts/EDStateManager.cs#L212-L214

pettypetty7 commented 6 years ago

Hey there, I made this account because I love using this overlay but I get a version of this problem. I can detect ED just fine and the overlay works perfectly for a good while, but eventually (typically after loading into a new area) the overlay will begin using 100% of my GPU. Restarting the overlay after this problem occurs doesn't fix the issue as it immediately uses 100% GPU. The only fix I've found is completely restarting my computer. I'm having a great time otherwise, aside from my grip button fingers aching.

dantman commented 6 years ago

I'm having a great time otherwise, aside from my grip button fingers aching.

Check out v0.2.0, @dhleong helped get toggle grab in early. You can still hold the grip button if you want. But if you press and release the button quickly it will stay grabbed until you press it again.

pettypetty7 commented 6 years ago

I'm having a great time otherwise, aside from my grip button fingers aching.

Check out v0.2.0, @dhleong helped get toggle grab in early. You can still hold the grip button if you want. But if you press and release the button quickly it will stay grabbed until you press it again.

Oh awesome, will I need to resetup my Virtual buttons, or can I transfer a file over?

dantman commented 6 years ago

Oh awesome, will I need to resetup my Virtual buttons, or can I transfer a file over?

State is saved in a user appdata folder just like a game, not the program folder. So you can just startup the new program.

pettypetty7 commented 6 years ago

I've spent the last few hours playing in one continuous session and I haven't had any GPU problems yet. I've been playing normally and jumping sectors quite frequently. Not sure if something changed, but I'll keep vigilant. This new update is great though, It's so much more comfortable to play for extended periods. it might be nice to consider a control that auto releases a joystick based on proximity in the future.

dantman commented 6 years ago

it might be nice to consider a control that auto releases a joystick based on proximity in the future.

Right. VTOL VR doesn't do it, but it's probably worth adding. Something like auto ungrab when you move 50cm away (to be generous, since it should be normal to rest your controller on a leg that may be a distance away). I'll probably wait till after I add the throttle/joystick options panels. So I can let you configure the distance right away, in case people want a really low release distance.

Thevgm01 commented 6 years ago

Okay, so after a lot of painful research, I think I solved it. The code wasn't able to find the PID of ED. That was because SteamVR wasn't detecting that I was in the game (which would also explain why I was never able to use the SteamVR overlay). I finally came across this guide which fixed my issue. Essentially, if you have an Oculus Rift, you need to run ED in Windows 7 compatibility mode in order for Steam to actually latch on to it. Or, well, in my case I did. I have no idea why other people don't seem to be having this issue. But, whaddaya know, the SteamVR overlay works, and VR Cockpit started working too! I could see my controllers and everything.

Unfortunately VR Cockpit is still eating 90% of my GPU and the game is literally unplayable since I only get ~5 fps, but at least it functions.

Thevgm01 commented 6 years ago

Okay, so just for the heck of it, I decided I would try to run VR Cockpit in Windows 7 compatibility mode, and it actually helped! It only used ~50% of my GPU, and ED was minimally playable. Hopefully future updates will improve performance further.

dantman commented 6 years ago

@Thevgm01 Would you mind downloading the latest source (the master branch not the releases) and running it in Unity?

I've made some changes that I think could improve performance. But I'm not sure if they do, and I want to make sure I didn't actually make things worse.

Thevgm01 commented 6 years ago

@dantman Okay, it does indeed look like there are massive performance improvements. With no modifications it only uses ~30% of my GPU, and with Windows 7 compatibility mode turned on, it only uses 3-4%. ED is playable now, thanks!

One thing to note is that the moment I click on the lock (to add function buttons), the game once again becomes unbearably laggy. But, as soon as I close the icon list, it instantly returns to normal. I'm guessing the fix would be to collate groups of icons into one object.

dantman commented 6 years ago

The icons in the icon list aren't separate. The top half is a single Unity UI driven overlay.

The performance impact of enabling edit mode would be that the Edit Panel is made up of 2 camera based overlays and the 6DOF controller is also made up of 2 camera based overlays and is normally hidden. So there are 4 overlays using camera rendering that appear when you unlock the edit button.