F for Frame Selected - why does it zoom out so much?

I've been using Unity for some years, now, and I know the interface like the back of my hand. I'm familiar with obscure functions and sneaky gotchas and yet... mastery of one basic command still eludes me.

'Frame Selected' usually centres the screen on the selected object, then zooms the camera so the object fills approx 1/4 of the available frame, automatically adjusting the scene camera's clipping planes to best capture the object visually. Which is great!

Except sometimes it centres the view on the object, then zooms out to capture almost the entire scene! This leaves me zooming the camera in, rolling and rolling that mouse wheel until I can actually see what I was trying to frame.

Don't get me wrong. It's a small issue in the grand scheme of things, and I can mostly work around it. It's just... a bit frustrating, a bit of a nag, especially if you keep encountering the problem. Given the galloping improvements Unity is always making, it's annoying this still pops up.

I'm confident that users will know what I'm talking about, but I can provide pictures later if neccessary.

Am I using the 'Frame Selected' command correctly? Does anybody out there have a fast workaround (other than laboriously zooming in) for when it seems to misbehave? Does anybody have a straightforward fix for the problem?

And now, back to work... =)

--Rev

 

I am not sure of all what it uses to frame the selection. But we use some curved shaders in our game. In order to make things render correctly we have to adjust the bounds of the meshes so the camera thinks they are still in view and does not cull them. Unity at least looks at the mesh bounds because now when we frame selected it positions the camera to view the modifed bounds not the actual mesh bounds.

You may have similar issues or have some object that is expanding the bounds unity is calculating to frame in the window.

 

Our fix is to select another game object not with a mesh at the location. Like a bone and frame that instead of the renderer.

 

These kind of issues are just as important because they can make your life harder for no reason and if ignored for a long time, could add up to many development hours from working around it.

I figured out that the view will zoom out very far on an object if it has a child object that is bigger than the root object. For instance I had a character with a large trigger box around it. Whenever I selected the character the view will zoom out to fit the trigger box.

However there is a few rules that it follows when it decides whether to zoom out or not.

-If the root object has a mesh filter with a mesh renderer, it will zoom to fit the root object
-if the root object has a collider, it will zoom to fit the root object
-if the root object is an empty gameobject, it will zoom to fit the largest child object

You can still have a large trigger around your character and have the view zoom in on the root object if you add a collider or mesh renderer + mesh filter to it. It doesn't even need to be enabled.

 

This is an issue I would also like to see resolved. After spending a little time on it, I don't know how much I entirely agree with roger0. That is, the parent relationship of the object you are framing does not seem to affect the level of zoom. At least in Unity 5.6 it doesn't.

I came up with a workaround that is not ideal, but does offer very good flexibility.

1. Create a sphere.
2. Disable the Mesh Renderer and Sphere Collider components.
3. Now depending on where you position the sphere, and how small or large you scale it, you have complete control over where the view zooms to and how far it zooms in or out when it's the selected object that you frame.

That's it. Kind of a waste of time but might be useful.

 

The

The child objects only effect the zoom level if the root object is an empty gameobject and the child objects have a mesh renderer + mesh filter and/or collider attached to them. If the root object has any collider or mesh attached it will zoom to fit the root only.

The viewport needs something to zoom in on, so it will prefer to zoom in on colliders and meshes opposed to an empty gameobject. If the root is lacking these, it will zoom in on a child object if they have them.

 

I had a similar issue with a prefab (F always framed the object and the origin together), and noticed there was a Line Renderer component on one of the child objects which was set to render in World Space. If you have a problematic object like this which does have children in the hierarchy, you can troubleshoot by selecting each child in turn and pressing F to hopefully see which one is causing the issue.

Mind you I have had this problem with some objects which had no children so it's not a silver bullet.

 

I am not sure if this is addressed as an overide in newer unity versions but you should allow an option for temporarly setting the bounds and frame selection as an overide feature that is based on an object pivot. This is madening when trying to design. I understand the logical reasoning for how your code above calculates the bounds and I understand that alot of people will never need another solution, but for those of us who do its frustrating and seems like a simple integration for a check box that says "from now on when the user selects a game object, it will frame select and zoom in close to the selected object based on its pivot, even if this requires setting a temporary "ghost" collider". Store these bounds in another area that when checked a zoom can happen on pivot point, or whatever you need to do to get the zoom based on pivot like most people are probably trying to do. A lot of indie developers don't always set everything up logically or correctly but we want to be able to do basic navigation even if we slopify the objects transform, collider positions ect.

 

