PS: if you're gonna try to comment out the cull off lines, you need to edit the shader that's being used by the leaves of the high quality lushLOD tree models. The exact shader depends on your manager settings, so I don't know which shader your scene is using. But you can select one of the HQ tree models, and see what shader it is using for the leaves. Edit that shader and comment out the "Cull Off" lines, should be two of those lines, and see if the flickering goes away. That's not a permanent fix though, so you shouldn't leave the shader that way, it's just a test to see if that's where the problem is.

Just a quick off the top of my head answers for now....

1) The way my converted trees move in the wind should be identical to the way the tree moved in the wind before it was converted into a LushLOD tree. So if the converted tree isn't moving correctly in the wind, then the same incorrect behavior should also be happening in the original Unity tree prior to conversion into LushLOD. I will say though, I believe I'm using a copy of the windzone code from like Unity 5.6 or earlier, and so hopefully windzones haven't changed since then. But check to see that the tree is moving correctly prior to conversion, because it should behave the same after conversion.

2) As for the shadows...flicker in the leaves... the shadows in the HQ leaves shouldn't flicker. It could be caused by duplicate verticies in your tree. You can try editing my HQ tree shader, and comment out both occurrences of the line "Cull Off" and see if that makes the flickering go away.

Just to clarify again.. it *can* run applyall() multiple times in a single frame, if it is passing the value of a single tree. This is supposed to allow you to drop a single tree into the game, and it would instantly apply the settings from the manager to that tree, without having to loop through all the trees in the whole scene. So if you were to drop 5 trees into the scene at once, then it *would* call applyall() 5 times, once for each of those trees. This causes the applyall() to apply the settings from the manager to just those trees only. But since you're spawning trees at runtime, and it seems to be messing up so much for you, the hack solution would probably be your easiest solution to fix the problem, just to take full control over when applyall() is run. So again, if you just run it only once, after you spawn a batch of trees, then you shouldn't let it run ever again, until you spawn more trees, or until you change some setting in the manager (if you do that, it's not common) during gameplay and you want to apply those new manager settings to the trees. But if you've already applied the settings from the manager to all your trees in your scene, and you can't think of any particular reason why the settings would need to be applied again, then probably odds are the applyall() function doesn't need to be run anymore and you should block it from being run in that case.

Just to clarify... ApplyAll() is only supposed to be run once when trees are spawned, to apply the settings found in the manager to the tree(s). And that's it... it isn't supposed to run ApplyAll() on every frame. Only reason you would call ApplyAll() again would be if you spawned more trees, or if you change the settings in the manager and you need to apply those new changes to the trees.

Maybe you could just do a hack solution, and tell the manager to return out of ApplyAll() always, except for when you want applyall() to be run. Then you would call it yourself after you finish spawning a batch of trees. Something like this:

ApplyAll(null, true, true, false);

It does appear that applyall() is being called multiple times per tree, on the same frame. This hack solution would guarantee to stop that from happening, at least. If you do this,, then you should probably un-comment out those ShaderSettingsChanged increment lines, since they probably do something important. :-)

Your next issue was the lag on the Update() function on the trees:

By "low setting", do you mean billboards only? Because billboard-only mode shouldn't use the update functions on the trees. The other modes do use the update() functions to do the transitions, but only for trees that are somewhat close to the camera. Most of the very far away trees fully turn off their update() function calls.

I think the demo scene has about 4000 trees, which isn't much different than the number of trees in your custom scene. You might check to see if your laptop can run the demo scene. If it runs my demo scene just fine, but can't run your custom scene, then maybe something isn't set up or working correctly in your custom scene.

What you could do if you have time, is add a debug line to that function, same place you added the line:

WriteToLogFile("Trees to go through: "+allTrees.Length);

And add these lines: 

WriteToLogFile("Value of ShaderSettingsChanged: " + ShaderSettingsChanged);
WriteToLogFile("Value of ShaderSettingsChanged_PREVIOUS: " + ShaderSettingsChanged_PREVIOUS);
WriteToLogFile("Was this a specifictree?: " + ReferenceEquals(SpecificTree, null) == false ? "true" : "false");
WriteToLogFile("Value of ByPassChangedChecks: " + ByPassChangedChecks == true ? "true" : "false");

