Edit menu lagfest

[pettypetty7]

Opening the edit menu to change things just puts me down to about 5 fps and it quickly becomes unusable, The framerate almost immediately shoots back up after closing the edit menu.

[TolleyLikesRice]

Same here

[dantman]

Edit mode results in displaying of the 2 camera based overlays for the edit panel and the 2 camera based overlays for the 6DOF controller. So it's 4 extra camera based overlays.

I've already tried limiting the FPS of these. Most of them are limited to 30fps, and I think the spawn panel is 10fps. But I guess we need to do more.

[pettypetty7]

I don't edit the joy sticks because I like the immersion of grabbing the game stick. Maybe a separate edit menu for throttle, stick, and landing controller?

[dantman]

Right now the throttle and stick are static image overlays, they just render a static Texture2D and display it. They are also always visible at the moment, so they aren't the source of performance issues that only show up in edit mode.

And if you want to turn off the throttle/sticks then I explicitly need to show them when editing so I can give you the future option panel to disable them.

Maybe I can find a way to make the FPS code dynamic. i.e. For the 6DOF controller reduce it to 1FPS or render once then disable the FPS renderer when it's not being grabbed, then turn it back on when you grab it.

[pettypetty7]

Do all the buttons already in use switch to some kind of non static mode in the edit menu that could cause lag?

[dantman]

Nope. Buttons always behave the same. The only difference is the MovableSurface doesn't ignore grabs.

In fact I already worked on optimizing them by making them skip overlay.SetTexture calls when the texture has not changed.

[pettypetty7]

Can we disable the 6DOF controller? I don't actually use it, I have my throttle trigger and menu button set to vertical thrust down and up respectively.

[dantman]

I am going to provide toggle options later for all the controls. But I'm not going to do it as a performance solution. The overlay should be made to run fine with all the controls enabled.

[pettypetty7]

Ya got a point

[dantman]

Also... the options panel in front of the throttle/joystick/6dof controller is going to add a new camera based overlay. Though I am thinking of making it so only one of them is visible at a time so there is only 1 new overlay, instead of adding 3 new overlays. Also I'll try to make it only render on-demand when button styles change.

But ultimately the ability to toggle off controls will actually likely lightly hurt edit mode performance instead of improving it.

[jdawgzim]

I'm having this issues sometimes too. On a fresh Windows boot I get normal frame-rates when unlocking the edit menu. After locking and unlocking several times while playing eventually I get the "5 frames per second" bug and the whole game is sickening lagging until I can carefully make my hands go back to the lock edit button. I'll try to figure out how to make it happen consistently

[pettypetty7]

I'm also still having this issue consistently with the 4.0 version. Is it possible that limiting the framerate of the overlay limits the framerate of the headset? I'm not a programmer so maybe what I'm saying is beyond idiotic, but I don't know how this overlay could slow down my computer so much.

[jdawgzim]

I do get the "too many overlays" type error, so maybe that's causing the issue when the additional menu overlay appears when I'm already at max overlays. I'll test this out later one.

BTW, is mod is making Elite VR Experience amazing for me! I combine this with Voice Attack but being able to not use Voice Attack while on Discord is nice. Also not buying a HOTAS and try to set that up is excellent.

[dantman]

but I don't know how this overlay could slow down my computer so much.

Rendering game cameras are expensive, games avoid having more than a few so the game runs smoothly. And the overlay needs to use multiple cameras, when there is already a full game running at the same time expecting to have the full attention of the GPU for its in-game camera. Outside of edit mode there are 2 cameras rendering on-demand. In edit mode a number of extra controls have to display for you to move them, so there are 6 cameras in the overlay and some of them render continuously instead of on demand.

Basically the way overlays and Unity fundamentally work put me in a situation where I have to use a number of game cameras that no developer would ever sanely want to do even outside of VR. To optimize the overlay I have to come up with whatever tricks I can think of to reduce how often the cameras render updates to the images used in the overlay. For some of these I managed to make them "on-demand" where they render once then only render again when something changes. Others though were too difficult and had to get a fixed low FPS rendering hack instead.

[dantman]

Ok, I actually started noticing this happening myself, on my GTX 1080 and I started testing things out.

The first thing I noticed, this was even happening in edit+menu mode, where the normally hidden extra controls like the 6DOF controller are still hidden.

Then while examining the Profiler I noticed that nothing seemed to actually be hogging the GPU for an excessive amount of time. In fact I noticed that the Texture.GetNativeTexturePtr() SteamVR was calling when updating a texture occasionally blocked everything for a whole second.

However this topic suggests that what is happening there is actually that SteamVR is entering Motion Smoothing mode and blocking rendering to reduce the framerate.

This is what causes the overlay itself to stutter. GPU usage gets a little too high and SteamVR panics and starts blocking the overlay's rendering to halve the framerate causing the overlay to stutter.

Examining SteamVR's frame timing graph I actually noticed that ED outside of edit mode (and perhaps even with the overlay off) was already always in the yellow and not delivering frames fast enough.

So I dropped out of ED and tried experimenting with the overlay in SteamVR Home (which actually has a decent frame timing). The overlay on its own with nothing expensive running is actually quite light, it only adds about 1ms to the average frame timing. But edit mode still thrashes the frame timing even when in SteamVR Home.

So I tried debugging to see what element exactly is causing the spike in frame timing. I narrowed it down to the edit panel itself. Even with the spawn panel disabled and edit mode disabled, if rendering of the edit panel itself is turned on frame timing spikes massively. In fact if you change the fixed FPS renderer to 1fps, you'll see the frame timing graph show green most of the time and a massive purple spike every 1s when the edit panel is rendered.

It seems my back of the hand estimate of what size of render texture the edit panel needs to look smooth when you look closely at it was overboard. Not even my GTX 1080 can render the 2048x2048px interface without massively slowing things down.

If the UI still looks good, I'm going to reduce the texture to 1024x1024in a release after I'm done with the galaxy map stuff.