Yeah, this has annoyed me for the last 5 years. The logic needs tweaking, or at least an override.

For example, if your object contains a disabled child with a Point Light w/range of 60, you'll be zoomed way the hell out every time you frame it. Ideally, Child objects that contain Lights, ParticleSystems, etc. should be ignored by the bounds check, especially if they're disabled.

I had to write my own frame script as a workaround, but I can't be the only one frustrated by this. It's one of those classic usability issues that irritates everyone but not enough to file a bug, so it just aggravates for years.

 

This is still an issue. And it's even worse now - sometimes an object will cause it to zoom all the way out, but if I inspect the object causing this (always a light), and then focus the parent again, it fixes itself.

Could you post this script, possibly? I'm guessing they are in no hurry to solve these issues.

 

Sure, it's just a quickly-and-dirty version of jvo3dc's code from:
https://forum.unity.com/threads/fit...ameras-field-of-view-focus-the-object.496472/

It simply focuses the first Renderer it finds. I explored encapsulating child meshes, but find this more "useful" in my projects when the built-in "F" key fails.

Press "ALT-F" to use. (I never use that key for opening the "File" menu.)

If anyone has time to improve it further, please do so!

Code (CSharp):

1. using UnityEditor;
2. using UnityEngine;
3.  
4. public class FocusSelected : ScriptableObject {
5.     [MenuItem("Edit/Focus Selected &f")]
6.     static void Focus() {
7.         EditorApplication.ExecuteMenuItem("Window/General/Scene");
8.         var scene_view = SceneView.lastActiveSceneView;
9.         if (scene_view) {
10.             scene_view.orthographic = false;
11.             GameObject selectedObject = Selection.activeObject as GameObject;
12.             Transform camera = scene_view.camera.transform;
13.             camera.rotation = Quaternion.LookRotation(camera.forward);
14.             Bounds bounds = new Bounds(selectedObject.transform.position, Vector3.zero);
15.             Renderer r = selectedObject.GetComponentInChildren<Renderer>();
16.             if (r)
17.                 bounds = r.bounds;
18.             const float cameraDistance = 0.5f; // Constant factor
19.             Vector3 objectSizes = bounds.max - bounds.min;
20.             float objectSize = Mathf.Max(objectSizes.x, objectSizes.y, objectSizes.z);
21.             float cameraView = 2.0f * Mathf.Tan(0.5f * Mathf.Deg2Rad * scene_view.camera.fieldOfView); // Visible height 1 meter in front
22.             float distance = cameraDistance * objectSize / cameraView; // Combined wanted distance from the object
23.             distance += 0.5f * objectSize; // Estimated offset from the center to the outside of the object
24.             camera.position = bounds.center - distance * camera.forward;
25.             scene_view.AlignViewToObject(camera);
26.         }
27.     }
28. }

 

I made some minor changes, like instead of focusing on the first renderer it finds, it instead loops through all renderers and encapsulates the bounds, but it ignores particle renderers.

I also made it use "f", not "alt f", since I wanted to replace the built in one. Later I hope to make it a bit better with the focusing :3

 

Alright, I made some pretty major changes, sorta replacing the entire thing in my case LOL
Since I made mine replace the built in one, I had to add new logic that doesn't override pinging the hierarchy and project window.

I also made it focus all selected objects, instead of just the active one, and it turns out there's a built in function that frames a bounds, so I used that Note I also set the "instant" parameter to false, to make it still focus just like in the old way. As far as I can tell, this is a complete replacement for the built in framer, but if there are an

Code (CSharp):

