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
  2. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  3. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

SpeedTree shader broken ?

Discussion in '5.4 Beta' started by AdamGoodrich, Apr 22, 2016.

  1. AdamGoodrich

    AdamGoodrich

    Joined:
    Feb 12, 2013
    Posts:
    3,780
    Hi,

    Possibly not the right place as this is a broader unity issue, so apologies in advance if that's the case.

    Either the SpeedTree shader is broken, or something has changed and I am now doing something wrong. The issue is the way that sun shines through leaves. I never noticed this issue until later 5.3.x releases but also didn't use earlier 5.3.x releases.

    The following images were generated with Gaia 1.5.3, using exact same assets and lighting setup on the same machine across 5.1.0f3, 5.3.4p2, 5.4.0b15. They were all generated on Windows 10, DX11, Linear Deferred, Realtime GI.

    First Unity 5.1.0f3 - All good - and probably 5.2 as well, but no longer have that version installed.

    Grab 20160422104858 w1900h1200 x5y74z3r129.jpg

    Next 5.3.4p2. broken - and imho unusable in a game.

    Grab 20160422105300 w1900h1200 x30y62z-77r140.jpg

    Unity 5.4.0b15 - Still broken - this time with no image FX - which tend to mask the issue.

    Grab 20160422114636 w1900h1200 x66y69z-89r146.jpg

    This leaves Unity without a viable tree system IMHO. Fyi @Dannyoakes

    Cheers,
    Adam.
     
    Last edited: Apr 22, 2016
  2. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    Sorry, could you please elaborate on what exactly is broken about this, for the pixel-sensitivity-impaired amongst us?
     
  3. AdamGoodrich

    AdamGoodrich

    Joined:
    Feb 12, 2013
    Posts:
    3,780
    The way the light shines through the leaves, and also on the edges of the leaves is messed up. Sorry for the lack of correct language, i am somewhat pixel impaired as well.

    2016-04-22_22-14-00.jpg
    Good.

    2016-04-22_22-14-24.jpg

    Not so good.

    2016-04-22_22-22-29.jpg

    Looking great...

    2016-04-22_22-22-17.jpg

    But walk under the tree and look towards the light...
     
    Last edited: Apr 22, 2016
  4. Fatalis

    Fatalis

    Joined:
    Sep 9, 2013
    Posts:
    52
    I always wondered why my Speedtree assets looked so "meh". I have this exact same issue with the shading on leaves looking really off and rough.
     
  5. AdamGoodrich

    AdamGoodrich

    Joined:
    Feb 12, 2013
    Posts:
    3,780
    Some more testing - this will only ever happen with linear + deferred.
     
    Whippets likes this.
  6. Dannyoakes

    Dannyoakes

    Joined:
    Feb 10, 2015
    Posts:
    118
    Yeah, we've been talking to the Unity team about this issue. I think it's related to the lighting changes in 5.3, but they're working on tracking down the issue.
     
  7. camel82106

    camel82106

    Joined:
    Jul 2, 2013
    Posts:
    304
    Yes same thing and I'm using linear + deferred too
     
  8. looki666

    looki666

    Joined:
    Sep 5, 2013
    Posts:
    79
    The same :( Deferred -Linear .
     
  9. o1o101

    o1o101

    Joined:
    Jan 19, 2014
    Posts:
    639
    I am noticing a similar problem, Does anybody know when were going to get some good Speed Tree fixes?
     
  10. elbows

    elbows

    Joined:
    Nov 28, 2009
    Posts:
    2,502
    I don't know but I will celebrate the day when this happens because for a headline Unity 5 feature I really don't think it's received enough love from Unity.
     
  11. looki666

    looki666

    Joined:
    Sep 5, 2013
    Posts:
    79
    + one for the fix , SpeedTree is realy awsome , but needs better shaders in Unity . Displacement , transmission , more detail maps etc :)
     
  12. elbows

    elbows

    Joined:
    Nov 28, 2009
    Posts:
    2,502
    On that note I'd suggest that I don't expect everything to be perfect because I assume that certain limitations are down to the textures SpeedTree provide - Unity can make their shader work better but they can't, for example, add full PBR if the required info to make PBR work isn't supplied via textures in SpeedTree for Unity products.
     
  13. o1o101

    o1o101

    Joined:
    Jan 19, 2014
    Posts:
    639
    I will celebrate too haha! I also think they really need to make optimized versions of the Speed Tree shaders, since mobile is such a big part of Unity, it seems strange to have such a broken yet built in feature to Unity, it can barely perform well enough on desktop let alone mobile... But, the best would be if they could just fix what they already have, because its currently unusable in 5.4, I would love an ETA, for the fixes from somebody from the Unity staff.
     
  14. sqallpl

    sqallpl

    Joined:
    Oct 22, 2013
    Posts:
    384
    I think that it would be great if the SpeedTree shader would be somehow based on Unity standard PBR shader but still with SpeedTree wind and SpeedTree maps support so it would work with the maps that are exported from SpeedTree modeler (base color, normal, specular) out of the box.

    I think that these things are basic stuff that is still missing from the SpeedTree shader. Without them it will be hard to match shading quality of Unity Standard Shader. It's not related only to 5.4 beta but generally to SpeedTree shader in Unity.

    1. SpeedTree shader is not affected by reflection probes.

    2. There is no input for specular map that SpeedTree generates. Only 'Base' (color and transparency) and Normal maps are used. (I'm not sure that SpeedTree specular maps are matching Standard Shader setup so SpeedTree shader would probably need appropriate changes for it).

    3. There is a 'shiness' slider in the shader inspector for leaves and fronds but looks like it's not working at all.

    4. Same for 'specular color'.

    There are more advanced and additional features like subsurface scattering that would be great in the future but I think that we need basic features like the ones mentioned above and bugfixes (like the one that was reported by @AdamGoodrich here).
     
    Last edited: Apr 29, 2016
  15. Deleted User

    Deleted User

    Guest

    @sqallpl
    5. Vertex AO is not being gamma-corrected, and is being applied to all lighting rather than just the ambient lighting.

    We ran into all these problems when making the Alloy SpeedTree shader. It's kinda embarrassing how broken and unusable the official Unity SpeedTree shader is. The worst part is that it would take a negligible amount of time and effort to fix it.
     
  16. AdamGoodrich

    AdamGoodrich

    Joined:
    Feb 12, 2013
    Posts:
    3,780
    Adding GPU instancing to my wish list :)
     
  17. Pequisto

    Pequisto

    Joined:
    Apr 21, 2015
    Posts:
    66
    Before I plop down any of my money on SpeedTrees, I really am going to need to see some attention given to the issues mentioned above.
     
  18. Deleted User

    Deleted User

    Guest

    So I've figured out the problem. It's that SpeedTree leaves are rendered with face culling off, so it just has the same lighting on both sides of the leaf. The way to fix this is to use the VFACE semantic to invert the normals on backfaces. Sadly, Unity's surface shader framework doesn't support that feature.
     
    Pequisto and elbows like this.
  19. larsbertram1

    larsbertram1

    Joined:
    Oct 7, 2008
    Posts:
    6,898
    it does :)
     
  20. Deleted User

    Deleted User

    Guest

    @larsbertram1
    Oh? Do you have a working example within a surface shader? I've only been able to get it to work with raw vertex and fragment shaders.
     
  21. larsbertram1

    larsbertram1

    Joined:
    Oct 7, 2008
    Posts:
    6,898
    all you have to do is to declare FacingSign in your input struct
    struct Input {
    float2 uv_MainTex;
    half3 viewDir;
    float3 worldNormal;
    INTERNAL_DATA
    float FacingSign : FACE; // Needed to correctly lit single sided geometry
    };

    then you can access it in the surface function using IN.FacingSign to adjust and flip normals, viewdirs – whatever.
     
    elbows likes this.
  22. Deleted User

    Deleted User

    Guest

    @larsbertram1
    Hmm. I thought I tried that and it complained, but maybe I forgot. Also, it should be "VFACE" to be platform-portable.
     
  23. HolyFireGames

    HolyFireGames

    Joined:
    Apr 23, 2014
    Posts:
    134
    I can confirm that Alloy fixed this issue with their latest shaders for 5.4 The tree's look great again.
     
    TeagansDad and elbows like this.
  24. XaneFeather

    XaneFeather

    Joined:
    Sep 4, 2013
    Posts:
    97
    We have noticed the same issue. The effect is only happening in deferred rendering mode. This is fairly unacceptable as we're forced to modify the SpeedTree shaders in order to fix the issue but I'm unsure what might cause this. No change to the fragment shader affects the lighting issue so I'm wondering what everyone else's fix is, if anyone managed to fix the issue in deferred.
     
  25. Jaimi

    Jaimi

    Joined:
    Jan 10, 2009
    Posts:
    6,203
    Wow, this is pretty cool - Thanks for the info.
     
  26. PeterB

    PeterB

    Joined:
    Nov 3, 2010
    Posts:
    366
    It's amazing how one hand at Unity doesn't seem to know what the other one is doing. The fact that SpeedTrees are broken or halfheartedly implemented in 5.x is a well-known fact. Articles have been written about it, forum threads have mentioned it, fixes have been promised – and yet there are people working at Unity who are surprised when the issues are pointed out for the umpteenth time.

    When are SpeedTrees going to get fixed? We've been waiting a long time now. Even the people at SpeedTree seem to have given up on Unity fixing these issues, if you read between the lines on their forum.
     
    uiniti and VertexSoup like this.
  27. HolyFireGames

    HolyFireGames

    Joined:
    Apr 23, 2014
    Posts:
    134
    Although Alloy fixed the lighting issue mentioned in this thread, we still have massive LOD issues. Smooth transitions cause the trees to explode and billboards have wrong scale. It makes using them in a production environment extremely challenging. An official response on these issues would be great.
     
  28. o1o101

    o1o101

    Joined:
    Jan 19, 2014
    Posts:
    639
    AH! Thank god I am not the only one experiencing the billboards not scaled, have you updated to b18?
     
  29. HolyFireGames

    HolyFireGames

    Joined:
    Apr 23, 2014
    Posts:
    134
    We haven't checked it on B18 yet, but nothing in the patch notes about it. I'll try to check today or tomorrow to see if it's fixed.
     
  30. sjm-tech

    sjm-tech

    Joined:
    Sep 23, 2010
    Posts:
    733
    Hi,
    has anyone found a fix or a way to minimize the issue?
    Same issue is present in Advanced foliage shader : grass shader v4 (larsbertram1 can you check please?)
    Max

    Shader Issue.jpg
     
  31. XaneFeather

    XaneFeather

    Joined:
    Sep 4, 2013
    Posts:
    97
    Last edited: May 31, 2016
  32. dreyhal

    dreyhal

    Unity Technologies

    Joined:
    Jan 5, 2016
    Posts:
    15
    Hi,
    Just wanted to let you know, that we are making effort to fix this quality issue right now. It is composed of a few parts. Running the trees through a PBR pipeline (that's what really happens when deferred path is enabled) is one of them, since those trees are not PBR compliant. Another one is backface normals correction. We will let you know about the progress.
     
    TeagansDad, Arganth, uiniti and 10 others like this.
  33. elbows

    elbows

    Joined:
    Nov 28, 2009
    Posts:
    2,502
    Thanks so much for communicating about this issue with us. The Unity forum has been sorely missing a Unity voice on Speedtree topics, so touching base with users via the forum once in a while is much appreciated and I hope it continues.
     
    Jaimi and XaneFeather like this.
  34. uiniti

    uiniti

    Joined:
    Feb 4, 2015
    Posts:
    74
    Thanks, do you plan to fix it in 5.3 too? Because I need that.
     
  35. dreyhal

    dreyhal

    Unity Technologies

    Joined:
    Jan 5, 2016
    Posts:
    15
    Hi uiniti, it's hard to say to which versions we will backport the fix because I don't yet know the full extent of the changes that we will end up having. We have the result much improved right now but we don't know how much more we will change until it looks fully correct.
     
    uiniti likes this.
  36. uiniti

    uiniti

    Joined:
    Feb 4, 2015
    Posts:
    74
    Thanks, please support any 5.3.xPy version because the only other option is to upgrade to a beta branch of the engine.
     
  37. Killersan

    Killersan

    Joined:
    May 27, 2014
    Posts:
    76
  38. dreyhal

    dreyhal

    Unity Technologies

    Joined:
    Jan 5, 2016
    Posts:
    15
    Hi, a few words about the lighting quality situation. There are two changes that I think are critical to give to you as soon as possible. Let me describe the motivations behind them.

    1. In our lighting pass, there is normal correction happening, that, more or less, flips them if NdotV is negative. This is intended for views such as an inside of a sphere, to not have light bleeding inside in a glitchy way. This though turns out to be SpeedTree quality offender, because SpeedTree relies on normals looking away from the viewer a lot. And that correction forces them to, kind of, align to the geometry. This is the main reason why your leaf specular highlights look so washed out.
    2. When you use deferred rendering with SpeedTree, as I already mentioned, the trees are going through the PBR pipeline. To make that work without having PBR data for the trees, specular color and smoothness are being set to 0. This is a forced way to kinda make trees work Lambert-like after going through a PBR pipe. But that limits the image quality you can get obviously.

    Now let's talk about possible solutions for point 2, because pt. 1 we should be able to figure out internally.

    Ad 2) In your SpeedTree folders, where you have your trees imported, you can often see a specular map - and if you check the SpeedTree materials that the importer generates, you won't see those specular maps used. There is not even a property for them. They are being imported just because SpeedTree Modeller is using them, but so far we didn't care about them, so they were just sitting there. Why didn't we use them? Because we try to render trees with Lambert lighting, without specular at all. That's obviously limiting the quality that we can reach, but let's leave that aside for now. It's actually great that these specular maps are there, because now we have the door open for improvement. So what we can do, is we can extend the SpeedTree material to start using that texture, and use it not as a specular map, but as a Smoothness map. Bad news is, it will be up to you, to re-author your "Specular maps" to be Smoothness maps instead. For some trees though, the Specular map works as a smoothness map quite well - just needs scaling down by a factor such as 0.3. So depending on a specific tree you are using, you may or may not have to author the Smoothness map yourself. If you absolutely can't author the Smoothness map and the Specular map is totally not Smoothness-friendly, we can provide an alternative path for setting Smoothness as a constant value. It won't look as good but it is a workaround that will make trees look better already when compared to the current "zero it out" approach.
    So this is what I have to say about Smoothness but we need to also have specular color set to something correct. It is a simpler case though, because after we introduce the change, we will just make it default to something like 51,51,51 and as far as the Metalness/Specular work charts go - this is a solution that's good enough.

    There is one more issue which is connected purely to the linear color mode, but I will probably update on that later on.

    Hope this helps, feedback welcome!
     
    TeagansDad, sqallpl, o1o101 and 8 others like this.
  39. o1o101

    o1o101

    Joined:
    Jan 19, 2014
    Posts:
    639
    Thank you very much for the in depth explanation! You seem like the expert, so I am wondering if you have any answers about my questions posted here - http://forum.unity3d.com/threads/another-speed-tree-transition-bug.409718/
    Thanks again
     
  40. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,350
    About "should be able to figure out internally"... will this be figured out for 5.4's release or is it being pushed back again? I feel like this is an important fix, and if it's as simple as just including the normal facing sign in the shader as people posted earlier, I hope it makes it into 5.4.
     
    uiniti likes this.
  41. o1o101

    o1o101

    Joined:
    Jan 19, 2014
    Posts:
    639
    @Dannyoakes
    I'm starting to get very very frustrated with SpeedTree, performance is S***, billboards do not batch properly, meshes do not batch properly, on iPhones transitions are horrible depending on the device, on most androids I have tested, tons of billboard and transition bugs, and so much more. I have reported numerous bug reports, that do not seem to get through, not to mention I don't feel it is our job to help fix such obvious bugs on something so integrated with Unity, it is ridiculous. I feel so robbed when I pay 45$ for a tree with a "mobile" version, that doesn't even work the latest iPhone 6s... Are you kidding me? Nothing has even seemed to improve with Speed Tree on this beta vs the stable version, its only caused more bugs, batching isn't even better... Both SpeedTree and Unity are big company's, is it that hard to hire a couple people to fix the dam trees so they are actually usable? In the end I'm probably going to end up with another 3rd party asset off the store thats going to do it 100x better than you guys. Seriously. Does Unity even know about the bugs or turn a blind eye to them? It feels like SpeedTree hasn't improved since it was first introduced. Since when is the stable version of Unity the testing grounds for the SpeedTree nightmare, just remove it from the stable version at least if you wont fix it. Also, where can a get a refund for these horrible trees. I will buy some when they are actually fixed. Maybe this will be something that Unity Plus will fix. hah.
    Unity is not some little indie game engine anymore, its a multi million dollar company and it still seems to depend on the Asset store for shaders, better image effects, terrain tools, editor ad ons, and everything else. Also, don't give us the technical bullshit to shut us up, just fix the ridiculously over priced bug filled trees. I'm going to post this other places on the forum.. I am sure lots of people feel the same way I do.

    Rant over...
     
    uiniti, Nateply and looki666 like this.
  42. dreyhal

    dreyhal

    Unity Technologies

    Joined:
    Jan 5, 2016
    Posts:
    15
    Yes, the change will be available in 5.4.
     
  43. uiniti

    uiniti

    Joined:
    Feb 4, 2015
    Posts:
    74
    What about 5.3.x?

    It's needed there, 5.4 is still unstable, games can't be shipped with it.
     
    Dannyoakes likes this.
  44. sjm-tech

    sjm-tech

    Joined:
    Sep 23, 2010
    Posts:
    733
    A fix for 5.3.X is very important if you want to still publish Web Player contents...not available on 5.4.
     
    uiniti likes this.
  45. dreyhal

    dreyhal

    Unity Technologies

    Joined:
    Jan 5, 2016
    Posts:
    15
    Hey
    First allow me to quote myself.

    So considering how timely you guys need this, I propose I tell you how to change one shader file, so that at least you have that part improved. I am aware it is not so cool that you have to do it yourself. But at least this is a way in which we can give the change to you pretty much instantly.

    So, for both 5.3.x and 5.4.x:
    1. Go to your Unity installation folder, and then to Editor/Data/CGIncludes, and find a file named UnityStandardBRDF.cginc

    2. Locate this section of code:
    Code (CSharp):
    1. #if UNITY_BRDF_GGX
    2. // NdotV should not be negative for visible pixels, but it can happen due to perspective projection and normal mapping
    3. // In this case we will modify the normal so it become valid and not cause weird artifact (other game try to clamp or abs the NdotV to prevent this trouble).
    4. // The amount we shift the normal toward the view vector is define by the dot product.
    5. // This correction is only apply with smithJoint visibility function because artifact are more visible in this case due to highlight edge of rough surface
    6. half shiftAmount = dot(normal, viewDir);
    7. normal = shiftAmount < 0.0f ? normal + viewDir * (-shiftAmount + 1e-5f) : normal;
    8. // A re-normalization should be apply here but as the shift is small we don't do it to save ALU.
    9. //normal = normalize(normal);
    10. // As we have modify the normal we need to recalculate the dot product nl.
    11. // Note that  light.ndotl is a clamped cosine and only the ForwardSimple mode use a specific ndotL with BRDF3
    12. half nl = DotClamped(normal, light.dir);
    13. #else
    14. half nl = light.ndotl;
    15. #endif
    16.  
    17. half nh = BlinnTerm (normal, halfDir);
    18. half nv = DotClamped(normal, viewDir);
    19.  
    20. half lv = DotClamped (light.dir, viewDir);
    21. half lh = DotClamped (light.dir, halfDir);
    and replace this whole section with this:

    Code (CSharp):
    1. #if UNITY_BRDF_GGX
    2. half nv = abs(dot(normal, viewDir));
    3. #else
    4. half nv = DotClamped(normal, viewDir);
    5. #endif
    6.  
    7. half nl = light.ndotl;
    8. half nh = BlinnTerm (normal, halfDir);
    9.  
    10. half lv = DotClamped (light.dir, viewDir);
    11. half lh = DotClamped (light.dir, halfDir);
    After you make the change, you have to go to your project folder, and delete Library/ShaderCache folder. This way, after you start Unity, the shaders will be recompiled, and you should see the change. It should make a significant difference, because even though the SpeedTrees still won't be properly setup for PBR, at least their normals won't be stomped. But in some views it can look similar, so please don't surrender after a first glance. As I said - the data not being PBR still limits the potential look.

    EDIT: I edited this description, originally it had two ways depending on the versions, but one solution applies to both 5.3.x and 5.4.x after all.

    EDIT2: Feel free to report if it helped you in a way you expected - it can be a valuable feedback for us.

    If something is unclear, just ask.
    Cheers.
     
    Last edited: Jun 15, 2016
    uiniti and makeshiftwings like this.
  46. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,350
    Thank you for the fix!
     
  47. camel82106

    camel82106

    Joined:
    Jul 2, 2013
    Posts:
    304
    At least I don't see an difference. It's as bad as before. I have double-checked change of shader. Deleted cachce, restarter Unity. Or it is another problem?

    Away from sun is ok:

    Against sun it's really bad


    I hope that everybody can see that trees in center are weird looking with too light parts or too dark. Everything is relative. But that change between branches is too big

    Unity 5.3.5p3
     
    Last edited: Jun 15, 2016
    uiniti likes this.
  48. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,350
    Yeah that change doesn't seem to have made any difference for me either (using Unity 5.3.5)

    With directional light towards camera:
    Capture.JPG

    Without directional light:
    Capture2.JPG
     
    looki666 and camel82106 like this.
  49. dreyhal

    dreyhal

    Unity Technologies

    Joined:
    Jan 5, 2016
    Posts:
    15
    Hey guys
    Thanks for the feedback. I am not overly surprised by what you wrote. I was expecting problems with what you see.
    Before I begin with a couple of questions, let my show you what kind of change you *should* see.
    Please check out the below comparison screenshots taken from 5.3.5f1 (no shadows - keep that in mind):
    comparison.jpg
    This is the kind of difference that you should see after just applying this change. It's pretty significant, wouldn't you say? Now take a look at the below comparison (with shadows):
    comparison2.jpg
    And here you will barely see any difference. So depending on how you look at it you may very easily miss it.
    Now take a look at what happens if I switch the shadows off for the latter comparison:
    comparison3.jpg
    What's very important to realize here, is that even if we add PBR data to this tree, the highlight will still be there (just more varied), because in SpeedTree assets, to achieve a sensation of liveness, normals are facing pretty much all directions regardless of what section of a tree you are looking at. Because of that, the tree to look properly, it absolutely requires shadows rendering. OR, well, no specular contribution at all :) That also solves the issue, and it is the case when you have forward rendering enabled. Unfortunately for all of us, when in deferred( which is PBR ), there isn't any way to just switch specular off completely, because ... it's PBR.

    1. So I would like to ask you guys. Can you make comparisons like the first one in this topic? Just to make sure that you don't have any difference? Because if you still don't have any, then we will just figure out why it is not applying for you.
    2. What DX version do you use?
    3. @camel82106 these dark spots that you see are very weird. It seems like a different problem to me. If you could provide me a link to some repro package, I would gladly take a look.
    4. Do you render with shadows?

    I will keep digging to help you as much as possible.
    Cheers
     
    uiniti likes this.
  50. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,350
    I thought the problem was that the camera-facing side of the leaves were not using the normal sign correctly, and so it was using the normal of the back side of the leaf. There were posts earlier about fixing this problem by including the normal sign in the shader. It looks like the lighting we see on the front side is what we are supposed to be seeing on the back side. Are you saying instead that all the leaves have random white noise as normals per pixel? Because that seems pointless... can't you just have the normals on the leaf be the regular normal of its polygon?