My game when full screen or when the scene view is hidden / closed plays at 90fps.
with the scene view open and the game view docked beneath it … i hit play and performance drops to 20fps
Closing the scene window or covering it with another window returns the FPS to 90fps in the game view.
This happens both on my mac laptop and my windows game dev box.
I never thought about this as a bug, since depending on what the scene view is showing, the engine has just to render a lot more stuff (sometimes the entire level) where the game view would just display a fraction of it. This does come with a performance cost. However, it would certainly be nice if Unity could render at the same speed while both, scene- and game-view, are open.
Is this issue specific to 2017.2 beta for you, or can you reproduce it in earlier versions as well?
Any console errors?
I have problems with Scene view too (without Game view opened!) - https://fogbugz.unity3d.com/default.asp?949723_k21a1c1jdmj6a3hj - it goes with 50+ fps in Game view, but only 10-15 fps for Scene view in Unity 5.6.x (poor, but manageable); in 2017.1.x/2017.2.bx there is 2x-3x performance drop for Scene view, to 5 fps (really hard to work). Seems that my 4-core CPU is bottleneck for Unity editor with that not so complex map (resource monitoring is in attached screenshot), but buying an 8-core Ryzen only gives me 2x boost from 5 fps to 10 fps (“… now you’re the Man, Dog!”). Need 16-core Threadripper for 20+ fps XD. And if all of this because of CPU1 main thread - it will be waste of money…
The first thing I would do is open the Profiler window, turn on “Profile Editor” and see what’s going on when I navigate in the Scene view. Perhaps it’s just a custom editor script that’s causing the performance issues.
Otherwise, if you have a project where you can reproduce this performance regression (same project fast in 5.6 and slow in 2017), I guess Unity would be thankful if you submit a bug-report (which you already did), following the advice given in this document to give them a chance to repair their software.
Ow, I can profile editor… here is results:
Seems those 100+ ms problems caused singly by LPPV (Light probes proxy volumes) - in Scene view it seems they updated all at once and every frame. In Play mode my scripts are fixing that madness by randomly spreading update for each object with LPPV over 50-60 frames (1 second), but for Scene view this is not working of course … guess only Unity can fix this…
How many LPPV’s do you have? They should be quite fast according to Unity’s blog.
A lot of them - almost every object has it, guess around 700. And they are not fast - on one object with 4x4x4 LPPV volume takes 0.15ms to update it on Core i7 as documentation says. Were possible I use as small LPPV grids as possible (like 1x2x1), but huge objects requires higher density (buildings for example has 8x8x8 LPPV grid density- it’s 1.2ms for each building each frame in Scene view).
700 seems high for arch vis, even. I hate to ask but do you know if you are using them correctly?
LPPV with less or equal to 64 probes will execute on the main thread, while larger probe sets will be multi threaded. The idea is you use maybe one big one for the entire town or level, if you are using geometry that is
a) dynamic not static
b) your dynamic objects are too big for a normal light probe
If it’s one LPPV per object then you are most certainly doing it wrong I think.
In standalone build mode there is 60-70fps at 2560x1440 (without post-effects, just clear test of raw speed) - sooooo… guess I’m using them right at least for final end-usage, with those scripts to spread LPPVs update between a dozens of frames. LPPVs are heavy but this is real time GI actually, substantial part of it at least. This way Enlighten is finally usable for me ^_^, it’s closer to SEGI / HXGI this way.
LPPV is per-object thing, unfortunately they don’t spread influence on others like reflection probes… Combining small meshes in to big one to set it with 64+ LPPV grid and receive multi-threading … is logical thing to do … but this turns level design in to nightmare, so really few cases are worth it. There is an option to share LPPV from one object to all over copies of this object, but this of course shares same lighting on all objects, they are losing lighting context - this also didn’t fit most of the situation, it’s like sharing backed GI…
I see, I thought that several renderers could use the same LPPV without problems.
Several objects can use the same LPPV without ANY problems by using Proxy Volume Override option where you can specify a game object that has LPPV component in it.
Please note that LPPV feature shouldn’t be used in place of normal lightmap baking! The feature is intended to be used by large DYNAMIC geometries that cannot use normal lightmaps(eq. large characters).