1. using UnityEditor;
2. using UnityEngine;
3.  
4. public class FocusReplacer
5. {
6.     [MenuItem("Edit/Focus Selected _f")]
7.     static void Focus()
8.     {
9.         if (Selection.activeObject == null)
10.             return;
11.  
12.         //Detect object is in project, so just ping
13.         if (AssetDatabase.Contains(Selection.activeObject))
14.         {
15.             EditorGUIUtility.PingObject(Selection.activeInstanceID);
16.             return;
17.         }
18.  
19.         //Detect hierarchy window is focused, so just ping
20.         if (EditorWindow.focusedWindow != SceneView.lastActiveSceneView || SceneView.lastActiveSceneView == null)
21.         {
22.             EditorGUIUtility.PingObject(Selection.activeInstanceID);
23.             return;
24.         }
25.            
26.         var scene_view = SceneView.lastActiveSceneView;
27.         scene_view.orthographic = false;
28.  
29.         Bounds bounds = new Bounds();
30.         bool created = false;
31.  
32.         foreach(GameObject obj in Selection.gameObjects)
33.         {
34.             foreach (Renderer r in obj.GetComponentsInChildren<Renderer>())
35.             {
36.                 if (r as ParticleSystemRenderer)
37.                     continue;
38.  
39.                 if (!created)
40.                     bounds = r.bounds;
41.                 else
42.                     bounds.Encapsulate(r.bounds);
43.  
44.                 created = true;
45.             }
46.         }
47.         scene_view.Frame(bounds,false);
48.     }
49. }
50.  

 

Nice effort! I haven't been to sleep yet and it's 10:30AM, so forgive any mistakes, but a couple things I noticed should you (or anyone) want to take this further:

1) The original "Frame Selected" doesn't check for EditorWindow.focusedWindow and then Ping. I'd just remove that block, as it's better to just go ahead and focus if you've selected something in the hierarchy and pressed "F".

2) Line 36: "as" should be "is".

3) If the object or its children don't contain a renderer, you're creating an empty bounds and focusing on that. You can add an "if (created)" at line 47 to bypass it, but we almost want to do something there?

4) The original will focus on a collider's bounds even if it doesn't have a renderer. That is good behavior.

5) Ideally there'd be some sort of "good distance from object" to fall back to when it contains nothing you want to encapsulate. i.e. it would be nice when Focusing a Point Light or empty GameObject if it just put you ~1 meters away and set the camera's min-clip accordingly. I think if your bounds defaulted to something nice it could work but I'm too tired to focus more myself...

 

I took some of your advice. The reason I added the focusedWindow logic is because this is replacing my "f key" logic entirely. In other words, it needs to handle both pinging the object in hierarchy and the framing, since those are both features that the f key do.

I also replicated how Unity handles objects with no bounds. If all objects have no bounds, then unity focuses on all of them. Otherwise, it focuses only one the ones that do have bounds. And I also added collision bounds.

It looks like if the object is a light (which counts as a non-bounds) or a non bounds, it focuses a meter or so away. If you want to tweak it, simply tweak the emptyBoundsSize value.

Code (CSharp):

1. using UnityEditor;
2. using UnityEngine;
3.  
4. public class FocusReplacer
5. {
6.     private static Vector3 emptyBoundsSize = Vector3.one;
7.  
8.     [MenuItem("Edit/Focus Selected _f")]
9.     static void Focus()
10.     {
11.         if (Selection.activeObject == null)
12.             return;
13.  
14.         //Detect object is in project, so just ping
15.         if (AssetDatabase.Contains(Selection.activeObject))
16.         {
17.             EditorGUIUtility.PingObject(Selection.activeInstanceID);
18.             return;
19.         }
20.  
21.         //Detect hierarchy window is focused, so just ping
22.         if (EditorWindow.focusedWindow != SceneView.lastActiveSceneView || SceneView.lastActiveSceneView == null)
23.         {
24.             EditorGUIUtility.PingObject(Selection.activeInstanceID);
25.             return;
26.         }
27.            
28.         var scene_view = SceneView.lastActiveSceneView;
29.         scene_view.orthographic = false;
30.  
31.         Bounds bounds = new Bounds();
32.         bool created = false;
33.  
34.         foreach(GameObject obj in Selection.gameObjects)
35.         {
36.             foreach (Renderer r in obj.GetComponentsInChildren<Renderer>())
37.             {
38.                 if (r is ParticleSystemRenderer)
39.                     continue;
40.  
41.                 if (!created)
42.                     bounds = r.bounds;
43.                 else
44.                     bounds.Encapsulate(r.bounds);
45.  
46.                 created = true;
47.             }
48.  
49.             foreach (Collider c in obj.GetComponentsInChildren<Collider>())
50.             {
51.                 if (!created)
52.                     bounds = c.bounds;
53.                 else
54.                     bounds.Encapsulate(c.bounds);
55.  
56.                 created = true;
57.             }
58.         }
59.  
60.         //Detect no bounds were added
61.         if(!created)
62.         {
63.             foreach (GameObject obj in Selection.gameObjects)
64.             {
65.                 if (!created)
66.                     bounds = new Bounds(obj.transform.position, emptyBoundsSize);
67.                 else
68.                     bounds.Encapsulate(new Bounds(obj.transform.position, emptyBoundsSize));
69.                 created = true;
70.             }
71.                
72.         }
73.  
74.         scene_view.Frame(bounds,false);
75.     }
76. }
77.  

 

