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

Workflow Case Study - Show us your pain!

Discussion in 'Editor & General Support' started by willgoldstone, Mar 1, 2019.

  1. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,791
    This is how I would imagine the texture importing and compression to be, inside this window.
    Right now its still the blocking popup but I have good hope it will all move to the background tasks window


    Screenshot 2020-01-08 at 16.01.24.png
     
  2. Ferazel

    Ferazel

    Joined:
    Apr 18, 2010
    Posts:
    447
    It always feels that Unity is always changing tech instead of fixing bugs and making improvements to existing systems. The employee/feature churn over the years has been horrible and detrimental to having a feeling of any consistency to the features that are being worked on or delivered to us the end-users.

    The other problem here is it seems a majority of core engine talent is working on DOTS and leaving the rest of the teams throwing GameObject features together while the engine is transitioning to a new backend. Everything seems to be being rewritten right now and the existing functionality is barely "production-ready" as the features claim. Which gives the feeling that the features that are being implemented now are not going to be improved or fixed up either since they will need to be rewritten again for ECS.

    I mean let's count every system that is going through either a DOTS transition or a GameObject transition right now in my years at Unity.

    IMGUI -> AssetStoreGUI (EZGUI/NGUI) -> UGUI -> UIElements
    ParticleSystem -> Shuriken -> VFX Graph
    Built-in -> SRP -> URP & HDRP
    Beast Lightmapping -> Enlighten (Abandoned) -> CPU Baked -> GPU Baked -> New Realtime GI
    NetworkView RakNet -> NetworkV2 (Abandoned) -> ECS NetCode
    C# OOP -> Modern C# OOP -> C# DOTS (Jobs, Burst, ECS)
    Legacy Input -> New Input System
    Asset Bundles -> Addressables
    NavMesh -> ComponentNavMesh (Abandoned) -> ECS Nav?
    Animation -> Mecanim -> ECS Animation
    AudioSource -> AudioMixer -> DSP Audio
    PhysX -> 2D Physics -> ECS Havok/Unity Physics

    However, the duration that is has been taking to get to the green hill that these features on the far right promise is multiple years. Then it seems that Unity starts up with another system to replace that system. In the meantime we're left holding the bag about what the hell Unity actually is anymore as we try to develop our product. Very few if ANY of the systems on the right are "feature-complete" nor free of issues and problems that are difficult to navigate around. You also have split your user-base into using some old features, some new features, and no one is able to figure out your problem because there are infinite configurations of feature sets.

    Some of these improvements were long overdue. I've wanted an InputSystem rewrite for awhile, but it was announced years ago and just now getting to a point that might be usable by some projects. Then hearing that it isn't ECS compatible, makes me throw my arms up not believing this system will be around long either. It's like watching someone fail over and over again, and them telling you "Yeah, that was a problem. Wait though, I have a better solution coming!" over and over again. It's tiring, and eventually you just want to fire that person.

    The input system is hardly alone there in how long we wait for features. Nested Prefabs was a biggie, and 1 year after it was released is it in a point where I feel most of the issues have been resolved (or will be resolved in 2020 with in scene editing). How long did it take to get UGUI in a spot that was without with severe performance problems or bugs (5.5)? Only to have them throw it out and start over with UIElements.

    I have this 5-year mentality in my head that this will be better in that time as more of the engine transitions to ECS foundations. However, it's a mess currently, and we developers live in the present. Where all of these deprecated systems are out there and the new systems are not really ready. I almost would rather have Unity DOTS as a separate product instead of trying to add to the complexity of Unity as it exists today and the mess we struggle with.

    I've been a Unity user 10 years now this year. I've seen project big and small use the engine, but I'm reaching my wits end lately. I'm pretty sure my current project will be my last Unity project. At least until these transitions complete to a full-engine with clear solutions to problems.
     
    Last edited: Jan 9, 2020
  3. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    691
    Ferazel, I concur with everything you said. It's so sad that there aren't many old users like yourself hanging around anymore. They might have left Unity already and I fully understand. I myself regret so badly coming back to Unity after abandoning it years ago.
    I love C# and I was so excited after seeing Unite Berlin thinking that Unity is headed toward the right direction.
    It's just that Unity CANNOT deliver. Unity is much bigger company now and I expect more but things are getting out of control.

    I feel that Unity doesn't take things very seriously. It feels like they are doing a hobby project. A community project Blender seems like doing a much better job than Unity.

    Unity needs to hire many more expert(full-time, no more part-time who are more likely to leave in the middle) developers who knows their stuff. And cut some marketing personals who are so disconnected from the core if the budget is the big concern. It feels like there are two companies, one selling candies and one making a timemachine.

    Fundamentally, the problem is that Unity doesn't eat their own dogfood and have no idea what it's like in production.
    If I were Unity, I would start a game production studio and start making AAA commercial games and backport all improvement, share many knowledge and tools to users. Be your own ginny pig instead of making all of us the pigs. If competing with your own client such a big concern, I would make the project an opensource.

    Secondly, their business model doesn't benefit much from our success but from mostly from having as many noob users lurking around Asset stores trying to fill the empty Editor. Well, it will be best if Unity provides essential tools as part of the Engine like Unreal but we all have to spend lots of time searching for the right tool on the Asset Store. I understand that it will be hard to change BM but what you can do to help users is to do better quality control of Assets. Honestly, more than 50% of the assets are garages and less than 1% of Assets are useful but they all have different issues and we are at the developer's mercy for the support. You should provide a much stricter QA process so that users don't have to deal with the asset provider individually. For example, 2019.3 has really a wonderful feature called, Fast Enter-To-Play Mode. This will save countless hours and all assets should take advantage of it. If a single doesn't support, we cannot use the mode in the project. So, to call the Asset 2019.3 compatible, mandate that it must support the new mode. Right now, I have to contact all individual asset developers and ask for support.

    My two cents.
     
    oxysofts, xVergilx and Ferazel like this.
  4. KokkuHub

    KokkuHub

    Joined:
    Feb 15, 2018
    Posts:
    455
    Here's another nasty bit of pain I'm dealing with right now: placing platform-specific files in the StreamingAssets folder.

    After painstakingly refactoring a project to use asset bundles instead of the resources folder, I now have to write code to move several gigabytes worth of files in/out of the StreamingAssets folder before/after building because Unity always includes everything into the build.

    Can we please have per folder/file platform filtering settings like those for native/managed libraries and assembly definitions?

    (I can't help it, I have to rant now)
    Pretty much every Unity game worth its salt targets multiple platforms. And this is not a recent thing either. This is yet another myopic shortcoming derived from the discrepancy between how the internal teams at Unity imagine game development is done day-to-day and how it's actually done by those on the front lines. It took several years for Unity to finally realize that, yes, developers *do* need to switch between build platforms at a regular basis and they can't afford to wait the several minutes/hours it takes to do so on actual game projects, so everyone eventually resorts to hacks like renaming the Library folder or having multiple synced copies of the project (which probably caused any metrics about platform switching in-editor to be underreported, if Unity ever tracked such thing, that is).

    I hope it won't take Unity as many years to realize how devs constantly need to work around their flawed build process and asset management on actual games with more than a couple dozen assets that need to be tested, shipped and updated on multiple platforms. If they had a team making such games next door, close enough they could hear the expletives through the walls and whom they could bump into at the kitchen, giving them such feedback up close instead of faceless forum posters, maybe, it wouldn't take that long.
     
    Last edited: Jan 12, 2020
    Lars-Steenhoff likes this.
  5. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,791


    There are some good things worked on as can be seen in this video, and Unity is aware of the platform switching pain, I hope this year will bring many of the new workflow improvements to the editor.

    5A7FFB48-C5CA-4A14-AEA1-2CE06CA09E0A.png 20F98129-64B3-49C8-8A91-7CDEEBE40514.png
     
  6. KokkuHub

    KokkuHub

    Joined:
    Feb 15, 2018
    Posts:
    455
    I am aware of that and mentioned it in the rant (maybe I was too rant-y?). It's great we will finally have it (whenever 2019.3 reaches LTS, that is), but the time it took for what should be a simple fix for an issue that drains significant iteration time of so many developers does not inspire confidence.
     
    Lars-Steenhoff likes this.
  7. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,791
    Yea its taken a long time for sure, It was already slowing me down years ago. I just hope that this year things will finally work smooth.
     
    Last edited: Jan 13, 2020
  8. KokkuHub

    KokkuHub

    Joined:
    Feb 15, 2018
    Posts:
    455
    Oh, here's another one: asset names use only a single line in project window's thumbnail view:

    upload_2020-1-14_18-27-7.png

    This makes thumbnail view pretty much useless for all non-art assets, unless you use DOS-style names for all your scripts.
     
  9. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,064
    For me, it makes it useless for art assets as well, since I have longer names to make searching easier, ie "pre_arch_nakiban_wall-000"
     
  10. transat

    transat

    Joined:
    May 5, 2018
    Posts:
    772
    One workflow pain is not having any way to know which of my assets need updating, because this info is...

    - Not showing up online anymore (someone decided to remove the « items with updates » option without making sure users had some other way of finding this out).
    - Not showing up in the now defunct embedded store in 2020.1.
    - Not showing up in the Package Manager, which is not showing me the latest versions from the store anyway And is unable to sort anything effectively when I have 2000 assets.

    Recently got an official response after 4-5 attempts at asking about it on these forums. These appear to be regression bugs that somehow managed to slip past quality control. :-/
     
  11. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,173
    This.
    This drives me NUTS!!


    PAIN POINT:
    When I switch between assets of different types in different folders -- i.e. prefabs/textures/models to a list of scripts or assets (i.e. stupidly huge thumbnails for script files or other data-based asset types like render pipelines!!)
    I hate the search / spotlight feature -- I'm a Windows guy. I like tweaking things visually.
    I feel like the search/spotlight feature is a genuine UX/UI copout! -- Not creative enough to design a proper UI/UX? -- Hire me, or make the user search for the function/asset instead.

    PLEASE fix this!!


    POSSIBLE SOLUTION:
    1. Here's a flexible way to make the asset selection window usable for a guy like me:

    • "Line-break" at the camelCase, dashes, spaces, or underscores like the Inspector does for the names of our C# scripts

    • Add a vertical space slider for thumbnail separations (i.e. larger/smaller vertical grid cell spacing)

    • That same slider widget can increases the number of lines to display when broken camelCase, dashes, spaces, or underscores separate the lines.
      The slider would go between 1-6 lines (in case we need more lines per asset name, like @joshcamas-styled asset names).

    • Always display ending number group (and, if separated by a different char than standard asset name, display name group too):

      e.g. AssetNameThatGoesOnAndOn_DataAssetType-RenderPipeline-001

      becomes:

      AssetNameThat
      GoesOnAnd
      ...
      DataAssetType
      RenderPipeli...
      001


    BETTER USER EXPERIENCE:
    2. Two options for quick asset view customization:

    • Why not a group of radio button options (one icon for each property you want to modify) beside a single slider (for the line-number/thumbnail-size/cell-spacing functions mentioned above) to let you quickly pick the particular slider (and thus the particular property of the asset view layout) you're trying to modify at the moment? -- You'd click a button, then the slider would change between icon-thumbnail-size, grid-vertical-spacing, or line-number sliders in a single click.


      AND

    • You could either have Unity automatically pick customization profile for a folder containing a single asset type. For example, if a folder contains ONLY .CS files, you can customize it deep in the user preferences once to display folders that have only .CS files in a standard details list (consisting of just text and super-tiny thumbnails).
      If a folder contains a mix of assets that are .PNG, .FBX, .PREFAB, then display them as a grid with x number of lines with x amount of vertical spacing (with x thumbnail size). This customization would sit deep in the Unity Editor preferences. (Bad idea IMO)

      OR

      Situate a button / menu option in the slider area to "Save current folder as view profile". Upon clicking this option, Unity will analyze the current selected folder's file asset extensions, and if that folder consists of only PNG and FBX files, then the view profile (that is, slider settings) would be saved and automatically applied to folders containing only FBX and PNG assets. If a folder ONLY contained PNG assets or ONLY FBX assets, it would need a separate profile saved. Default view profiles would exist, but could be replaced generally OR for a particular folder location when clicking that (or another) option because, sometimes, a user would prefer a specific folder to be displayed in a specific way (such as a folder with 3 scripts in it, I might want to display thumbnails instead). Having a context-based "use this customization" option that takes a single menu-click is much better than shoving customization off deep in the user preferences. This is a very much "hands-off" approach for the user. This is good UX, and is what I, as a user, would prefer.
     
    Last edited: Jan 17, 2020
    KokkuHub likes this.
  12. tonygiang

    tonygiang

    Joined:
    Jun 13, 2017
    Posts:
    20
    My projects follow an event-driven structure. We rely a lot on UnityEvent to assemble the logic of a scene together. I'm going to list a use case that we use a lot: Invoking an event from another event. This is textbook DRY (Don't Repeat Yourself) principle. But Unity Editor does not support invoking UnityEvent directly. This has led us to create one companion function for each UnityEvent we want to invoke. There is no way to automate this. The UnityEvent-invoking functions eventually take up way too many lines in a complex class.

    Please give us the ability to invoke UnityEvent directly from another event in Editor. By this, I also mean the events of built-in Unity components like onClick of Button and onValueChanged of Dropdown.
     
    Last edited: Jan 18, 2020
  13. zadda

    zadda

    Joined:
    Sep 18, 2016
    Posts:
    7
    Something that I think would be a nice addition although it is quite a minor thing, would be if it would be possible to use the "back" and "forward" buttons from my mouse. I'm not sure how common those are on a mouse these days but it could be handy when going through folders in the asset folder or something.
     
  14. KokkuHub

    KokkuHub

    Joined:
    Feb 15, 2018
    Posts:
    455
    I recently had to deal with shader variant management for the first time due to making a game where 100% of the assets are loaded via asset bundles and... I just... what the? Everything about this is terrible. I either get hot magenta everywhere in my builds or get massive shader bundles with all shader variants plus the kitchen sink included. The window to edit shader variant collections is hilariously bad. Truncated lists? No search?

    -- EDIT --
    And in the end nothing I tried could convince Unity to not strip away the keywords I needed from my bundles, so I had no alternative other than adding the shaders to "always included" and accept the bloating of my shader bundles.
     
    Last edited: Jan 24, 2020
    awesomedata likes this.
  15. Ne0mega

    Ne0mega

    Joined:
    Feb 18, 2018
    Posts:
    341
    Editor Sliders from the Range attribute could really use a slow-down key, like alt + drag or shift + drag, that slows down the rate of difference when moving the slider, for fine tuning. Maybe even just RMDrag or MMDrag, since both of those are unused when moving the slider.
     
    Last edited: Jan 24, 2020
  16. SisusCo

    SisusCo

    Joined:
    Jan 29, 2019
    Posts:
    460
    It's a small nuisance, but I also don't like the fact that you have to start dragging a slider before you can obtain any information about its range. Being able to know what value a specific point on the slider maps to by merely mouseovering it would help solve this.

    range-drawer-tooltip.png
     
  17. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,173
    Don't worry. Unity has us covered on this. Its range is from the right to the left. It doesn't go any farther than this. This means we should never have to worry about the slider sliding off the track there. Even if it does, it should be safe -- that little handle is virtual. It shouldn't hurt anything if it hits the void beyond your computer screen. Nothing breakable is down there. See? That's the kind of foresight Unity offers us. They've totally got our back on stuff like this!

    Oh wait... you meant the _value_ of the slider... popping-up on mouseover... My bad... Yeah. That would be useful too. :)
     
    willgoldstone and SisusCo like this.
  18. transat

    transat

    Joined:
    May 5, 2018
    Posts:
    772
    Anyone here tried the “tree height” range slider in the terrain component? Which user ever needs to know what values they’re selecting?? :rolleyes:
    Mind you, who would ever want to place trees with that tool!

    On that note, does anyone know of a tool that works on URP and that will allow me to mass place trees above a certain terrain height so that I don’t need to go through and delete trees underwater?
     
    Last edited: Jan 24, 2020
  19. willgoldstone

    willgoldstone

    Unity Technologies

    Joined:
    Oct 2, 2006
    Posts:
    778
    Added to the backlog.
     
    Ne0mega and Lars-Steenhoff like this.
  20. Ne0mega

    Ne0mega

    Joined:
    Feb 18, 2018
    Posts:
    341
    I am highly annoyed* by both HDRP and URP having a default scene with a bunch of junk I have to root out and throw away.

    Any initial project should be bare bones, with most everything turned off, so the designer can turn things on themselves, after they have researched how to do so and what it does, instead of throwing in a scene that might be useful to some, but certainly is useless to many, and costs EVERYBODY *at least* an extra 5 minutes of throwing things out they never really asked for, and then leaving it to the designer to figure out what to turn off to get a simple start point they can then build upon.

    *
    This annoyance is built on an underlying feeling of annoyance at Unity for clearly assuming most games will be of a certain type and design structure. I'll not get into that here, but there is definitely an underlying tone of the entire engine. I probably wouldn't "highly" annoyed at this alone, but it gives me confirmation bias.
     
    Last edited: Jan 30, 2020
    Vectrex likes this.
  21. Ne0mega

    Ne0mega

    Joined:
    Feb 18, 2018
    Posts:
    341
    It would be nice if "maximize on play" of the game view Window was it's first, and furthest left button.
    Unless I am missing something, there is no way to show scene view only when pressing play.
    So I often grab my Game window, and kind of just squeeze it off to the side, so I can see what happens when the game starts in scene view.
    Or often I want to pause, or quickly hop into fullscreen mode.
    When the maximize on play button is upper left, it is the last to get squeezed out by Unity Editor GUI conventions, therefore, always accessible when trying to swap between fullscreen game and editor view when in game mode.

    If there is already a hotkey for that, cool.
     
    Vectrex likes this.
  22. Deozaan

    Deozaan

    Joined:
    Oct 27, 2010
    Posts:
    685
    I believe Shift-Space will toggle maximize the currently selected window. And if you don't like that hotkey, you can change it in the settings.
     
    jonathans42 likes this.
  23. Miguel_LZ

    Miguel_LZ

    Joined:
    Jan 12, 2018
    Posts:
    35
    Some minor but healthy addition would be something that Unity did say they were looking into implementing (years ago), but apparently never came to fruition: a 'Select All Scenes' checkbox in build settings.

    Sometimes, when you have a big project you want to make a quick build with independent scenes to test features, bugs, whatever. When that project has, say, over 50 scenes, if you want to make a build containing only one or two scenes, you are forced to manually deselect almost 50 checkboxes in the Build settings menu, one by one.

    This is insanely slow and unintuitive [...] it's about time for Unity to include such a basic feature nowadays as a 'Select All' checkbox that would check/uncheck every scenes in the Build menu at once [...] and it would actually be very easy to fit in the current Editor design.

    Sometimes little additions like this one help the users feel that a software is more intuitive and straight-forward.



    A Unity team member recommended using Ctrl+A or alternatively holding Shift to bulk select, but as the OP points out there, those commands have been faulty and not always work correctly, which is a little exasperating.

    I am always hoping that, in a new Unity version, this really tiny quality-of-life feature suddenly pops up. That was, after all, a 2016 post.
     
    Last edited: Jan 30, 2020
  24. Ne0mega

    Ne0mega

    Joined:
    Feb 18, 2018
    Posts:
    341
    Nope, not in game mode.
     
  25. OliverAnthony

    OliverAnthony

    Joined:
    Nov 21, 2012
    Posts:
    12
    Has the issue of recompile been raised, here?

    Whenever I need to do housekeeping or refactoring, having recompile (or asset reimport) triggered every time I move or rename a code asset (or other asset) is an absolute nightmare.

    The way Unity manages meta files clearly pushes users to do these kinds of things from inside the editor rather than a file explorer or code editor, so having an accessible and reliable means of suspending recompile/reimport seems like an essential that is sorely missing and exactly the kind of low-hanging fruit I'd expect a workflow task-force to prioritize, especially seeing as it is such a minimal feature to develop and purely additive (doesn't necessitate breaking or modifying any existing UX).

    Cheers!
     
    Vectrex and Lars-Steenhoff like this.
  26. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,791
    Thats why I proposed to have a library kind of window, where you can do the house keeping without affecting how it is stored on the disk, and therefore also not triggering any imports / compiles.
     
  27. OliverAnthony

    OliverAnthony

    Joined:
    Nov 21, 2012
    Posts:
    12
    While a library window seems like a highly useful feature, especially for teams, there are cases where housekeeping and refactoring tasks go beyond moving files from one folder to another, including but not limited to renaming scripts, creating assembly definition files, and modifying assembly definition references and build targets.
     
    Lars-Steenhoff likes this.
  28. Deozaan

    Deozaan

    Joined:
    Oct 27, 2010
    Posts:
    685
    I suppose that makes sense, since it needs to ignore most Unity hotkeys to be able to properly test potential game input using the same combination of keyboard presses.

    But then Ctrl-P starts and stops playmode, so it makes me wonder if the maximize window hotkey can be changed to something that will work in game mode.
     
  29. Deozaan

    Deozaan

    Joined:
    Oct 27, 2010
    Posts:
    685
    A major pain point for me is trying to get rid of all the cruft that comes in each project by default. Every time I start a new project I open the package manager to remove all the things I don't need in my project, which is most of it, but I have to disable them one at a time, with a 20 second recompile time each time I disable or enable any package.

    If I was smart, I'd just open the manifest file in a text editor and remove it all at once from there, but I don't recall claiming to be smart on these forums. :p


    Oh, and somehow, even though I've "removed" Unity Collaborate in the package manager, somehow one of my project settings files keeps getting an option changed in it to enable Collaborate every time I make a build. I keep reverting that change in my version control, but the Editor keeps turning it back on again even though it's supposedly not even in the project anymore after I removed/disabled the feature entirely using the package manager.:mad:
     
  30. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,791
    Yes if the packages could install without blocking the editor, or if you could make a selection first of many packages and then press install / uninstall / upgrade it would save quite a bit of time
     
    awesomedata likes this.
  31. Deozaan

    Deozaan

    Joined:
    Oct 27, 2010
    Posts:
    685
    All I want is to have check boxes next to each item and an apply button. Anything that is checked will be installed when the apply button is pressed and anything that isn't checked will be removed.

    Upgrading is a different story IMO and introduces additional complexities.
     
    awesomedata and Lars-Steenhoff like this.
  32. Miguel_LZ

    Miguel_LZ

    Joined:
    Jan 12, 2018
    Posts:
    35
    Also, speaking of the Package Manager, the new UI design icons in 2019.3 are not very easy to read. I just opened it after installing the new version to check for new versions of the packages I already have installed and at first glance all of them seemed up-to-date with the checked box next to them, and I closed it.

    Then, I saw in the forums that one particular package had a new version, so I went back to Unity to get a screenshot and report a bug, only to find out that the package did have an update pending but the new icons are super tiny and seem super similar, so in a small screen as mine (I'm not really that close to it either) they all seemed the same.

    I guess they could use some tweaking to better tell them apart.
     
    Last edited: Jan 31, 2020
  33. willgoldstone

    willgoldstone

    Unity Technologies

    Joined:
    Oct 2, 2006
    Posts:
    778
    HI Ne0mega I couldn't agree more - its why we've been working on Scene Templates - which will allow you to have firstly some decent options when you get into an SRP project but more generally the ability to make your own templates you bring in upon starting a project and iterate from there when prototyping. More in this thread -
    https://forum.unity.com/threads/scene-templates-preview-now-available-for-feedback.778265/
     
    Ne0mega likes this.
  34. willgoldstone

    willgoldstone

    Unity Technologies

    Joined:
    Oct 2, 2006
    Posts:
    778
    Our intended solves for this are basically in the New Asset Database v2 which is on by default in 2019.3 onwards, we'll be adding to that the ability to background / on demand import too to make things like this a lot smoother. Ideally you shouldn't be getting as many random reimports as you do (obviously!) so we're hoping from that release onward you'll be a lot less bothered by this kind of thing.
     
    Lars-Steenhoff likes this.
  35. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    2,353
    When will actual scene async loading come to the editor?

    Loading multi-scene setup in the build takes less than a second, where as in editor its slowly synchronously loading it one by one.

    Zzzzzzz

    I've been waiting for this feature like since I've started using multi-scene setup years ago.

    Moreover, it causes inconsistencies between build and editor environment behavior, where at some point people start asking on the forum why does their X doesn't work like X in the build.


    We've got DOTS, Jobs, but the editor can't load more than one scene at a time.
    eFBfFU7J_400x400.jpg
     
  36. willgoldstone

    willgoldstone

    Unity Technologies

    Joined:
    Oct 2, 2006
    Posts:
    778
    Regarding not show or switch to game view on play - we're adding that as one of our Quality of Life fixes yep. Regarding the maximise during playmode - if you pause the maximise shortcut works, then unpause to continue play. https://gyazo.com/8a3ccc914bb0540fa96fe263e6a27ce1
     
    Ne0mega likes this.
  37. willgoldstone

    willgoldstone

    Unity Technologies

    Joined:
    Oct 2, 2006
    Posts:
    778
    Hey Miguel - I just shared this with our package manager designer thanks for the feedback.
     
    Miguel_LZ likes this.
  38. willgoldstone

    willgoldstone

    Unity Technologies

    Joined:
    Oct 2, 2006
    Posts:
    778
    that's the plan :)
     
    Lars-Steenhoff likes this.
  39. willgoldstone

    willgoldstone

    Unity Technologies

    Joined:
    Oct 2, 2006
    Posts:
    778
    Hey not sure what original post you're referring back to (apologies if i'm being dumb and missed it) but shift select seems to work okay? what issues are you experiencing? I tried with about 35 scenes loaded - Cmd-A and Shift select - https://gyazo.com/fe6653228d63e9616cbd0d3a32cec4a7
     
  40. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,173
    THE MULTI-INSPECTOR WORKFLOW.

    My tears flow endlessly.


    So here's the rub: When I have a material setting I want to quickly reference in a prefab, or a reference I want to check in a particular prefab's inspector, or while I want to click on something else (and maintain my current inspector), these all threaten to change my inspector reference to the newly-selected gameobject/instance/whatevs. This drives me MAD.

    My proposed solution is a scene-based "multi-inspector" workflow. It goes as follows:

    • Every gameobject you're working with has an "inspector" it wants to build
    • Upon clicking a gameobject in the scene, you can hold a hotkey (i.e. CTRL or SHIFT or "M") to set the inspector as the "main" inspector, otherwise pop-open a 3d panel in the scene next to the object as an in-scene "sub" inspector.
    • By default, the "sub" inspectors appear relative to the object's location in the world and are tweaked by the panel's appearance in the viewport (for better display), and the mouse-wheel can be rolled over these panels to scroll them (rather than finding and dragging a tiny slider like is required in the "main" inspector).
    • There can be multiple "sub" inspectors, but only one "main" inspector.
    • Elements, properties, etc. can be dragged back-and-forth between the in-scene inspector(s) and the main inspector panel, allowing one to both quickly reference and copy values between the inspectors
    • In-scene inspectors can be set to display in screen space (so you don't lose them when you move around your world) and you can "X" them out shrink / minimize them when you're done with them (think 'minimized' Apple window panels, but expandable when you hover over them to show you the entire gameobject's name they reference)
    • In-scene inspectors also have a minimum overall screenspace scale or width (so that they are still interactive in a practical way (or at least they increase in size or scale back up when you mouseover them, which would be the preferred behavior for me)
    • When you turn the 3d scene away from the gameobject, unless you locked the panel to display in screenspace, the panel fades away, but when you look back at that particular gameobject, its inspector reappears again.
      This allows you to have multiple "sub-" inspectors open simultaneously (i.e. 3 or more) and not block your UI since simply changing your viewport looking direction causes the panels to shrink/disappear depending upon how central they are to your scene viewport's focus.
    • Most importantly, the ability to quickly reference particular inspectors for a gameobject in the scene is vital.
      Being able to (quickly) pick a gameobject in the scene while simultaneously setting this inspector as the "main" inspector should be a choice (i.e. NOT automatic) for each new gameobject you select. To do this, I suggest making a big button on the (sub-)inspector UI as well as adding a hotkey (i.e. holding "m") to put the selected object as the main inspector, otherwise the inspector opens automatically as an in-scene "sub" inspector. This allows the user to make the display of a particular inspector intentional -- (which is what is lacking very much at the moment!)

    If you've ever looked at Dreams for the PS4, they handle their UI immersively (in-scene rather than in-window) -- and it works well for a complex UI like Unity requires. This lets natural 3d movement through the scene move things out of the way and shrink or disappear automatically based on when you're focused on them or not. For example, when you turn back their direction to view the object in question, the UI panels (i.e. their inspectors) reappear.

    This is automatic UI handling at its finest.
     
    Last edited: Feb 5, 2020
    Lars-Steenhoff and chrisk like this.
  41. willgoldstone

    willgoldstone

    Unity Technologies

    Joined:
    Oct 2, 2006
    Posts:
    778
    We have been discussing this A LOT LATELY (wow, caps is fun you were right) and we have a few simple things coming to make your life easier, and a longer term more embedded plan later on. In the short term - the one I'm more definite and can share with you we simply have what we call Property inspector - in order words, inspectors you'll just fire up and close quickly without messing with the main inspector. Now before anyone gets mad we KNOW this is not the overall and long term solution - we are working on ideas for that too - with everything from scene Overlays, to panel grouping with dedicated inspectors per group - there's a lot on the table so far.

    Here's a quick demo video of property inspectors -

     
    Vectrex, Ferazel, Timboc and 2 others like this.
  42. willgoldstone

    willgoldstone

    Unity Technologies

    Joined:
    Oct 2, 2006
    Posts:
    778
  43. Miguel_LZ

    Miguel_LZ

    Joined:
    Jan 12, 2018
    Posts:
    35
    Ah, sorry about that! I was referring to this specific comment from the guy that wrote the original thread: https://forum.unity.com/threads/edi...eckbox-in-build-settings.427493/#post-2765958
     
  44. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,090
    That looks really great. We made essentially that tool, but for assets, and it's helped a lot with being able to edit several assets at once and not losing context constantly.

    The only thing that seems annoying with what you're showing is the right click->properties workflow. I guarantee you that opening the property window for an asset is the thing I'm going to do the most, so it makes sense to either put it on double-click, or at least to have properties on the top of the right-click list.

    When working with scene objects, one of the major annoyances is that the act of clicking an object in order to drag it into an inspector also selects the object, so we constantly have to lock/unlock the inspector in order to assign things. If we had property inspectors, as well as the ability to open them by double-clicking things, I'd simply not have the inspector open quite often, since the property inspectors solve that problem.
     
    Last edited: Feb 6, 2020
    Lars-Steenhoff, frarf and awesomedata like this.
  45. KokkuHub

    KokkuHub

    Joined:
    Feb 15, 2018
    Posts:
    455
    The inspector context problem can be fixed with a lot less hassle if you implement a selection history that can be navigated back and forth, treating the inspector context like a browser handles URLs. Maybe add support for tabs inside the inspector window to more easily manage multiple inspectors, by quickly opening objects into new tabs with the object/asset name in the tab title.

    There should also be an option to change the double click action to "open in new inspector" instead of editing the asset. Very rarely do I actually open assets for external editing from within Unity.

    Right now selection is treated like any other undo-able action. If you're only selecting things to view their properties, you can go back to the previous selection, but if you do any property changes you're SOL and need to hunt down the previous object, which is a huge pain.
     
    Ne0mega likes this.
  46. Rowlan

    Rowlan

    Joined:
    Aug 4, 2016
    Posts:
    1,532
    One thing I really miss is a navigation history. It's really handy in browsers to navigate back using a dedicated mouse button. It would be very beneficial for the work with Unity as well.
     
  47. Rowlan

    Rowlan

    Joined:
    Aug 4, 2016
    Posts:
    1,532
    The "Show in Explorer" shortcut should open the exact folder in the explorer, not the parent of the item that got selected in the project view.
     
  48. Miguel_LZ

    Miguel_LZ

    Joined:
    Jan 12, 2018
    Posts:
    35
    This. So much this.
     
    Rowlan and awesomedata like this.
  49. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,173
    INORITE? Caps are so underrated! I don't understand why _everyone_ doesn't just use them ALL THE TIME!!

    In all seriousness -- I am really glad to see you guys working on this. You give me hope. :)


    I have to agree with @Baste on the double-click thing. The Property Inspector should appear when the gameobject is double-clicked. This has always been the expected behavior for me. The current double-click function of zipping to the gameobject (to visualize it in the scene view) should change to holding a shortcut when double-clicking instead. This is basically reversing the current functionality, but to me, this was the expected behavior from the outset when I first started using Unity. I was surprised (and very disappointed) when it zoomed the object instead.

    Like @Baste, I nearly wrote a tool to do this exact thing multiple times because Game Maker's method (literally back in 1998) was always much more efficient to me when going between multiple objects and modifying their data. The reason I never made my own tool was because Unity's UI was always considered to be in flux and I knew I'd have to just rewrite my tools again later, so I just tried to bear the load since I've got a lot of other tools I've got to write to compensate for similar UX issues / limits. Beyond that, as you've already hinted at with your post, the property inspector method has its flaws too -- Namely, the UI quickly gets cluttered.


    Clutter, clutter, EVERYWHERE

    To fix the impending cluttering issue, why not allow the user to hold a key (1, 2, 3) when double-clicking the Hierarchy object to replace the default (or a specific) inspector? Depending on which "sub" inspector is opened first, second, or third, it would be tied to 1, 2, or 3. By default, the double-click opens to the first (main) inspector (no shortcut necessary), but if you want a "sub" inspector, you hold 1, 2, or 3 to open up (and replace the contents of) up to three (or more) windows. These can have other things docked in them, so if you want to dock an inspector, it no longer counts as your 1, 2, or 3 (or more) "sub" inspector windows.

    Although this keeps the number of unintentional windows down, Workspaces (i.e. like what Blender has for Modeling, UV, TexturePaint, Sculpting, etc.) would be the most general way to help solve the issue of general tool AND shortcut clutter (which is a HUGE issue in Unity). Scene-based organizer tools are also a very good option. See tools like Peek for Unity, for example.


    Scene-based, designer-centric, workflows!

    I really suggest you guys start looking HARD (Huh-huh.) into scene-based designer-centric Editor-tooling for your tool and workspace concepts. Tools like Unreal or Maya, for example, are very utilitarian for design purposes. Tools like Unreal and Maya rely on sheer brute-force feature-heavy tools (instead of innovation on a tools' main concepts) to keep up with technology. As feature-heavy as "brute-force" applications of a tool are, for "in-the-trenches" design purposes, these kind of tools simply cannot compete with creatively-designed, modular, designer-centric, tools which help a user iterate at great speeds. To even have a chance to compete, these tools require a major rewrite (or three) of their main engine from the ground up each time a new ground-breaking innovation is made in another tool.

    And guess what? -- That's exactly what you guys are doing right now.

    Regarding designer-centric tools, I will bring up a point that @Baste has already made for me: Multi-property inspector tool like this can work for Assets as easily as it can works for GameObjects. There are lots of things in Unity where interactions can (and should) be designed from the outset to overlap (floating-origin system and transforms/meshes). A more general look at these kind of interactions (i.e. the kind of interactions users might eventually (want) to make with your engine) is mandatory for Unity to stay in good favor with users. When you can consolidate interactions into an intuitive path to learning, it is a really good sign that your approach is both designed well and modular enough to iterate on.


    A new way to play?

    I still want to emphasize that 3d UI (for example, inspector property panels in the scene view shown/hidden near gameobjects in a creatively-unobtrusive way) is less responsibility-heavy to the user (assuming the 3d UI panels depend on his viewpoint in the scene, like I suggested). This way, Unity can keep the UI clutter (and required effort!) down for the hard-working designer trying to knock down the endless list of mundane-but-required tasks he is responsible. Rather than force the designer to keep his own clutter down, which is much preferable for the lazy *erhm* busy designer, why not focus on more creative (and useful) automation for these more mundane tasks that usually revolve around optimization of and in workflows? Automation is generally great, but it's even better when it's done creatively and outside-the-box. For example, as my experience with 3d tools has informed me, there is a whole other landscape that simple 3d controls, panels, and widgets can lend themselves to (if used creatively, in conjunction with standard UI elements) -- especially when we start getting into tools with 3-6 dof (degrees of freedom) for input. But the main advantage of a 3d widget and/or panel (besides their flexibility to interact with the scene/world directly) is that they keep clutter down simply by virtue of the fact that they are context-specific. For example, this is true for a viewport where 3d UI inspector panels will only appear when you're looking at them. This means you could have hundreds -- but they're only shown if they're close enough, or if the user focuses the mouse on them. The zzzip to the gameobject on double-click could suddenly be a useful two-fold action for the multi-property inspector. That is, it zooms you to the relevant gameobject in a scene, and instantly opens the 3d UI panel, while also having the "main" inspector panel in your standard 2d UI to toss values back and forth via drag and drop, and to help the user reference between them. In a way, you could consider this method as treating the design for your UI as if you were designing it for a game. In other words, you want to keep the user immersed in the UX, just like you would want to do when developing an experience for a game.


    What the heck do I know? -- I know a LOT about frictionless UX design

    I tend to break Unity's UI quite often. When I want a good frictionless UX, Unity's UI fails me at every turn. So I write my tools within the limits of the UI's capabilities. I, however, can only do so much. My UI design (and the experience of actually implementing it) is just a game of chicken -- i.e. Who quits first? Unity's UI, or my creative spirit?

    Unlike Unity's overall UX, I have a vision. I designed Snapcam to appear instantly (without friction) when you need it, and for it to (by design) stay the heck out of your way when you don't need it. I actually made two approaches for this purpose (for two kinds of users) -- First, the main, persistent, window with a slider the user keeps docked in his interface, and a second, separate, graphical, window the user calls forth instantly at a single keypress and a click (to go anywhere in the world, making the window vanish with that click.) This makes the tool feel effortless to use in practice and overall provides a great (frictionless) experience as you zzzip around your world. That kind of frictionless design needs to be a key tenet for any official tool/utility in Unity, so that the toolset can be more accessible and powerful without also being clunky. This kind of attention to detail would quickly make Unity (as a whole) feel more polished and professional simply because it is more considerate to the general user experience. You will certainly need a more general approach than simply assigning a hotkey to everything, but this kind of workflow can definitely be achieved with the help of someone like me involved in any of your more serious experiments.

    I'm up for consultation! -- Just let me know when and where you want my input! ^____^
     
    Last edited: Feb 11, 2020
  50. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    691
    Without a deep meditation, I can tell Unity UI is designed by programmers, a worse kind of UI designer and it has been that way for years. Seriously, Unity needs a good UX designer with some authority to kick some ass. Look how Blender has come along, even as a community project. It is miles better than Unity in UI department.

    Basically, Unity works with "Simple to Use" concept, an excuse to say "We don't know what to do with UI." Please mind that "Simple to Use" is fundamentally different than "Easy to Use" If you don't know the difference, please let me know. "Easy to Use" may not be simple to implement but it should work as User expected.

    In the "Simple to Use" concept, there are too many mouse clicks, go back and forth, and Inspector loose context so you have to lock and unlock. Yeah, sure it's Simple to Use but not Easy to Use. For example, it's missing "History" with mouse-forward/backward, a fundamental feature in all Editors of any kind, and it drives me crazy. So please don't say the Editor is Simple To Use, therefore it's a good thing because it easy to learn ever again. I don't mind a "Complicated to Use" as long as it works as expected, intuitive, and it can get the job done faster.

    Besides the fundamental UX workflow problems, the biggest problem is, Editor is so freaking clunky. It slows down as project size grows. For example, I often have to click on Checkbox three times.
    1. Click, nothing happens,
    2. The Editor sometimes eats click events, so I Click again. Unity responses but it registers two clicks, therefore, it reverts the first click,
    3 Click one last time.

    What the !!@#$! Unity Editor needs to move to .NetCore as fast it can as if there is nothing more urgent because it is. Forget about DOTS! Moving to .NetCore will enable us faster Editor and reduce the compile time to almost zero without the unnecessary whole assembly reload every time. Right now, it's a constant fight against the Editor rather than working on the project. Why should we all care about DOTS if we hate so much to work with the Editor on a daily bases?

    More resources should be put on Editor than on DOTS in my humble opinion.
    If you improve the Editor, everyone will benefit right away, rather than a couple of years later when DOTS are ready and by just a few people who will adopt DOTS. ~90% of the games will be fine without the DOTS, or better off without DOTS.

    Someone from Unity, please respond. Thanks.
     
    Last edited: Feb 11, 2020
    Vectrex, oxysofts and Yozaro like this.
unityunity