Turn on vsync in the editor Scene window.

Is there a way to enable vsync in the editor for the Scene window ?

When I am moving about in the scene my graphics card is whining.

Thanks.

 

Turn it on in the quality settings. Whatever quality setting you have currently selected is the setting for the editor.

--Eric

 

I have but the card still whines..

 

VSync wouldn't have anything to do with your card whining. And by whining, I assume you mean the fan is ramping up in speed. Nothing you change in Unity is going to affect that. You'll have to look into whether your graphics card's driver has a control for the fan speed or find another way to set the speed to a lower setting or underclock the GPU.

 

Actually, vsync often can have a lot to do with overheating since to burns through frames as fast as it possibly can, consuming more power.

 

Vsync does have an effect on cards whining and it's not the fan. For example I had a game a while back that was trying to run at silly FPS and the card whined. It's an R9 280X. Forcing the vsync on with D3DOverider worked and the whining stopped. This is the same whining that Unity is causing, albeit it unintentionally and a little less. Technically this is called 'coil whine'.

The idea with controlling vsync, as I am trying to do, is to stop more powerful cards from maxing out and running at full speed when unnecessary, which can cause coil whine.

D3DOverider seems to have no effect on Unity though sadly. So I was asking if there was anything in Unity that I could set up, but it appears not. It's just a little annoying but I can live with it.

 

Yes hippocoder - this is my concern, but as it's not all the time I think I can live with it unless I can find a solution.

 

I see, makes sense.

Have you verified the changes you made to quality settings did enable VSync? Just open the Stats box with the game running and if it shows over 60fps, you should check your settings again and make sure they apply to quality setting currently assigned to the editor.

 

Yes in the game window it runs at the expected 60fps give or take 5 frames. So something is working. It's just the Scene window when it occurs.

 

There are no settings specifically for the scene view, so if changing the editor quality settings didn't stop it, then there isn't a setting I know of in Unity that will help, unfortunately.

 

OK well thanks for suggesting a few things and for your time

I'll dig around the net to see what I can find.

I checked my graphic card driver ( AMD Catalyst) and made a profile for Unity that forced vsync on but still the same. I did read that sometimes programs that run in windows don't respect vsync but in full screen they do. It's funny how the Game window does respect it though and the Scene window doesn't.

Oh well, if I find anything I will drop it in here for future reference.

Cheers

 

Back again, just to prove this is a real problem I ran fraps and got the FPS while moving around in the editor.

Here's my Scene window. It actually went well over 300 FPS

So clearly the Scene window is not being controlled by the Quality settings.

Getting worried about my expensive graphics card now

 

If the graphics card is hurt by rendering frames, there's something wrong with it; 300fps isn't even really that high.

--Eric

 

I think you are missing the point of vsync and how not controlling it can damage a graphics card...

 

No, I don't think so. You should be able to use the full capabilities of your card without damaging it in normal operation, and it's not required to use vsync as a normal operation. I've certainly never owned a card which was ever damaged by running "too fast", nor have I ever heard of such a thing. Cards will throttle down if they start to exceed thermal parameters in order to avoid overheating.

--Eric

 

Hmm yes I think I agree with you there actually, I can't say I have had a problem in that department with any card. My card has adequate cooling - it's a good design. It's just this whining that is new to me, so I was concerned as well as irritated...

 

It might be a fault in the card. I once had a card that had a few bits of bad VRAM, which would show up (depending on where stuff was located in VRAM) as wrong-colored pixels in textures, or vertices in models that were way way off. It was kinda annoying....

--Eric

 

I was reading about coil whine some more and it's just one of those things that can happen with electrical components sometimes, well so I have read. This has only happened on one game and Unity so far, since last year sometime.

I asked MSI who made my card about it and they said to enable vsync and that solved it. It's reassuring that my card is probably safe in the end. I'd just like to stop it running at silly FPS when it's unnecessary and in doing so stop the whining.

 

I know you mentioned using D3DOverider but have you tried forcing VSync in the Catalyst control panel directly? I haven't use an AMD card since they were ATI, but you can do this pretty easily on NVidia cards.

 

Yep I tried that in the AMD Catalyst control centre.

I have it set to use vsync globally and I also tried making a configuration just for Unity, none of this worked.

I think it's the problem that perhaps (not entirely sure atm) vsync only works on full screen. What with the Scene window being in a...well...window... seems to make it ignore the settings.

I don't think this can be fixed, I'll just have to put up with it.

 

