Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Feedback Working with Unity for 16 months 8 hours a day - these are my pain points

Discussion in 'Editor Workflows' started by Xarbrough, Jun 23, 2019.

  1. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    752
    I'd like to share some issues I've had with the Unity editor while working on multiple professional projects. I've compiled this list with the help of team mates and tried to focus on things that affect multiple members of the team. I really enjoy working with Unity and want to make it better, so please take the criticism as tough love. :)

    About Me
    I've been using Unity since 2013. I studied game design and computer science and have been working at both software and game companies. In total I've worked on about 10 real-world projects (released games, VR experiences, software). The projects were between 6 weeks and 6 months with team sizes of about 10 people. I focus on programming, editor tools, general workflows, all things engine and technical.

    1) Feedback loop for the Issuetracker
    Bug reporting with Unity works well. I've reported dozens and always received fast replies and relatively quick fixes. However, many of these replies are personal emails and the community doesn't benefit from them. Also, labels such as "By Design" or "Won't Fix" need explanations. Some of these issues do show comments, but most do not. Beyond the basic issuetracker system I would hope for improved communication directly from developers in cases where technical details should be shared.

    2) Assembly Definition Files are difficult to work with and benefits are unclear
    This is a whole topic on its own, but in short: asmdef breaks the established special folder name "Editor" convention used by almost all tools and it's a pain to maintain. It would be perfect if we could somehow make it work to define our custom asmdef for our own code but also let third party plugins use their Editor folders. Currently we always need to restructure third party tools which can take a long time. Additionally, the overall performance or workflow benefit of asmdef in Unity is hard to tell. Without having hard numbers (I've only checked compiled seconds in a few projects), I'd say that asmdef is even slower than not using them and the workflow of setting up dependencies has been difficult (mainly because of third party code).

    3) Editor navigation is cumbersome
    The project window and inspector really needs breadcrums and back/forward buttons and shortcuts. In fact, navigating assets feels brittle, because I need to always pay close attention to what I currently have selected. When I edit an important prefab or ScriptableObject and god forbid I click somewhere else in the project, I lose my current context, because I forgot to lock the inspector. Then I go back and try to click the tiny lock icon, now I need a second inspector with a few clicks and then I start editing my data, but everytime I change context I need to start over searching because there is no forward or back button.

    4) The Hierarchy window is hard to navigate
    A real-world project has hundreds, thousands or ten thousands of GameObjects. Drilling down into such a hierarchy is incredibly frustrating, because you either lose all of the context when drilled down too many steps deep into a large tree or you need to start searching from the top again to find other objects. The view gets cluttered easily when many objects are expanded. We often implement a "collapse all" button to start over with all GameObjects collapsed. A common pain-point is editing multiple objects or doing side-by-side views. We've made the experience that we spend much more time switching between objects or comparing different contexts than actually only editing a single item.

    I'd like to see shortcuts to expand and collapse all scenes but the active one and for collapsing all GameObjects. Additionally, maybe some sort of focus mode like the new SceneView Visibility could help editing many GameObjects.

    5) No real folder objects in the hierarchy and no place for data without a position
    I'd say a third of all GameObjects in our scene are empty and should be positioned at the origin with no rotation and scaling of one. That's at least three things that go wrong when level designers work on the project. We desperately need real folder objects. I'd like to avoid the performance penalty and issues caused by Transforms used only for organization. This also counts for all objects which do not need a physical presence in the scene. GameManagers and data-scripts do not need a Transform and do not need to be part of the hierarchy used for building level objects. As a level designer, I don't want to see all these managers, but as a programmer, I want to configure scene data not related to the virtual 3D world, which brings me to the next point:

    6) Unity should provide UI focused on workflows
    Window layouts are a good start, but the truth is, that something like the Hierarchy window can be focuses more on specific workflows. Our level designers only want to focus on seeing 3D objects in there scene, while programmers look for a separate view of data about a scene. Unreal, for example, provides different windows for editing custom data for the global game, specific scenes and then a different view for editing a level.

    7) Moving assets in the project view is slow and feels dangerous
    I try to keep a clean project for my team, but I understand that most of us are afraid of touching anything related to assets. Moving any asset in the project causes a massive freeze, either because of reimporting, recompiling or assembly reload. It's all just painfully slow and feels brittle. We've had it numerous times that users accidentally dragged an asset and moved it into some unknown folder because they tried to select something but then the editor locked up. The entire AssetDatabase feels brittle and dangerous. I've tried to disable "Auto Refresh" but it only stops recompiling after editing a script, but still hangs when moving assets.

    8) Asset search needs to be more powerful
    I was about to write, that the search is slow, but it has actually improved dramatically compared to a few Unity versions back. Instead, I still think that the search is lacking some love. We can't search for the type of assembly definition file, for example. Also, searching for sprite textures is a common thing for us, but it has an annoying problem: We actually want to search for the sprite texture asset to edit the texture import settings. Instead, it shows the sprite sub-asset which cannot be edited. We want to filter for textures, which are of type sprite.

    9) The AssetDatabase and importer API has room for optimizations
    We write a lot of custom importer scripts, AssetModificationProcessor, SceneProcessor etc. As does Unity and plugin developers. Now we have dozens of scripts in our project which all run on import and each one of them receives all global callbacks for many things which they are not interested in. For example, when importing a custom mesh with special settings, why do I have to check the file path of all other imported models? If we are only talking about a single script, this doesn't make a difference, but with many importers, Unity could gather all the different interests and distribute callbacks for specific assets. I'd like to register callbacks for specific assets, specific scene changes, etc. The current system forces me to write boilerplate code and is quite slow.

    10) Assembly Reload is too slow
    Working with assets, scripts or play mode is incredibly slow. The first playmode enter after opening a project takes more than 30 seconds, later its around 10 seconds, but they add up and feel incredibly unproductive. I've also worked on a large indie project with loading times of exactly 7 minutes per scene in the editor. I know people say this should not be the norm and that "something is going wrong", but I've seen this with every project in the past years. There is no way around building large scenes or doing some amount of processing etc, however it all comes down to assembly reload. Compile times are ok, import times are understandable, but assembly reload takes up most of the times, when it feels like the editor freezes and wastes my time.

    11) Almost everything runs on the main thread
    Some days I feel like I'm getting paid to stare at that tiny lock icon at the bottom right and it makes me smile, but then also cry. As a programmer, I understand that certain things take time, but why can't I work on other things while Unity does it's thing in the background? I want to create script, then while it is being imported, create a GameObject, name it, move it, while I wait for the script to become available. Let me import a few folders of model assets and then start setting up some of those hated folder-gameobjects in the scene. While it's importing, I wouldn't be able to save the scene or change any assets on disk; all of it should be locked to prevent issues, but within the safe memory of a scene, I could get to work already. Or even if all edit-operations were locked, but the UI remained responsive, I could start looking around at some settings and prepare myself instead of contemplating if this freeze will be long enough for coffee.

    12) Menus have too many unorganized entries and no icons or colors
    The create menu is simply too long. A lot of other menus are hard to read. They would benefit from icons or colors. Compare with menus in Maya, for example. There I have much better visual clues which I can remember instead of having to read through the gray list of text. All in all, menus in Maya feel so much easier to read and better organized than in Unity.

    13) Configuring (custom) menu items and toolbars needs a rework
    We can add custom menu items to many places, which is a nice feature, we use extensively. However, hardcoded strings and attributes in code are a pain to maintain. I would like to see this handled more like the new shortcuts in the shortcut manager. Users should be able to show/hide specific menu items, such as third-party tool entries. I want to use Cinemachine, but I hate their giant top-level menu entry which I never use. Now think of all the other developers who add their stuff in random locations. Users need a way to fix this on their end and simply organize menus how they need them. See Maya or Visual Studio. Tool developers should be able to add menus or even more custom toolbars (the single toolbar icon since 2019.1 is nice, but we want more), but users should be able to disable them on their local machine. It would be fine to make all official/builtin menu items fixed and only allow changes to custom menus.

    14) ProjectSettings/UserSettings pains
    For example, StackTraceLoggingType or scripting defines is something I personally configure, but other developers on the team do not want to have this as shared setting, maybe it should be a local user preference. EditorBuildSettings is something important for the project, but many of our developers need their own local build configuration as well. Ideally, we would be able to define all of these important settings as project-wide defaults, but then each user could override any setting on their local machine. I know this would cause problems for beginners, it's indeed a pro feature, but that's what expert settings are for, it could be off by default.

    15) EditorPrefs is easy to use but awkward
    I use them all the time, but I still don't know if it is ok to call into this API every frame. It's hard to measure how fast or slow it is or what happens to memory, etc. How much data does Unity actually write to disk? What happens to all the old data some third-party tools forgot to clean? Is all of this slowly filling up my registry with no way of cleaning up? Instead of writing to some hidden location in the registry, I hope for Unity to change to a system with settings files, which can also be copy and pasted between machines, something we cannot do easily with EditorPrefs. Unity could have it's own set of official user settings files (similar to the ProjectSettings folder), but also provide a way for tool developers to add their own user data to a location which is known and visible and managed by the user.

    16) Unity windows are not real OS window
    There's already a thread about this topic. I too think that Unreal handles windows much nicer. I'd like to see real operating system windows and better layouting/tabbing. Tool developers want to create a full-size uber window with multiple child-panels and undockable parts so users can pick their setup, but they are still managed via the main tool window. Currently, our animator is struggling every day with the fact that the Animation window cannot be truly maximized. It's a floating window with the same size as the monitor, but every so often a user accidentally moves the window instead of adding a new keyframe and suddenly the header bar is off screen.

    17) Please optimize editor performance
    I love editor code and it hurts me to see the Unity source or profiling callstacks for so many functions. The editor is simply slow. Our SceneView and window scrolling is lagging. When I try to profile the editor I only find the usual stuff happening, but all together it's too slow to keep up. I see some of these problems are being worked on right now, such as the calls to retrieve custom attributes all over the place, but overall it looks as if editor performance was low on priority and it should not be. The editor is our main work horse, it needs to run smoothly all day long. It's gotten slower over the years and in our current project it's at a point where our animator is having trouble previewing animations, because the editor cannot keep up 30 frames - and this is for a mid-sized 2D project.

    Real projects rely on custom tools and Unity needs to leave some room for these tools to execute. For example, a few unnecessary repaints of the Inspector or SceneView may not hurt performance when running a fresh project, but after time we implement custom tools, which all need to be redrawn when specific events are triggered. This is where I try to optimize my personal tools to the point where they are almost invisible, but they still show up because of the amount of tools and things happening. Unity needs to pull on this rope as well and optimize their editor code. I could point-out multiple locations in the source where lists are allocated every frame and easy-to-fix things like this for example.

    18) It gets worse with big projects
    It feels as if all performance issues scale linearly with the amount of assets and the size of scenes in Unity. Big projects are barely manageable in Unity.

    19) What is dirtying my scenes and assets?
    In every project we run into issues where some tool (usually something from the Asset Store) dirties an asset or a scene and it's impossible to tell who the culprit is. I'm hoping for an API which lets us track who is dirtying objects so we can write our own tool to check for issues.

    20) Unity sets assets dirty without changing their content
    ProjectSettings, XRSettings and a few other assets are often set dirty by Unity and show up as changed in version control although their contents have not changed. This is a real problem when working in a team and version control context. It's ok for me to revert a few files each day, but it's also causing confusion for other non-technical team members. This has gotten us to a point, where I've noticed some of my custom tools which generate custom metadata were seemingly not saving data correctly until I realized that our level designer has gotten used to discarding all changed files but their scene files because they are accustomed to Unity changing "random files".

    21) Provide an API to add to preloaded assets
    This is part of a request for making it easier to programmatically add data to the build. We often want to inject tooling or special data which does not live in the project, but gets generated during a build. However, there is no official API to support this. A first step would be to add a public method for adding to the preloaded assets list.

    22) Builtin packages can be excluded but Unity and developers cannot check for them
    The new packages system is great. I also like that I can disable packages and exclude builtin modules. However, this can lead to compile errors with other tools which depend on them; but in fact, they don't. For example, I want to disable the VR and XR modules, because we're developing a 2D and I also want to use Amplify Color as a plugin, which supports VR as one of many use-cases. Now I need to include the VR module although I don't use any VR functionality because there is no API which Amplify can use to check for the presence of said module. Can we maybe add preprocessor symbols for packages?
    See: https://forum.unity.com/threads/add...processor-defines-for-builtin-modules.698291/

    23) GenericMenu is not scrollable (KeyCode and Animation)
    Has been brought up many times and still an issue for my team and me.


    24) Creating script assets is slow and cumbersome
    I hope that script creation can be made faster and have a better user experience.

    When I create a new script asset, it's highlighted for renaming, then I accidentally click somewhere else or need to unfocus Unity because I want to lookup some info to pick a good name for the file. Unity starts importing and I have to wait 15 seconds until the editor-lockup is over. Now, I rename my script, wait 15 seconds again. And then I realize that I need to do it 5 more times (because it's a common thing to create a base class, two variants and editor classes for each).

    Using the 'Add Component' button in the inspector solves the renaming issue: Here I add the component right where I need it and can also pick a name before the asset is created, but only a single one and it doesn't prompt me for a file location. Instead, new scripts often clutter up the Assets root folder and have to be moved later. This is another problem, mentioned later, because moving assets is so slow.

    To solve the hassle, we can use third-party tool or create text files outside of Unity and only import once, but I feel these kind of workarounds should be addressed, when dealing with such elemental parts of the engine.

    The next part is the actual script default content. When coding 8 hours a day, every day, it gets pretty repetitive to change all the boilerplate, so templates to the rescue. And Unity does have some sort of script template, but configuring them feels like a hack. The templates only work for a specific Unity version and need to be copy pasted manually after every installation.

    What I would like to see implemented: A script wizard which lets me create a number of Unity scripts with templates. It should allow me to specify multiple different templates and save locations at the same time, then batch create all of them. I would provide info such as: script name, location, preset type. The presets can be saved and loaded as a user settings on my local machine, but also as part of the project.

    24) VSync
    In Unity I can set up: 60, 30, 15 frame intervals. What I'd rather have: 60, 30, then, when performance drops below 30, disable VSync. And have the intervals be configurable per platform, because these issue may only be relevant to e.g. consoles.

    25) Impossible to have smooth camera movement and animation
    This is also a separate thread, but I notice it in every new project: In a clean project, almost empty scene, without any sort of performance impact being related, it seems to be impossible to achieve a smooth camera pan or animations. There's always some sort of micro-stutter or frame hitches, which do not show up as spikes in the profiler, but are visible on screen. It must be something about VSync or the way the render loop works in combination with specific monitors, but I can only say, that I recognize Unity games because of those hitches and I don't see these problems with other games and engines.


    Thank you for listening and I'm looking forward to a bright Unity future! :)

    Edit: I know this is a long read and some of these requests are their own thread already or should be in the future. However, I do want to bring the point across that all of those issues combined affect my daily work. Looking at each issue at its own would seem like a minor thing, but many of them happen every day for our team.
     
    Last edited: Jul 31, 2019
  2. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,004
    This can be edited on a per-project basis; details. It's (afaik) not really documented, so it's no wonder nobody knows about it.

    Have you tried the preview of the Quick Search? It's an incredibly powerful tool. I'd take it over any other feature Unity has made the last few years.
     
    Last edited: Jun 26, 2019
    SugoiDev and Xarbrough like this.
  3. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    752
    @Baste Thanks for both of these suggestions! ScriptTemplates as a special folder names is indeed new to me and I think that would already help. I've seen the QuickSearch and also think it's a great addition, I can't wait for it to finish.
     
  4. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    7,379
    Seams like multiple points would be significantly improved, if disabling auto refresh in Unity and getting use to manual refresh (CTRL + R).

    Visual Studio can be nicely used, to create your new cs file templates.
    Probably is more preferable way, to create new scripts.
    When done, then refresh manually Unity Editor.

    There are also known issues with assembly files, which discussion can be read on this forum. Some people decided not to use them, while for others, their work fine.
     
  5. willgoldstone

    willgoldstone

    Unity Technologies

    Joined:
    Oct 2, 2006
    Posts:
    776
    @Xarbrough Thanks so much for the detailed breakdown, we're taking a look through it internally and i'll get back to you with a few suggestions and insights into the roadmap we're on to fix / address what you're raising here.
     
  6. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    891
    A typical issue that is unrelated to performance and often confused with this is that it's tough to figure out when and where to put your camera logic.
    The short version is to update your camera position in LateUpdate. if you do things in there in other scripts that would invalidate the position you are setting the camera too, ensure a ScriptExecution order where the camera update runs after that.

    Once that is no longer a problem, the thing I see in all kinds of made with unity titles is a regular interval frame drop due to garbage collection. For that, use the Profiler to guide your optimizations to come down to 0 GC.Alloc in your gameplay flow. Way easier said then done, I know. There is also the Incremental GC in >2019.1 that can ease that burden, but that won't save you if you thrash the managed heap with too many allocations every frame.

    Also, Profile the Game in a build player, not in the Editor. Select the PlayerLoop sample if you think the CPU Usage graph did not show a frame drop that you saw happen.
     
  7. IsaiahKelly

    IsaiahKelly

    Joined:
    Nov 11, 2012
    Posts:
    347
    I completely agree with this point and have actually made the same suggestion before. It would be such a simple yet powerful organizational and performance improvement for the current OOP workflow. I only hope such a feature is possible and easy to implement.

    A very common stutter issue in Unity is caused by using fixed update for movement. There is an excellent in-depth article on the subject here: Timesteps and Achieving Smooth Motion in Unity. I think this is a subject Unity documentation and tutorials should really focus on some, since it's such a common pitfall.
     
    Lars-Steenhoff likes this.
  8. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    752
    Thank you for the replies!

    Regarding the camera stutter, I'd like to reiterate that I'm not at all talking about beginner mistakes or performance. I can't really prove a real fixable bug, but Unity is showing much more micro stutter than other engines or 3D applications. An empty scene with a simple camera rotation animation and no code at all will produce frame hitches from time to time, but these are more or less apparent depending on a users monitor (with vsync enabled or disabled). For now, I can only say that there are multiple other community threads about this topic and there seem to be more people like me who believe that the way Unity syncs to the refresh rate is not optimal when compared to other engines. But actually, let's focus on usability first, this is why this point is last on my list. ^^
     
  9. APSchmidt

    APSchmidt

    Joined:
    Aug 8, 2016
    Posts:
    3,784
    Using empty game objects as pseudo folders is perfect for that. No need for "real" folders.
     
  10. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,118
    According to various Best Practices and Unite talks, using empty GameObject's as folder is not a good solution:
    https://unity3d.com/learn/tutorials/topics/tips/large-project-organisation

    Unfortunately we don't have a "Folder GameObject" that by-passes those hierarchy transforms yet. I guess that's the feature request here.
     
  11. APSchmidt

    APSchmidt

    Joined:
    Aug 8, 2016
    Posts:
    3,784
    You don't need to pile up empty games objects like Russian dolls. One is enough in which you put all your lights, or cameras, or whatever.
     
  12. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    752
    Yes, exactly. Performance is one of three reasons why dedicated folders would be better. The other being, that regular Transforms introduce another failpoint during production with designers scaling or positioning these empty Transforms unknowingly/accidentally and finally, folders would be much better represented as folder icons in the hierarchy and could add additional features in the editor, such as locking or filtering by folder during edit mode.

    Edit: For reference, most of the projects I’ve been working on in the last years required thousands of objects per scene. We would have gone crazy without custom tooling which faked folders. Also, it always looks easy in toy examples published as beginner tutorials where there are only a few objects in a scene. Sure, just nest them under “Managers” or create pseudo GUI separators by placing funny Ascii art in the hierarchy like “=== Managers ===“. That’s not an option when making a real-time strategy game.
     
    Last edited: Jul 25, 2019
    Peter77 likes this.
  13. APSchmidt

    APSchmidt

    Joined:
    Aug 8, 2016
    Posts:
    3,784
    Except that anything that is in the hierarchy view as a part to play, is active. Folders cannot be active, hence the use of game objects as pseudo folders. It's up to you to make sure you use them wisely. Unity cannot do everything for you.
     
  14. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,004
    Folders-objects would be incredibly good. They'd both be able to get rid of the (considerable) cost of folder-transforms, as well as provide a proper abstraction for folders.
     
    Peter77 likes this.
  15. IsaiahKelly

    IsaiahKelly

    Joined:
    Nov 11, 2012
    Posts:
    347
    That is true, but I do not think such an attitude is at all helpful when discussing possible features. It feels a little too dismissive and nonconstructive. Which actually makes me wonder why you are so against the idea?

    Unity has added many small additions to the editor over the years and this one could actually improve both workflow and performance. So I don't see any downside to it. Not sure what you mean by "folders cannot be active" because I thought that was the whole point. Perhaps you do not understand the concept.

    Yes, for now you can simply create a script like this to give you a similar effect:

    Code (CSharp):
    1. using UnityEngine;
    2.  
    3. public class FolderObject : MonoBehaviour
    4. {
    5.     [Tooltip("Delete this folder object at startup.")]
    6.     [SerializeField] private bool m_RemoveOnStart = true;
    7.  
    8.     private void Reset()
    9.     {
    10.         // Automatically lock the transform.
    11.         LockTransform();
    12.     }
    13.  
    14.     private void Start()
    15.     {
    16.         if (m_RemoveOnStart) RemoveFolder();
    17.     }
    18.  
    19.     [ContextMenu("Lock Transform")]
    20.     private void LockTransform()
    21.     {
    22.         transform.hideFlags = HideFlags.NotEditable;
    23.  
    24.         // Make sure default values.
    25.         transform.position = Vector3.zero;
    26.         transform.rotation = Quaternion.identity;
    27.         transform.localScale = Vector3.one;
    28.     }
    29.  
    30.     // In case we need to unlock it for some reason.
    31.     [ContextMenu("Unlock Transform")]
    32.     private void UnlockTransform()
    33.     {
    34.         transform.hideFlags = HideFlags.None;
    35.     }
    36.  
    37.     private void RemoveFolder()
    38.     {
    39.         // Unparent children first.
    40.         var children = GetComponentsInChildren<Transform>();
    41.         for (int i = 0; i < children.Length; i++)
    42.         {
    43.             children[i].parent = null;
    44.         }
    45.  
    46.         Destroy(gameObject);
    47.     }
    48. }
    49.  
     
    Last edited: Jul 25, 2019
    Danixos and Peter77 like this.
  16. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    7,050
  17. IsaiahKelly

    IsaiahKelly

    Joined:
    Nov 11, 2012
    Posts:
    347
    Do you experience the same hitches after building it?

    I tested a simple camera rotation animation myself and all hitches disappeared once I built it.
     
  18. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    891
    The Game and Scene view Rendering is happening in the same process that is rendering and processing the Editor around it. The Profiler tries to give as accurate as possible a view into this in a "how would this look in a player" kind of way, which essentially hides the EditorLoop/Editor overhead in the "Other" Category which is (due to an oversight in how the system was designed/"fixed", see the bug ticket for details) currently not shown in the Chart unless a sample was selected that contributed to that category, or in any child sample.

    Besides that, here's another writeup on timesteps. And yes, I agree, this should be tackled better in Documentation.
     
  19. willgoldstone

    willgoldstone

    Unity Technologies

    Joined:
    Oct 2, 2006
    Posts:
    776
    Regarding this one, i've had multiple looks into it the past couple of years. We added vsync on the game view as a result of one of these and I still don't think its resolved. We are also developing UMPE (Unity multi-process editor) to tackle this and other things - basically the game view will be its own process in that instance which we believe will help.
     
  20. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,004
    I haven't actually tested it myself, but my understanding from reading other threads is that this is not a game-view only issue, nor is it tied to dropping frames or anything else.

    Rather, it's that the value of Time.deltaTime fluctuates even if the game is running with VSync on, and never dropping any frames. In other words, if the screen refresh rate is 60hz, and the game is getting capped to that by vsync, the value of Time.deltaTime is not exactly 1/60, but rather values that fluctuates around that.

    This means that you might get different amounts of movement from an object from frame-to-frame, even if if the movement is implemented in the "correct" way. This variance will even out to constant movement, but the movement won't be smooth if you look at subsequent frames in isolation. People claim to be able to see this as stutter.

    This has been theorized to be due to deltaTime being calculated not as the exact time between two renders, but rather as the time between some other part of the engine cycle, which is affected by how long the engine is waiting for vsync.


    Now to be clear, I haven't tested this myself, and I haven't personally noticed this stutter. I just felt like summing up what I've caught from other people, because those threads are pretty long and filled with a ton of speculation and digressions.,
     
    a436t4ataf, JoNax97 and Xarbrough like this.
  21. Crystalline

    Crystalline

    Joined:
    Sep 11, 2013
    Posts:
    144
    Great post! I agree with everything, especially the part with the hierarchy folders.
     
  22. TextusGames

    TextusGames

    Joined:
    Dec 8, 2016
    Posts:
    381
    You can alt + left click on fold triangle in hierarchy or project windows and it will collapse all object undearneah that hierarchy.
     
  23. MechaWolf99

    MechaWolf99

    Joined:
    Aug 22, 2017
    Posts:
    63
    I agree with so much of this. I especially feel the bit about creating new scripts and having to rename them or move them. Some sort of small wizard like what they have for the new UIElements when creating new ones would be great!
     
    SisusCo likes this.
  24. SisusCo

    SisusCo

    Joined:
    Jan 29, 2019
    Posts:
    450
    Back in the day Unity released an asset that helped solve many of the issues related to creating new scripts called Create Script Dialog. Unfortunately they seem to have dropped support for it and it's no longer available from the asset store.

    I have however revived it as part of my inspector overhaul project Power Inspector.
     
  25. Quatum1000

    Quatum1000

    Joined:
    Oct 5, 2014
    Posts:
    821
    Time.deltaTime has also a low precision float problem. On frame rates for eg 100, 120 or 140 , 240 then Time.deltaTime completely loos its ability to be correct enough and animations starts to run away as well. Perhaps the complete unity vsync process should be processed in double instead of the weak float size at first.
     
  26. a436t4ataf

    a436t4ataf

    Joined:
    May 19, 2013
    Posts:
    1,030
    I've been wrestling with @Xarbrough 's same problem with stutter in empty projects too. I've tried everything I could think of (and I like the quote "I'm not at all talking about beginner mistakes" :) - I've had numerous conversations where people offer great advice for beginners, but I've been a professional game developer since the PS2 days, and written render engines in C, C++, before even picking up Unity. It's unlikely that I'm making a beginner mistake). The worst part is: I couldn't yet find a consistent reproduction, and I've had some projects where it didn't happen (which was enough to make me weep).

    The idea that it depends on the physical monitor comes the nearest to what I've seen, and sounds like a perfect explanation given all the things I've ruled out - the projects where I didn't see it ... was I working on a different monitor? (for some of them, definitely; for all? Maybe). Small variations in both the monitor timing, and how the device drivers are interfering with that, once you take into account the full stack down through the OS and then back up inside the monitor, would make sense.

    A couple of years ago I looked into how much commercial flat panels change the incoming signal before displaying it. The electronics is so cheap that panels are stuffed full of pretty radical post-processing, that often messes up your nicely-colored, nicely calibrated, fine detail graphics, in order to (and I quote from one of the manufacturers here) "always pop!". I've seen it make big differences with e.g. particle systems looking great or terrible, since the monitor ruins the fine-grained detail. /facepalm.

    ...but I'm spitballing. It's a problem that has had me tearing my hair out time and time again, unable to find a reliable, 100% deterministic, reproduction.

    I'm pretty sure I've seen this during my investigation, but I remember going through a phase of thinking that was it, and then being unable to capture any reliable direct evidence. Looking back ... if that's because I'd just bought a new monitor, and it was the change of monitor that made the problem disappear ... I will kick myself :).

    (And it's very obviously stutter - but I've got a high sensitivity to framerates (blame it on too much time doing FPS optimization as a graphics programmer, always looking out for it?). I'm happy to accept that some people literally can't see the stutter (I've worked with colleagues who couldn't see stutter that was so bad I had to walk away from their dev machine, watching it / watching them work was giving me a headache)).
     
  27. TextusGames

    TextusGames

    Joined:
    Dec 8, 2016
    Posts:
    381
    I do remember than five years ago I did tested this problem and can confirm that on my note book there was almost no stutter artifact but in my monitor it was very significant and awful.
     
  28. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    203
    With the recent introduction of editor coroutines, I would like to hope that threads and so on will now be part of the editor. Oddly for me, one of the biggest wishes I had with unity was that they would provide a basic code editor, much like say visual basic code, as part of the unity IDE, so that it didnt have to rely on external tools but also, for those of us who have a habbit of closing windows instead of minimizing them, the waste of time of it reloading vs/vscode/raider does add up very quickly!
     
  29. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    891
    @bugfinders Coroutines run on the main thread, EditorCoroutines therefore did not change anything about moving load off of the main thread. That said, more and more code is moving into the managed or native job systems and is therefore multi-threaded.
     
    bugfinders likes this.
  30. DGordon

    DGordon

    Joined:
    Dec 8, 2013
    Posts:
    465
    We have extensive editor tooling that outputs c# files. How I wish Unity let me create a code editor textbox!
     
    bugfinders likes this.
  31. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,004
    There's a half-decent one on the asset store that I used a while back - it was a bit more competent than MonoDevelop used to be. So it's for sure already possible.
     
  32. DGordon

    DGordon

    Joined:
    Dec 8, 2013
    Posts:
    465
    Assuming you mean ScriptInspector3. I wish UT would pick that up and devote some real resources to it. If a single person can create something that useable, I can only imagine how polished it could be if properly integrated.

    Maybe with more than 1 man on it I could finally get my feature request of having that work in custom editors, which would be such a huge production increase for us :).
     
    bugfinders and Lars-Steenhoff like this.
unityunity