SpeedTree shader broken ?

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.

1 Like

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

I can confirm that Alloy fixed this issue with their latest shaders for 5.4 The tree’s look great again.

2 Likes

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.

Wow, this is pretty cool - Thanks for the info.

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.

2 Likes

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.

AH! Thank god I am not the only one experiencing the billboards not scaled, have you updated to b18?

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.

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

While this issue is not unique to 5.4 and has persisted during the past few 5.x releases, if you’re dependent on SpeedTree, please vote for a fix on the Issue Tracker:

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.

13 Likes

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.

2 Likes

Thanks, do you plan to fix it in 5.3 too? Because I need that.

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.

1 Like

Thanks, please support any 5.3.xPy version because the only other option is to upgrade to a beta branch of the engine.

Hello guys, I’ve posted it on speedtree forum few months ago:

We didn’t have such problem in Unity 5.2.

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!

11 Likes

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

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.

1 Like