Nice work! I've had a moment to try some things myself.

It looks like line 17 may serve us better as:

Code (CSharp):

1. if (EditorWindow.mouseOverWindow != SceneView.lastActiveSceneView || SceneView.lastActiveSceneView == null) {

Note the Editor.mouseOverWindow, which adds some functionality that was missing: if focus is in the hierarchy window, but the mouse is hovering over the scene, pressing "F" should focus the object in the scene.

Also, after re-reading karl_jones's post above, I noticed that encapsulation of children only happens when Tools.pivotMode == PivotMode.Center. I think that has been a major source of confusion for me as the ignorant user I am, as sometimes focus works nicely while other times it's zoomed way out for seemingly no reason.

To that end, after playing around with different ideas, I think the built-in Frame works fairly well in pivotMode==PivotMode.Pivot (minus the zooming-out for lights and ParticleSystems), and I'm not a fan of child encapsulation at all. I've also found I enjoy having a "maxExtent" value, whereby even large objects have a limit to how far away the camera will be from them. (I also like zooming-in 30% closer than Unity's default, so I added that as "zoomFactor = 0.7f".)

Anyway, here's how it's looking:

Code (CSharp):

1. using UnityEditor;
2. using UnityEngine;
3.  
4. public class FocusReplacer {
5.     static float defaultExtent = 1f; // if no renderer or collider is found, zoom to an object of this size
6.     static float maxExtent = 20f; // controls the maximum "zoom-out" when focusing large objects
7.     static float zoomFactor = 0.7f; // zoom-in more than Unity would by default (1f)
8.  
9.     [MenuItem("Edit/Focus Selected &f")]
10.     static void Focus() {
11.         if (Selection.activeObject == null)
12.             return;
13.  
14.         //Detect object is in project, so just ping
15.         if (AssetDatabase.Contains(Selection.activeObject)) {
16.             EditorGUIUtility.PingObject(Selection.activeInstanceID);
17.             return;
18.         }
19.  
20.         //Detect hierarchy window is focused, so just ping
21.         if (EditorWindow.mouseOverWindow != SceneView.lastActiveSceneView || SceneView.lastActiveSceneView == null) {
22.             EditorGUIUtility.PingObject(Selection.activeInstanceID);
23.             return;
24.         }
25.  
26.         Bounds bounds;
27.         Bounds allBounds = new Bounds();
28.         foreach (GameObject obj in Selection.gameObjects) {
29.             Renderer renderer = obj.GetComponentInChildren<Renderer>();
30.             Collider collider = obj.GetComponentInChildren<Collider>();
31.             if (renderer && !(renderer is ParticleSystemRenderer)) {
32.                 bounds = renderer.bounds;
33.             } else if (collider) {
34.                 bounds = collider.bounds;
35.             } else {
36.                 bounds = new Bounds(obj.transform.position, Vector3.one * defaultExtent);
37.             }
38.             if (allBounds.extents == Vector3.zero)
39.                 allBounds = bounds;
40.             else
41.                 allBounds.Encapsulate(bounds);
42.         }
43.  
44.         allBounds.extents *= zoomFactor;
45.         if (allBounds.extents.magnitude > maxExtent)
46.             allBounds.extents = allBounds.extents.normalized * maxExtent;
47.         SceneView.lastActiveSceneView.Frame(allBounds, false);
48.     }
49. }
50.  

 

@karl_jones in which version is this update coming?

from https://aras-p.info/blog/2020/01/04/Fourteen-years-at-Unity-o_O/

 

Does it properly frame lights and particles?

 

Thanks Josh, this was a real gem. I struggled with this way too long. Framing being fixed in 2020 is a joke.

 

just having this issue now with my ai, theyre a spec in the distance when I focus on them,, hope 2020 fixes.

 

@Aras
The way I create a character or a prop prefab is that I create an empty game object (name it Character), drag a FBX model as its child and add a Character script and an AudioSource as its components. I then create a prefab out of that empty game object called Character.

When I then select the Character and want to Frame it, instead of framing the mesh, camera zooms out to encompass the entire 500m radius AudioSource.

But... even if I would add that AudioSource on the FBX model instance, it still won't work, as my FBX model is using LODs, which are children of the FBX model instance, and the Frame command would still pick the AudioSource first.

Is there a way to maybe expose some API so I could in my own Character(or whatever) script override the bounding box for the Frame command?

 

Thanks, Aras! That worked!
I do hope that the framing logic will change though, with renderer bounds having a higher priority over everything else in the hierarchy (colliders, audio sources, etc). At least use the inner radius for Audio Sources.

 

LOL. This thread was created 3 years ago.

Today June 2020 I just upgraded to latest LTS using 2019.4 and I'm a bit disappointed that Unity Technology still can't build a proper Frame tool that you probably use on daily basis as a developer! You guys made better in this forum.

@Aras, My suggestion is to to actually remove the non working feature instead of having a broken implementation!

Try using F on any object on most objects in a scene and watch the camera zooms out to about 250m away from the object.

The FocusReplacer puts the camera about 2 meter from the object. I would like to have it even more zoomed in but it's at least 100 times better!

Thanks for a working Frame tool! I'll have to add this FocusReplacer for every unity project I'm working in.

 

or how about clearly click on an object but the freaking UI or canvas is blocking your selection. They need depth selection in a sense that if my mouse is over an object and I click on it, regardless if something is in front it bypasses all UI if I have that option on selection enabled and will then attempts to grab the actual object. instead it selects everything else not visible under my click. how about the ability to select only objects that have mesh enabled and are non ui. You should be able to customize how the selection works and it should work a lot better. the selection should allow EASY and close mouse wheel scrolling into view of the object, I mean basically the way its set up is not logical when you think of the process of trying to focus and zoom on an object. Regardless of how its built, how it should function, was not meant to be design that way, it should anyways be built the most logical way, which is 99% of users when trying to click on an object in their scene want it to focus on the visible object under their mouse and it needs to be able to be zoomed into and focused on in a logical common sense way with full customization of control. You should not force users into using the most basic and most important tool in unity, the selection tool which is the foundation for all object placement and selection when working in the editor. Unity has completely overlooked this and if Unity is going to be the easiest and the best tool it HAS to have these features.

 

In particular, the camera on an XR Rig when using XR Interaction package has a high FOV of around 60 - 80 and also a distance of 1000, meaning that if I use 'F' to zoom in on anything under a hierarchy containing that camera in the rig, it zooms out like 1000m from the gameobject I want to zoom in on!

 

Is there not a way to do a frame based on transform.position or the likes as opposed to the bounds. Wouldn't this make more sense to have the same scroll in and out of view for ALL game objects by focusing on all gameobjects transform.position center and not end up with all these whacky zoom levels for all objects. This is not a bug, but the way Unity works with bounding boxes it seems, when it comes to focusing and zooming in the inspector.

I just feel like most developers simply want to have the same zoom level and speed on all objects and then allow them to adjust this in the menus as far as zoom levels/speed or other options. I think most developers are simply wanting to focus on the objects center and zoom in on it, no matter if its ui, a rock or a 700 meter elephant from some sketchy asset store designed by a guy who just got off youtube blender tutorials. It seems like every object has some screw ball zoom sensitivity and whacky focus distance. Yes, this is the objects issue with bounding boxes but why not simply get rid of bounding boxers for focus and zoom and use a another method if possible or one click center pivot/whatever it takes to normalize all assets center if users are getting unsatisfying focusing distance and zoom levels?

 

Are you going to be doing anything about the behavior of using F to focus on empty game objects, or game objects that don't define an explicit bound? I realize there's really no way to know what a user would expect for a zoom level for empty game objects, but it's definitely annoying when I try to focus on a small game object, and it zooms out to 50m away.

For example, let's say I click on a bone in a rig. The bone itself has no visible children, it's just a transform. If I Focus on it, to get tight zoom around that small area, I get zoomed out to 50m or so away from the object. Very annoying.

Could you maybe give users a setting they can change to control the desired default zoom level when trying to focus on a game object that doesn't contain something that explicitly defines its bounds?

 

F-key focus used to work great until recently. Now it's completely broken.

 

Can I suggest that pressing F multiple times just cycles through some logical focus presets?
eg Just renderers first, then logical things like spotlight/audio range

Also, focus presets could be assets, where you tag types of components + layers to care about.

 

I think that's a great idea.

I can't speak for the person you're quoting, but the main issue is how F zooms way the heck out in cases where there's no implicit bound to infer from the object. The example I always get annoyed with it focusing on armature bones, which are just transforms without any other components. Let's say I'm going to do some animating, and I want to focus on one bone. Here I am before hitting F:



And now I hit F:



The thing I've circled there is the model I showed in the first screenshot. "F" zoomed out to something like 20-30 meters away.

These days I mainly think of "F" as a way to zoom out more than anything else. For zooming in, I've started using the FocusReplacer script described earlier in this thread, just hard-coding the zoomFactor to something very low. I've also mapped this to the numpad "." button, which gives me some muscle memory from blender.

Anyway, really the only problem with "F" is the incorrect amount of zoom. The idea @Vectrex suggested seems pretty solid. Maybe even add a preference for setting the F "steps" that get cycled through. Or just give some reasonable defaults as you cycle through it: 1m -> 15m -> 0.1m -> 1m, etc...

 

@Aras

Here is what happens when I F-key on my character's mesh


Here's what happens when I then zoom in towards it a liitle bit with the mouse wheel.

 

@Aras Please don't frame AudioSource's max radius, it doesn't make any sense.
This breaks framing a lot, because AudioSource is part of many prefabs / objects / props.
I don't see much use case for framing AudioSource's max radius, i'd rather see frame button in AudioSource when someone needs it, because it's so rare.

Framing just render bounds / collider should have higher priority IMO.
- so when there's renderer / collider in child hierarchy of selection it should frame that
- when there's no renderer / collider in child hierarchy of selection, it should frame anything

 

Considering the default AudioSource sets Logarithmic Falloff at 500 units, this does seem a little ridiculous. Just confirmed this is still the case in 2020.1.6f1. Even at 10 units, the amount of zoom out seems excessive.

 

It's been sitting here a long time without any response from Unity, is AudioSource framing getting fixed?

I'd fix it myself but it seems impossible, because Framing method is extern (Unity internal C++ code).

 

One situation I often notice with this is when I have a particle system attached (such as a trail of smoke), it seems to frame the entire global particle system. Its probably fine to ignore the particle system when framing IMO.

 

Hey,

This is on 2019.4.12f1:


Something is not right...

 

Popping in to second the opinion that framing should definitely ignore AudioSource bounds and really anything that's gigantic with default settings. This has seemingly gotten worse in 2020, so fingers crossed on a fix.

 

I don't know how stuff like this makes it past a single dev review. Does Unity not use their own tools? Including an audio source's distance is completely ridiculous.

 

I am having issues with framing particle systems, because their bounds are only updated when playing. Inspecting a prefab made of a particle system, I will first have to play the particle system (click replay), and then smash F in the hope to land at a frame where the bounds make sense. Does anyone have a better workflow to frame a particle system?

It's not easy to find the best design here. Unity would have to simulate the particle system and average the bounds over time before framing. Quite an effort...

 

Still an issue in 2020.1.9

In all seriousness: No, they do not. This is why we have abysmal editor performance and years of unfixed editor bugs. It's Unreal that uses their own tools.

This is why every single script in the entire project will recompile if you edit a comment in a .cs file, for example.

 

You can use assembly definition files to break down your code base into individual dll's and only those will recompile. Unreal will also have to recompile when you edit scripts.

Using 2020.1.17f1 framing does not seem to frame audio sources unless they are the only component that can be framed.

 

Hi!

Stupid question, but have you tried pressing F twice in a row? We have objects on which "F" zooms out kilometers away, requesting a second time actually zooms-in properly.

I'm not sure if it's the same issue, but this helps me a lot, so just wanted to point it out

 

It's sad that 4 years later, in mid 2021, the issue is still there. And it's not about the character bones or sound objects, I'm getting this with almost every object in the scene.

 

using this script by pressing alt+f , fixed unity "F" focus function for some reason

Thanks