A few questions about frame rate

I'm using VRTK/SteamVR and a Vive with a 1070 card. Working on stuff for a few months now, but just purchased some cool buildings from the asset store and turned on the frame rate in the HMD. It seems reasonably ok detail wise for VR, but I saw some dips when I added too much to the scene: https://www.assetstore.unity3d.com/en/#!/content/33052 So I had a few questions about what I can do.

1. Hidden Objects Effecting Frame Rate - When you are in an interior space looking at a wall where there is a lot of detail behind it (not rendered) can it impact frame rate? It *seems* to. If so is there something I should be setting to make sure unseen objects don't effect the current view.
2. Number of Objects in one scene - Sort of related to question one. If I put a bunch of prefabs in a scene, where you can't see the other objects does it still effect performance. This also seemed to be the case. Does this mean I should break objects into smaller scenes and try to smoothly transition?
3. Frame Rate Drops a Killer? - when I'm looking around and showing the frame rate in the headset I notice sometimes a drop will occur for a second or two and then go back to 80+. I don't notice a shudder and I wouldn't notice if I didn't see the frame rate, but it is dipping into the 40-60's. Is this a show stopper that I should definitely address or is it ok?
4. Editor vs Built Frame Rates - I'm just running from the Unity editor. Can I expect better frame rates when I build?
5. Different Computer Performances - I've got a middle of the road system with 16GB ram, 1070, i5. If I want to eventually (one can dream right?) put something on the steam store how do people know test to min specs like a 970 without actually owning one? Can I consider mine close enough to min specs to be ok?

 

This is something I've encountered since Unity 3. I believe someone once said it had to do with extra work being done in the editor (IE: tracking objects in the hierarchy, profiler, etc). I also notice that if you have an object selected while in play mode, and that object has complex components attached to it, the inspector will slow down the frame rate.

In VR I've noticed it pretty heavily and it does become an issue, especially when you're trying to throw objects that are currently attached to a hand. Things will seem choppy in the editor but when I build it the choppiness is completely gone.

Not sure if that helps at all, but you're not alone on that one.

 

Yep, editor vs build frame rates are completely different. Night and day.

This also relates to #3 - frame rate drops could be minimized in a standalone build. It could be a combination of the garbage collector collecting stuff plus the editor doing stuff behind the scenes (which may also need GC'ed as well). So the GC may have more work to do in the editor. I would not trust the editor frame rate as a meaningful value unless you're running at like 3 fps or so.

Plus, it's good practice to test a standalone build from time to time as you're likely to notice bugs that don't show up in the editor.

Questions #1 and #2 - look into occlusion culling.

 

Hidden objects will be culled by the camera so they won't be rendered, but they will still be taken into account while trying to render and updating any components / animations etc.
Disabled objects however take up next to no memory. Always disabled objects / group of objects if you can be sure they're not going to be visible (i.e. disabling a room after closing the door behind you, disabling the interior of a building while outside).

If you're running on those specs and are dropping down to 40fps I would start optimising pretty quickly. 40fps is not enough for VR, even minor hiccups are enough to make someone feel nauseous. 60fps is the bare minimum, 90 is ideal, 120 is perfect (though I don't think the Vive or Rift support 120fps).

As the other two posters have said, there is a difference between the Editor and Player. Always build and profile the player rather than the editor. Performance will be different, garbage collection will be different, bugs may only happen on the player / on the editor.

 

Thanks this was very useful to me. As i am also with a similar situation as the poster was.

In your post though you mention about disabling interiors of a building when you go outside, in VR as your trying to keep it as real as possible this can be quite tricky to do. For example, when i leave the building but still peak through the window i should be able to still see interiors from outside, similarly, when im inside a house, from the room windows i should be able to still see outside.

Ive found this quite painful for medium sized environment that i am building for my VR survival horror game. Ive also added LOD and reduced camera far clipping plane down to 100 (hopefully this should help a little at least right?), ive also turned on Occlusion Culling for the camera.

But i am still yet to try out a build, so that will probably bump up my fps by quite a bit.

Right now in my scene im running at around 30fps in editor mode, the problem though is that im knowhere near finished and still need to add quite a bit of details to the level design

I should probably mention that this is my first Unity game im developing

 

There are various things you can do to optimise your scenes. Without knowing in detail how you've built your scenes and what the exact reasons for slow downs are, it's difficult to recommend solutions.
However, when you are outside, for example, you can LOD your indoor models down to low detail, or perhaps render the scene to a flat texture and paste that onto / behind the windows, depending on how close you can get to the windows.
Generally in horror games you can cheat a lot and get away with low quality models / textures by just turning the lighting down.
Dropping your far clip plane will help, but not massively. You'll get a far bigger boost from disabling things beyond that distance entirely. For example, if you cannot see more than 100m metres away, objects that are 500m+ definitely do not need to be enabled. Although you'll want to be careful over enabling and disabling objects all the time, you might run into memory problems.

 

Ah cool, that makes sense thanks!

Do you know of any unity store asset that achieves this? ie. turning off objects that are not within in your near and far plane?