I just tried in NVidia's control panel and it doesn't work either.

 

If you are having this issue again in 2019.3.0f3:


The "Stats" window may show more, i think it reports the maximum possible frames, even though it only renders one per vsync

 

Thank you, Marrt. Your screenshot helped me.

 

On a related note, if the aspect ratio is set to Free Aspect you will likely see screen tearing. Change it to better fit your monitor and it will go away.

 

just realized you gave some answers in 2020 in this old thread. i couldn't find any other info about his problem. so thanks.

i read up on the settings: Application.targetFrameRate, QualitySettings.vSyncCount and where do find it in Project Settings -> Quality

i STILL got the same problem: vsync gets COMPLETELY IGNORED. it sais in the docu, vsync overrides targetframerate, nonetheless, i can set targetframerate as i please while game is running and vsync is set to 1 or 2 and it has immediate effect.

i used this guys trick:

HOWEVER except for framerate < 10 the actual framerate is WAY off.
for 30 its actually about 60 and for 60 its actually >200.

the GUI setting in play mode in the resolution menu actually seems to work however. checking vsync there results in getting my roughly 200fps from unity info and about 110 fps from bandicam, which is the same when its disabled but targetfps=60.

with both settings to 0 and vsync unchecked in GUI i get 500+ fps from unity info and about 150 fps from bandicam. so the GUI checkbox does have some effect afterall (but not the field QualitySettings.vSyncCount).

and my monitor can only do 60 fps.


does this have sth to do with the fact that its not fullscreen?
i am fairly new to unity, so is this normal or am i doing sth wrong or not getting here.

 

Have you seen my post above?
https://forum.unity.com/threads/turn-on-vsync-in-the-editor-scene-window.276720/#post-5282394

The other Unity Editor windows have their own refresh logic afaik, but who cares about the refresh rate of these?

 

yes i was actually trying to refer to it. and thanks for your replies.

and your screenshot did actually help but also confuse me. the checkbox did have an effect, but the the code property did not for play-testing. is this intended? what about the standalone build? would be nice to have clarification which option has effect in which "version" (play testing in editor vs standalone build).

this is my code:

Code (csharp):

1.  
2. using System.Collections;
3. using System.Collections.Generic;
4. using UnityEngine;
5.  
6. public class redballdance1 : MonoBehaviour
7. {
8.     float direction = 1;
9.     public int targ_ = 60;
10.     public int vsync_ = 1;
11.     //GameObject go;
12.     // Start is called before the first frame update
13.     void Start()
14.     {
15.         QualitySettings.vSyncCount = 1;
16.         Application.targetFrameRate = 60;
17.         Debug.Log("vsync: " + QualitySettings.vSyncCount + "framerate: " + Application.targetFrameRate);
18.        
19.     }
20.  
21.     // Update is called once per frame
22.     void Update()
23.     {
24.         if (transform.position.x <= -6)
25.         { direction = 1; }
26.         else if (transform.position.x >= 2)
27.         { direction = -1; }
28.  
29.         transform.Translate(direction * Time.deltaTime, 0, 0);
30.  
31.         if(Application.targetFrameRate != targ_)
32.         {
33.             Application.targetFrameRate = targ_;
34.             Debug.Log("vsync: " + QualitySettings.vSyncCount + "framerate: " + Application.targetFrameRate);
35.         }
36.  
37.         if (QualitySettings.vSyncCount != vsync_)
38.         {
39.             QualitySettings.vSyncCount = vsync_;
40.             Debug.Log("vsync: " + QualitySettings.vSyncCount + "framerate: " + Application.targetFrameRate);
41.         }
42.  
43.     }
44. }
45.  

so i did the test again. today it seems the values were more accurate this time. around 60-70 (bandicam) fps for target=60 and also vsync.