UGH your code matches mine, in the spot I was worried about. So the fact that you're on an older version isn't the issue.

The code that should NOT be getting run, is the code near the spot where you added the line:

WriteToLogFile("Trees to go through: "+allTrees.Length);

But it looks to me like it is running that code when it shouldn't. Meaning it is looping through each tree, and each tree is triggering a loop through all of the trees again, potentially an endless loop.

I'm going to copy / paste your exact debug code here, but I'm adding in some comments so I can explain what I think is happening.

Okay so basically, here's my thinking:

Start
SetupHalfSrqTransition
CalculateLODDistances
UsingUltraShader
UsingUltraShader
Update 
    --> Start //first tree's start() function
        --> CreateTreeManager
        --> LoadSaneStartingSettings
        GetHighQualityShadowCastingMode
        GetBillboardShadowCastingMode
        ReCalculateParents
            --> Reset //This should be the call to reset, in the tree's Start() function.
                CalculateLODDistances
                UsingUltraShader
                --> SetupStaticMaterial
        ApplyAll(this); //<-- THIS should be the call to ApplyAll(this),
                // AT THE BOTTOM of the tree's start() function,
                // WHICH PASSES (this), aka it passes a reference to "this"
                // tree that is calling ApplyAll.
                // So the following code is being run by ApplyAll(THIS).
                // At the start of ApplyAll, we check to see if "this" is
                // not null, and if a reference to a tree WAS passed, then we
                // set ByPassChangedChecks == true. 
                // (See near the top of ApplyAll
                // where it sets ByPassChangedChecks to true.)
                // Right here, in your debug text, I'm expecting ByPassChangedChecks
                // to be TRUE, because we called ApplyAll and passed (this), which
                // means that ByPassChangedChecks should now be TRUE.
                // So, continuing on, here's the debug for ApplyAll(this):
            FindTreeUsingFastShader
                //#### LOD ####
                SetupHalfSrqTransition
                CalculateLODDistances
                UsingUltraShader
                UsingUltraShader
                    --> Reset
                        CalculateLODDistances
                        UsingUltraShader
                        --> SetupStaticMaterial
                //#### BILLBOARD QUALITY ####
                CalculateLODDistances
                    UsingUltraShader
                //And next it runs DoShaderUpdate, which I assume is being run
                //by the line of code just below the spot where you added this line:
                // WriteToLogFile("Trees to go through: "+allTrees.Length);
                //And here's that code:
                --> DoShaderUpdate
                //THE ABOVE LINE OF CODE should not have been run, because it only
                //runs if the value of "ShaderSettingsChanged" was changed, but it can't
                //change unless ByPassChangedChecks == false. But
                //ByPassChangedChecks should be TRUE, because we called ApplyAll(this), 
                // which should have set ByPassChangedChecks to TRUE.
                // so essentially, if ByPassChangedChecks == true, then
                // ShaderSettingsChanged should not have changed. And if
                // ShaderSettingsChanged didn't change, then we should not enter the
                // block of code near the spot where you added the line:
                // WriteToLogFile("Trees to go through: "+allTrees.Length);
                // However, by the looks of it, that's where we are right here
                // in this debug text.
                --> GetBillboardLeavesShader
                --> GetBillboardLeavesFarShader
    >>> The following bit repeats forever: <<<
UsingUltraShader
--> GetLeavesShader
UsingUltraShader
--> GetLeavesShader
UsingUltraShader
--> GetBarkShader
UsingUltraShader
--> GetBarkShader
--> DoShaderUpdate
--> SetupStaticMaterial
--> GetBillboardLeavesShader
--> GetBillboardLeavesFarShader

Actually, I don't know if this thing will let you attach files. If not, you might have to upload it to dive.google.com and then send me a link to download it.

Can you attach a copy of your manager.cs file and post it here for me. You're actually working with a somehow older version of LushLOD. The current version I'm working with is actually version 0.8, which hasn't been released yet. :)

Becuase I'm not able to see how this error is possible, at least with my version of the manager. It could be that I already fixed this error in version 0.8...

I'll be back in a few hours