Your comments
I think I probably found the problem... if you run a text search in the manager's code, look for every occurance of this line of code:
ShaderSettingsChanged += 1;
and replace it with this instead:
if (ByPassChangedChecks == false) ShaderSettingsChanged += 1;
And let me know if that improves anything.
For now, I'll assume you were working with 256 dynamically spawned trees... if that's not correct let me know.... gonna continue to work my way through your debug text till I find the problem... gimme a minute...
Okay, quick question...
--> LoadSaneStartingSettings GetHighQualityShadowCastingMode GetBillboardShadowCastingMode ReCalculateParents --> Reset
I notice it is doing a recalculate parents right after LoadSaneStartingSettings, but before it calls Reset(). It would only recalculate parents in this particular spot, if it detected that the parents have not been set up yet.
So just to clarify, were you spawning the trees at runtime via a script in this test? Or were you working with 256 trees that had already been manually placed?
Had to reinstall Unity, about to start looking at it now... I'm going forward with the assumption that these functions only loop like this if the manager is in the scene.... so gimme a minute to look into this...
This is really odd, I'm looking into it now... gimme a few minutes...
Actually, some of the manager's functions probably have to return a value, so you can't just return; to exit the functions. Well in that case, just try returning out of the ApplyAll() and also out of the manager's Update() function, and see if it runs with those two functions broken. Also you could try running the game outside of the editor (building it as a standalone or something), to see if it is any of the code relating to the inspector, such as all those buttons that appear in the manager's inspector window, in case any of that editor-related code is possibly what is causing the crash. None of that code gets run if you build the game as a standalone, so it would be worth a try to build it as a standalone to see if the hang goes away.
The manager is where the recalculateparents function is, but the manager also handles certain global shader variables such as the position of the sun (see the manager's update() function for some of that). Without those global shader variables, the trees won't handle lighting correctly. All of that is global in that it affects every tree, and so it made sense to me to handle it in a single location, which is why I made the manager. The manager also handles certain material property values that affect every tree in a global sort of way (most of that is done in the manager's ApplyAll function).
The first thing is to figure out why the manager is causing your scene to hang. If your scene runs and at least partially works without the manager, then I would add in the manager, and then I would add a return; command to each function in the manager, one by one, until it no longer hangs. Then you'll at least know which function in the manager was causing the hang, and we could go from there to figure out what exact line of code is causing the hang, or if it's hanging because the function is being called way too many times for some reason. I would start with the manager's ApplyAll() function, since that's the biggest one and it's probably called the most frequently.
If the computer is begging for mercy on terrain trees, it will be crashing on LushLOD trees. LushLOD trees do look quite a bit better than terrain trees. But that better looking comes at a cost, they are significantly more expensive to render than terrain trees. I don't think it'll work. Perhaps if you could somehow custom edit the LushLOD trees to make them faster... I do include the full source. One way to make them faster would be if you could batch together an entire terrain chunk worth of the trees into a single billboard, to reduce the extreme distance trees down to a single billboard. But that would be very complicated to do. But out of the box, LushLOD trees aren't going to be fast enough for what you are needing.
Hmm so I looked at your screenshots and it shows, I suppose one call to Start() for each tree in your scene, (it shows 707 calls to Start) but a very large number of calls to something inside of Start that is doing something to the tree materials.
Only thing I can think of to do is to figure out which specific line of code in that Start() function is triggering that material change. It's the Start() function inside of _LushLODTree.cs, which I don't think is too big of a Start function, so it shouldn't be too much to look through. It's something to do with materials, so that should cut it down quite a bit.,
If your project and scene isn't too big you could try to package it and upload it somewhere, so I can download it and I could try to figure it out.
Customer support service by UserEcho
Ok, earlier you pasted for me this code:
Start SetupHalfSrqTransition CalculateLODDistances UsingUltraShader UsingUltraShader Update --> Start --> CreateTreeManager --> LoadSaneStartingSettings GetHighQualityShadowCastingMode GetBillboardShadowCastingMode ReCalculateParents --> Reset CalculateLODDistances UsingUltraShader --> SetupStaticMaterial ApplyAll FindTreeUsingFastShader SetupHalfSrqTransition CalculateLODDistances UsingUltraShader UsingUltraShader --> Reset CalculateLODDistances UsingUltraShader --> SetupStaticMaterial CalculateLODDistances UsingUltraShader --> DoShaderUpdate --> GetBillboardLeavesShader --> GetBillboardLeavesFarShader >>> The following bit repeats forever: <<< UsingUltraShader --> GetLeavesShader UsingUltraShader --> GetLeavesShader UsingUltraShader --> GetBarkShader UsingUltraShader --> GetBarkShader --> DoShaderUpdate --> SetupStaticMaterial --> GetBillboardLeavesShader --> GetBillboardLeavesFarShaderCan you make me another one of these debug reports, just like this one, except this time with the code change that you just made to the manager (where you edited the ShaderSettingsChanged)? So that I can compare the two and see if there was any difference...