what worked in play-test mode (didn't check standalone build yet):
-setting fps via code: Application.targetFrameRate
-checkbox for vsync actually did result in about 60-70fps.

this however had no effect, maybe my code is wrong though?
-QualitySettings.vSyncCount = 0 .. or 1 or 2

whats is also strange is, that last time, i did the same test but the fps were like 40% higher, maybe there was some weird stuff on my pc happening idk?

in any case the info-window fps still shows 100 when i set 60 ad bandicamp sais 66 and it shows 700+ when i seti it to unlimited and bandicamp show 150.
so what kind of "maximum" fps is this supposed to be? its clearly not the absolute max, since it actually is 1/7 lower when i limit the fps to 60, but it is still very inaccurate.

 

I cannot get v-sync to work in the scene view in 2020
only game view, but I need scene view because the screen it tearing when I rotate the camera

 

"cannot get v-sync to work" is to little information. How do you test? The fps counter in the "Stats" will report a false fps rate because it measures the time it took to perform the game loop, nit the time between frames

Build the standalone and test that.

 

I want it to work in scene view, in the build its working fine

 

I just started having this coil whine problem in scene view. Thanks Marrt, your post above helps but it does not totally fix the problem for me. If I run the game, then stop and go back to scene view, it will start whining again - I have to disable and and then reenable "Vsync (game view only)" *every time*. Pretty annoying, but less so than the whine. 2019 LTS.

 

Guys,

Scene view has no options about vsync afaik. Small side hint, if you experience lags, it is most likely because you have an inspector open on some object that constantly changes values. These redraw events in the inspector cause lags in the other windows. Try selecting an empty object in the hierarchy.

Coil Whine is not something related to unity i guess. I had it on an old motherboard where the powerstate of the processor was on low, try enabling high speed mode. But yours could be display related, turn off the screen and listen if the whining stops directly after turning it off.

 

Thanks, I dont have lags, just screen tearing when I rotate the camera, I can live with it, but it would be nice if vsync also worked in the scene view

 

Thanks, I'll look into that.

Fwiw it happens specifically when I move the scene view camera or move objects, though with this it is a little quieter. Even holding a mouse button while not moving the cursor causes it to whine.

I know the vsync toggle is just for game view, but it does fix the problem for scene view. Until it doesn't. So, I guess, initially it does force vsync for scene view, (since vsync fixes the issue in game view too) but playing and stopping game disables it again, when it shouldn't have been enabled in the first place.

So I guess it doesn't whine while nothing on screen changes, GPU has nothing to do, but as soon as the window needs to update, it tries to push max fps (~200 by the profiler).

So I would say it is related to Unity, as it is related to how it renders scene view and it seems like it could be fixed with a specific vsync option.

 

vsync in the editor is broken in 2019.4.13f1: when I force VSync count to every vblank on a 60hz screen, I get 1500fps on the game view! lol
Checking the "VSync (Game view only)" checkbox in the game view resolution menu has helped a lot, but it's still running at 80fps on a 60hz monitor! wtf?
Even forcing the target frame rate by script doesn't help:

Code (CSharp):

1.           QualitySettings.vSyncCount = 1;
2.            Application.targetFrameRate = 60;

Is it really that hard to get a real vertical sync in the game view now?? It was working just fine some Unity versions ago...

 

We have a custom camera movement control in the Scene view to make editing our maps easier. Enabling the VSync option in the Game view does actually seem to help the main Scene view despite what it says. It would be nice if that option could be added to the camera controls drop-down in the Scene view. With it on our camera movement is significantly smoother in Scene view.

 

VSync and target frame rate is also completely broken for me as well on 2019.4.12f1.

Setting the vsync count to 2 and enabling the toggle "VSync (game view only)" and the FPS stays at above 60fps, it seems like the "VSync count" on the quality settings is useless on the editor now since it only takes into consideration the game view toggle now (so no 2 or 3 vsync count tests on the Editor anymore).

Changing the "Interaction Mode" on Preferences -> General also won't change anything.

About the 'Application.targetFrameRate' setting, it is doing nothing on Android, vsync count set to 0, the FPS stays on 30, no matter what value I throw at targetFrameRate.

 

I'm still unsure what the exact bug is in the editor, but going to the Game view / Free Aspect drop down / VSync disable/enable and then switching back to Scene view seems to definitely provide a *much* smoother/consistent frame rate in the Scene view.

This stops working at some point possibly related to the editor losing focus and dropping to 10-15fps (or possibly recompiling script). At some point it definitely starts stuttering again, and I have to go back to the Game view and redo the VSync setting to fix it and have smooth panning in the scene view. It would be great if someone from Unity could look at this as it is super annoying.

 

While i agree that we should strive for excellence, I still don't get why you guys even need vsync to work in the editor so bad. Create Standalone, verify that vsync works there, done.

If you see heavy stuttering it is probably a heavy inspector that updates a lot of values, try deselecting the object to clear the inspector and check if the problem persists.

 

@Marrt For what I'm talking about, it is for *in-editor* tools. And there is a huge difference with vsync / stable framerates are achieved there. So if it's not an issue for you, then you're lucky, but for those of us that find it vomit inducing it would be nice if Unity would fix it as it does not appear to take much to fix.

 

Not everyone is building for standalone nor can make a build for every gameplay test, and it's very important that the game view updates exactly as in build to fix motion update issues accross kinematic and physics objects to avoid stutering in game. The devil is in the details.

 

There is a way to disable vSync in the Editor via reflection, just attach the following script to any gameobject in the Scene and it will enable/disable vSync in the Editor and Builds:

Code (CSharp):

1. using UnityEngine;
2.  
3. #if UNITY_EDITOR
4. using System;
5. using System.Reflection;
6. using UnityEditor;
7. #endif
8.  
9. namespace Game.Performance
10. {
11.     public class FramerateLimiter : MonoBehaviour
12.     {
13.         [SerializeField] private bool vSync = true;
14.         [SerializeField] private int targetFramerate;
15.  
16.         private void Start()
17.         {
18. #if UNITY_EDITOR
19.             Assembly assembly = typeof(EditorWindow).Assembly;
20.             Type type = assembly.GetType("UnityEditor.GameView");
21.             EditorWindow window = EditorWindow.GetWindow(type);
22.             type.GetProperty("vSyncEnabled").SetValue(window, vSync);
23. #endif
24.             QualitySettings.vSyncCount = vSync ? 1 : 0;
25.             Application.targetFrameRate = vSync ? 0 : targetFramerate;
26.         }
27.     }
28. }
29.  

Note: Tested in Unity 2021.1

References:
https://forum.unity.com/threads/is-there-a-way-to-get-the-current-editor-game-window-display.846040/
https://github.com/Unity-Technologies/UnityCsReference/blob/master/Editor/Mono/GameView/GameView.cs

 

Spoiler

 

It's a bit sad how both Unity and Unreal Editor seem to have no simple easy way to set up FPS limits for their editors. ( or at least not last i looked, ie. in UE you have to resort to a console command )

My guess is that they have monstrous dev machines at Unity HQ and Epic, so of course they don't really care. But that's not the case for every user out there.

I like to have my GPU live as long as it can, so i try to limit FPS wherever possible.

To the question about "who cares about the FPS in the editor" - in addition to just keeping your GPU stress low - i recently had a strange thing happening when switching the editor view to "2D" mode. About a second later my PC powered down because of some sort of power surge detection on the motherboard, but no other electric device showed any signs of that.

So i suspect it *may* have been the switch to 2D mode which *may* have caused the GPU to go into overdrive mode of some kind, drawing a low of power instantly and setting off a false alarm on the motherboard.

But that's just a wild guess, maybe i'm wrong.
If it was possible to properly limit FPS in the editor, i could at least be sure that this wasn't the issue, because i would know that GPU usage was limited in the first place.

And if it is indeed the cause of the problem ( i'm reluctant to try, because sudden PC switch offs are scary ), an FPS limit would have prevented it.

 

Not very nice, but a workaround, reduce your OS framerate:


Otherwise, if I don't missunderstand your problem, your surely know about "QualitySettings.vSyncCount" & "Application.targetFrameRate".
For the general Editor Windows like the inspector and such, yeah, they get a lot of updates in some scenarios and can impact the Framerate especially Inspector-Updates. But you can always close windows. For the Inpsector, just select an empty object in hierarchy and the inspector is easy on the framerate (if you haven't locked the Inspector)

 

FWIW, this option was seemingly moved in 2022b, it's no longer under "Free Aspect" (IMVHO it didn't make any sense there) menu, it's now under "Normal (Enter Play Mode)", as just VSync. The official docs doesn't reflect that, but it's there:

 

Eight years later, and this issue is still not solved. When in Unity editor (latest 2019) I hold mouse wheel to navigate across scene, my motherboard starts producing terrible coil whine audible across room. Which never happens in any other app or under any stress test software. After some experimenting I found out that this happens due to a bug in Unity Editor, which runs at 300 ~ 500 FPS while in scene view. And as other people reported earlier, "VSync (Game view only)" option fixes it in some odd way. Despite saying that it's "game view only" it actually affects editor scene window and locks FPS to your monitor refresh rate. Coil whine disappears.

The problem here is that this functionality is bugged. After launching Unity editor, you have to uncheck and check VSync (Game view only) to enable it. And every time after exiting play mode it stops working, and you have to repeat the same steps again every time to get rid of coil whine...

Is this a known bug already on the bug tracker, or should I submit a new report?