Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice

2019.1.0a11: Editor weird look while building a project

Discussion in '2019.1 Beta' started by Deleted User, Dec 8, 2018.

  1. Deleted User

    Deleted User

    Guest

    This is what the editor looks like for me when I build a project. This blue colour sometimes flashes when I do stuff in editor but it lasts only a fraction of a second; here it lasts until the project is entirely built.

    Building the project worked perfectly.

    On the left is the game view, on the right is the scene view.

    Capture.JPG ​
     
    Deleted User, Dec 8, 2018
    #1

  2. Juho_Oravainen

    Juho_Oravainen

    Unity Technologies

    Joined:
    Jun 5, 2014
    Posts:
    42
    Hey!

    This is caused by the recently added async shader compilation feature which still has some rough edges. Any such cyan flashes you might see are the rendering using a dummy shader while compiling/fetching the actual shader.
    What I think happens here is some shader reloading occurring at the beginning but then taking the build to finish before the system refreshes with the actual shader.
    We're working on polishing the feature, eliminating unnecessary dummy shader usage and providing more control on the feature. Fortunately what you see is just a cosmetic issue as the async shader compilation is an editor only feature. And we're on it :)
     
    Juho_Oravainen, Dec 10, 2018
    #2
    Deleted User, MihaPro_CarX and Lars-Steenhoff like this.

  3. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,527
    I had something similar with the distance texture in my terrain, and I was already wondering what it was.
    Thanks for the explanation

     
    Lars-Steenhoff, Dec 10, 2018
    #3

  4. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,982
    Async shader compilation!?

    Im dead happy to hear that you have listened to our woes about the shader compilation lock up! :)
     
    MadeFromPolygons, Dec 11, 2018
    #4
    Lars-Steenhoff likes this.

  5. Deleted User

    Deleted User

    Guest

    Thank you for your explanation. :)

    Sorry for answering so late; I never got notification of your post. I've had that problem for weeks now; I must browse all the topics I've made to make sure I haven't missed answers. :(
     
    Deleted User, Dec 14, 2018
    #5

  6. Deleted User

    Deleted User

    Guest

    Also in models previews in the inspector:

    Capture.JPG ​
     
    Deleted User, Dec 15, 2018
    #6

  7. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    1,533
    hmm I don't have a screen shot on me right now, but there is also an issue with editor icons not being shown with instead icon sized cyan colored box, seems to happen more with odin inspector (latest build for 2019.1)
     
    Player7, Jan 21, 2019
    #7

  8. Corngood

    Corngood

    Joined:
    Nov 15, 2012
    Posts:
    20
    I believe the use of dummy shaders breaks generated textures in our project. I don't see how it can be done safely unless it's opt-in and initially limited to only when drawing to the scene view (and possibly game view?) backbuffer.

    Interestingly, after turning it off in preferences, I still get a blue frame in the scene view on start, but the problems in game are fixed.
     
    Corngood, Jan 23, 2019
    #8

  9. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    3,136
    Did you check whether your alert preferences changed? https://forum.unity.com/account/alert-preferences
    Are you getting no alerts at all?

    Could you please submit a bug report with a minimal reproduction project for this issue and reply in here with the issue ID?
     
    LeonhardP, Jan 24, 2019
    #9

  10. Juho_Oravainen

    Juho_Oravainen

    Unity Technologies

    Joined:
    Jun 5, 2014
    Posts:
    42
    Hey again!

    2019.1.0a15 will bring in some improvements and fixes on this. First of all, async shader compilation will only happen in game/scene view. This should fix all issues with preview/thumbnail generation etc. However, it is not limited to backbuffer rendering, which means that user solutions persistently caching rendering results might need some action to become compatible with async compilation. There will be a few different approaches to handle such cases:

    1) The quick'n'dirty route: Disable async shader compilation in Editor preferences. After all it is only an Editor UX feature and one can work just fine without it (accepting the "good old" occasional Editor stalls caused by shader compilation).

    2) Force specific shader to always compile synchronously with new `#pragma editor_sync_compilation`.

    3) Force specific rendering scope to force synchronous compilation (new API):
    - ShaderUtil.allowAsyncCompilation // For immediate scoping
    - ShaderUtil.SetAsyncCompilation(CommandBuffer cmd, bool allowed) // For CommandBuffer based scoping
    - ShaderUtil.RestoreAsyncCompilation(CommandBuffer cmd)

    4) Detect & control compilation (new API):
    - ShaderUtil.IsPassCompiled(Material mat, int pass)
    - ShaderUtil.CompilePass(Material mat, int pass, bool forceSync = false)
    - ShaderUtil.anythingCompiling

    Proper docs for the new API are under construction but one should be able to try it out with this. Of course some API tweaks might still happen. One notable thing is that with the new API you can also enable async compilation outside the default scene/game view scope, allowing custom editor tools to utilize the feature. We'll be internally using this for e.g. shadergraph.

    The fix for the terrain base map issue mentioned earlier in this thread missed this batch but will land later in the next batch of fixes.
     
    Juho_Oravainen, Jan 24, 2019
    #10
    z3nth10n likes this.

  11. Corngood

    Corngood

    Joined:
    Nov 15, 2012
    Posts:
    20
    .

    I've put in a support ticket, and I'll update when I get a bug number.

    The repro is really simple. In fact the first thing I tried based on the description of async shader compilation reproduces it on a14:

    - new unlit shader -> new material ->

    Code (CSharp):
    1. using UnityEngine;
    2.  
    3. public class DrawTexture : MonoBehaviour {
    4.     public Material material;
    5.     RenderTexture rt;
    6.     void Start() {
    7.         rt = new RenderTexture(256, 256, 0);
    8.         Graphics.Blit(null, rt, material);
    9.     }
    10.     void OnGUI() {
    11.         GUI.DrawTexture(new Rect(0, 0, 256, 256), rt);
    12.     }
    13. }
    14.  
    - first time I play after starting the editor with async compilation and auto-refresh enabled, it's cyan

    I generally don't mind making repro projects, but this is trivial. How do you not have test cases that cover this?

    The first thing that comes to mind when you describe the feature is 'what about persistent output?'. My test case is an example of that, as is the preview/thumbnail screenshot above. In our game this causes the player character to be black/cyan when you enter play mode for the first time. IMO this feature should be opt-in until this is dealt with.
     
    Corngood, Jan 24, 2019
    #11
    LeonhardP likes this.

  12. Corngood

    Corngood

    Joined:
    Nov 15, 2012
    Posts:
    20
    I didn't see your post before I made my previous reply.

    I like the idea of being able to control it the way you described, but it sounds like it's still opt-out, and that worries me. There are times when it's (probably) safe to use a dummy shader, like when rendering to the scene view backbuffer, and possibly the game view back buffer. I'd prefer if it was only used in those cases by default. I don't like the idea of a script like the sample one above having to go out of its way to specify that it actually wants the correct results, instead of some placeholder.

    If you absolutely need it to be opt-out, I would appreciate an option to disable it in ProjectSettings/. I don't want to have to deal with problems caused by default editor preferences.
     
    Corngood, Jan 24, 2019
    #12

  13. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,619
    Do you think using cyan is a good choice? The reason for having picked cyan is probably because it's very "in your face" that something is going on there.

    But if it's expected that things are compiled while working in the editor all the time, maybe picking a color that better integrates with the scene causes less distractions and is more comfortable to look at for the user.

    As I understand the feature, it's actually not really communicating an important message. It's basically "wait a second and it's done", not that important and also nothing the user can affect.

    Having broken materials/shaders being displayed in pink makes sense, because there is an action required by the user to fix such broken asset.

    But I'm questioning that "async compiling shader" needs so much attention. Maybe a color that better blends in the with rest of the scene would be a better choice in this case?
     
    Peter77, Jan 24, 2019
    #13

  14. Juho_Oravainen

    Juho_Oravainen

    Unity Technologies

    Joined:
    Jun 5, 2014
    Posts:
    42
    Yes, it is still more of an opt-out solution. In practice this is a balancing act between getting rid of editor stalls and the amount of user action required. We're trying to find the sweet spot where majority of users will have stall free experience without touching their projects. And for the rest with more advanced use cases we're trying to make it as easy as possible to handle.
    To put this into perspective one should remember that: 1) This is not affecting player build at all. 2) Any unhandled cases will be transient by nature as dummy shader is used only when encountering the particular shader variant the first time. E.g. entering playmode again will fix the issue.

    The simple example case you posted above goes into the category of very common usage and we agree that Blit is something where users would always expect correct result (fix coming in the next batch). We're still working towards finding the sweet spot here and any feedback is definitely welcome. And if opt-out turns out causing more trouble than benefit in the end, going opt-in fortunately is as easy as flick of a switch. Actually, the editor prefs checkbox in practice works as a switch between "sweet spot opt-out" and "full opt-in" atm (in our dev branch that is, not landed yet).

    Thanks for the feedback! This is something we're definitely going to evaluate. It might indeed make more sense to specify the shader compilation behavior in project settings as different projects might have different needs.

    The main reason for choosing cyan was to make it absolutely clear what is going on there. The color is easy to recognize both visually and by checking the color values. I agree that having a more subtle color would be less distracting in the common use and we might indeed change it (maybe even make it configurable?). However, having a highly distinguishable color has already proven to be an invaluable help on spotting systems not handling async compilation properly. We'll see...
     
    Juho_Oravainen, Jan 25, 2019
    #14
    Peter77 likes this.