Critias Tree System [Asset Store]

I just tested now, if the trees are set on a different layer they are drawn on that layer specifically. It's just that you need a camera drawing that layer in order to draw your trees. But that is problematic, since the trees are going to be drawn on top of everything. So be careful on how you plan to manage your trees.

If you wish for different culling distances, better set them per-layer or something. But in the very near future I hope that I can implement cascade culling distances for different tree types with some nice optimized tricks in order to lift the need of having many cameras, layers and all that kind of spagetti.

I'll post more probably Saturday on the subject.

 

How does your system work with Occlusion Culling? Sometimes, I don´t see any difference enabling or disabling the UseInstancing setting in my project (Is it possible that this value is affected by the game resolution?)

 

For the instancing part it is relative to your scene, more or less. If you have a dense forest the improvement might range from 200-500% to 0% imrpovement if you have a very sparse forest. You can see that very clearly in the demo, if you tick off 'Use Instancing' the fps will drop from 70-90 to something like 20-30. It is a huge improvement for many many machines.

Occlusion culling is used, via Unity's Occlusion Group API.

 

Thank you for the reply.

However, I´ve been running your demo project with multiple screen sizes and I got different results with different resolutions. Does this info make sense?

Cheers,

 

Well, rendering at lower resolutions should work better. But what were the results? Can you tell me anything specific?

 

Have a look to these screenshot. As you can see, I´m getting better results with the instancing disabled with the same machine and the same resolution.

instancingDisabled

instancingEnabled

 

I see. I think one more person complained about that, but it's not related to my system. I think it depends on the instancing support on your video card. If you have an on-board card or a card that is not supported by unity, or if it's instancing is not really hardware but just emulated that is the kind of result that I'd expect.

If you have a latest gen GTX video card and you encounter this, then it's quite a bad problem and I'd suggest you file in a bug report for unity, describing them the problem. If that is not the case you have to scale your requirements based on your client's targeted PC's.

If you are making a PC title, an good old gtx 580/680/750Ti would do as minimal requirement. They are around 200$ each, and I'd expect people that play PC titles to have at least that. And you can pack quite a lot in them, I haven't saw many Unity games that require more than that

 

Radeon RX 480 is the graphics card used. How could I know if the instancing is supported correctly?

 

Hm... That is quite a good video card. It should support everything, including instancing. Did you installed the latest drivers?

Seeing that you are the second person that has problems with AMD hardware (since the other guy that told me this also had an AMD video card) maybe there's some kind of unity bug related to AMD hardware. That would be my best guess. How long does the scene takes on GPU/CPU? Is there more time spent on the GPU or CPU?

I think it is quite important to let Unity tech know this, that on AMD cards there seem to be problems with hardware instancing.

Would you like to pack a report from your computer with your hardware config (since I'm using a GTX, I'm irrelevant) to unity? I am sure that it will help many many people out there, that are using AMD cards.

 

Done, I´ve reported the bug 883918

 

Hello @Assembler-Maze,
I am playing with your Tree System and as your reported in Documentation, grass is gone.
I am trying to make some optimization to raise FPS, so I am trying to disable water reflection of tree and I want to ask you a thing: if I have three terrain on my scene:

• terrain with details;
• terrain with trees;
• terrain only;

I need to include all of them on Managed Terrains array in Treeifier script? As reported in your documentation I think the answer can be no, just the terrain with tree. Am I correct?

Another question: If I want remove Critias from scene to make some change and then re-add, can I only remove GameObject related to it? What about GameObject that hold all trees? If I remove it, I will lost reference or trees will be assign to the older holder?

Thanks for your support!

 

I am using two tree system scripts, but they are in separate scenes on separate terrains. I am loading them additively. My main camera can see both kinds of foliage (that are on the two layers) and is set in both tree system scripts where I have made them into prefabs. If it helps makes things clearer, I am using the Suimono water system and only want to reflect large trees. I specified a layer for all large trees and used that layer in one tree system script in the scene where I am spawning large trees. In the other scene/tree system script I spawn small plants and bushes and have them on a different layer from the big trees. When I choose those two foliage layers to reflect in Suimono, nothing is reflected. When I choose the default layer, all foliage is reflected.

 

Awesome, I really want to see how this turns out.

However from their reply they said it's a 'SpeedTree' issue. It is not a speed tree issue, it is an instancing issue, I really hope that they got that clearly.

 

1. You only need to include the trees terrain to the script
2. In order to remove them from the water reflection make a layer 'TerrainTrees' or whatever, set the system to draw the trees on that layer and exclude that layer from the reflection's drawing
3. The system is not intrusive, you can edit your trees even if the system is in the scene. Just make sure that you re-generate the trees after you modify them
4. You can delete it along with it's holder and everything else. When you need it again just add it again and regenerate your trees

 

I understand, I think I have the same behavior in my game . Just that I use the old, now deprecated, Ceto ocean system.

Well, first of all you need to leave the 'Used Camera' slot empty, since if it is set it will only draw the trees for that specific camera. If it is null, the main camera is going to be used for occlusion and stuff, but the trees are going to be drawn for all the cameras.

Maybe I should add an little addition to the system, so that you can have a camera used for occlusion culling and another camera set for drawing the trees. In case that is null, the trees are going to be drawn for all cameras.

But if your 'Used Camera' is null and you have set the layers correctly, it means that the problem is somewhere else. Unfortunately I don't have your water system to see exactly what is going on in it when the trees are rendered.

In the near future I also hope that I'll be able to make that addon where you can specify tree groups all with different distances, different cameras and different layers. So that you don't have to use tons of systems thus making your project a huge spagetti.

 

Your recommendation fixed the problem, thanks! I actually found out that by doing this, it seems billboards are on the default layer and the mesh plants are on their correct layers. Anyway to get the billboards on a specified layer?

 

Yes, just select their generated mesh (they are simply a game object with a mesh renderer/filter) and set their layer just as any other unity game object. They are held by the 'Tree Holder'.

 

Thanks for you anwer. It is exactly what I did.
I also had another problem but your previous post fix also my problem .

Do you know if I need to uncheck on Terrain settings Bake light Probes for Trees to make it working in the right way with Critias?

EDIT: I do not why but today if I open project all trees are hidden in Scene view. If I press Play, I can see all trees. If I press Stop and switch to Scene view now I can see trees, but only if I zoom in, they disappear. If I save the project, all trees disappear. WIth my backup project (without Critias) I do not have this issue. However yesterday I did not have this issue.
Can be this video useful?

 

"Do you know if I need to uncheck on Terrain settings Bake light Probes for Trees to make it working in the right way with Critias?" - Well, if you are using instancing there's no light probe used since it is disabled by the API. If you don't use instancing they are using light probes. So the checkbox should really not do anything, so I don't recommend having it on. But it will not ruin anything if it is on either.

For the other problem, the one in the scene view, I have absolutely no idea how to fix that. It is a huge pain convincing Unity to render anything in the SceneView. I need a lot of time, time that I don't really have now, in order to make it run in the SceneView, that if it is possible. I have the exactly same annoying problem with the grass, that, trust me, is FAR more worse than the trees, since I am almost literally blind when painting it. That is a reason why I didn't published the grass system. As a workaround in it I have some sort of complicated system of grass-trees that are loaded as trees on some terrain and having only a cell loaded in memory at a single time. But that is not a real solution.

For the trees the only workaround is to enable the terrain's 'terrain trees' and keep them around until you do not need them any more. That is what I do. I can't think of anything else at the moment, sorry.

When I'll fix that I'll post here asap, since it is a problem driving me nuts too. And yea, i'll also have some option to paint the trees directly into the system without having to pass them through the terrain. But when, I do not know. There are other simpler to solve issues that need to be attended first.

 

I will turn off Bake Light Probes for Trees, just to be sure. Yeah, I forgot to mention that I am using Instancing.

Oh, that's not a problem. I thinked that was a problem just for me, because I remember that I can view them yesterday, but now I think that I failed.
It is curious that after Play/Stop trees appear, but zooming in make them disappear just where I zoom (LOD invert), but it is more curious (for me) that saving project make all them disappear from scene.

Thanks (also this time) for your quickly support (I was struggling tring change clip plane, field of view, layout, turning off cameras)!

 

Maybe you had 'null' for 'used camera'? That might also render all the trees for the SceneCamera too, but I'm really not sure. And it's not the trees that are dissapearing, it's the manually managed billboards that do that.

For now just use the default Unity's trees for editing and when I'll solve the problem I'll let you know.

 

I am attempting to add a Wind Zone to a scene. On any other scene I create, i follow the steps in the documentation and the wind seems to work fine, as it does on your demo scene. However, on my main scene, although the wind seems to work in scene view, when I run the game the trees do not move. Are there any special steps for getting Wind Zones to cooperate?

It worked at first, then the Wind Zone was removed and added back in. After this, the trees wouldn't move in the game view, only in the scene view. Is it necessary to paint all the trees you want to move after you set up the System, or can you copy trees from an existing terrain?

 

You always have to copy the trees from an existing terrain. In fact when you press 'generate' the trees are always extracted from the provided terrains. You can add/delete them at your will, just make sure that you re-generate them after you are finished editing them from your main terrain.

For the wind zones there's no special requirement, just add it to your scene and set it's values to whatever you require. Make sure that you have made the steps from the docs right, maybe see if there are any errors in the console etc.

If that still doesn't work, please pack a project for me, put it somewhere on dropbox or something and I'll look over it tomorrow morning. Just don't put in in millions of trees, so that I can get it up and running fast. You can contact me on private for any other details.

 

Sorry @Assembler-Maze for the question I'm doing but I think that you are one of the few people that know practically what's instacing needed to make it works...so here the question.
In the official manual here there is this

"Batching priority
Static batching takes priority over instancing. If a GameObject is marked for static batching and is successfully batched, instancing is disabled even if its Renderer uses an instancing Shader. When this happens, a warning box appears in the Inspector suggesting that the Static Batching flag be unchecked in the Player Settings.

Instancing takes priority over dynamic batching. If Meshes can be instanced, dynamic batching is disabled."

Is it true? Your system seems not affected by this or should we disable static batching?

I'm quite confused about the GPU instacing with Unity, the main reason is surely my ignorance on this matter (I'm not a programmer and I'm trying to study how realtime graphics works) so if you could clear my doubts I'll really appreciate (actually I'm alreaddy really appreciate your tree system )

Thanks in advance

 

The system is unaffected by this because it uses Unity's dedicated DrawMeshInstanced method to draw the tree meshes in the TreeSystem script. No need to disable static batching because for static batching to work, as you might know, gameobjects need to be static, which the trees aren't. Might be wrong, but I believe that trees managed by this system aren't even gameobjects anymore, but simply meshes without logic behind them.

 

@No0B25 is right, there isn't any game object that is marked as static in the hierarchy so any setting that you should have is not affecting the trees. That option is available only when the GPU instanced objects are managed automatically by Unity, that is when the objects really exist in the hierarchy.

For my tree manager that is not the case, since the trees exist only 'in memory' and are drawn manually with 'DrawMeshInstanced' that overrides any settings that you might have. So don't worry my trees are not affected by an setting you might have, they are non-intrusive on your game

 

No, I set Used camera with my Main Camera.

Thanks for you answer and sorry for this delay.

 

Any way to use blend probes or proxy volume with this system? I imagine that only realtime lighting will work?

 

Only if you don't use instancing. And I don't think you can use proxy volumes, since there's no 'DrawMesh' that takes a proxy volume as a parameter. It is not a problem with my system, Unity does NOT support blend probes with instanced objects.

And yes, only realtime lighting will work, if you want baked lighting you have to use game objects.

 

Hey there. I have been trying to get this to work, but no matter what I do, only the billboards get rendered and the trees themself do not show up. Any idea?

 

I am in the process of finishing a video tutorial, that will explain everything in detail. I'll post it here as soon as I have it working, at the moment I try to recode it from some weird format to something usable

In the meantime check your rendering settings, make sure that you have the 'TreeSystem' script added, that the correct layer and camera are set, that all the fields are referenced and that there are no runtime/eidt time errors in the log.

 

For those interested, I have finally managed to set up the step-by-step setup video tutorial! You can find it here!

 

I also had billboards only on Unity 5.5.1 - I traced it down to the culling group targetCamera not being set. I solved this by replacing these 2 lines in Start():

Code (csharp):

1.             if(!m_Settings.m_UsedCamera)
2.                 cullingGroup.targetCamera = Camera.main;

With this:

Code (csharp):

1.             cullingGroup.targetCamera = m_Settings.m_UsedCamera ? m_Settings.m_UsedCamera : Camera.main;

Might not be exactly what you want, but it was enough to prove to me that this plugin works well.

On a slightly different note, I have been having trouble with billboards in Unity 5.6b11. This error appears in the console:

Sometimes the billboards do actually work (sometimes just for one frame!), but most of the time it's mesh trees only.

Loving this plugin though - it's really bringing out the best in Unity trees!

 

Yes, the fix already exists on github, but it will take another 5-10 days (cry) to make it to the asset store. Until then, please, better grab it from github else you will find some other bugs too.

I haven't updated this for unity 5.6, yet, but I'll have to do that anyway, since I also need the 'DrawMeshInstancedIndirect' API, and that also for the grass system.

 

Well, it took a little less time to update the package this time, but, unfortunately, I forgot to add the code . I've only updated the description.

When the code is going to be reviewed and approved to (with the fixes mentioned above) I'll post here.

 

The less-buggy code is also updated on the asset store! No need to grab the latest version from github any more! (at the moment at least)

 

I've got the latest version, but I'm getting this error when I click Generate Trees:

Invalid cell sizes for the count of managed terrains!
UnityEngine.Debug:LogError(Object)
Treeifier:GenerateTrees() (at Assets/CritiasTreeSystem/Code/Treeifier.cs:386)
TreeifierEditor:OnInspectorGUI() (at Assets/CritiasTreeSystem/Code/Treeifier.cs:28)
UnityEditor.DockArea:OnGUI()

My terrain is 2200x2200, and I did Cell Info, which says:
{S: [2] C: [1100]}{S: [4] C: [550]}{S: [5] C: [440]}{S: [8] C: [275]}{S: [10] C: [220]}{S: [11] C: [200]}{S: [20] C: [110]}{S: [22] C: [100]}{S: [25] C: [88]}{S: [40] C: [55]}{S: [44] C: [50]}{S: [50] C: [44]}{S: [55] C: [40]}{S: [88] C: [25]}{S: [100] C: [22]}{S: [110] C: [20]}{S: [200] C: [11]}{S: [220] C: [10]}{S: [275] C: [8]}{S: [440] C: [5]}{S: [550] C: [4]}

so I've tried size=2 with cells=1100, and size=4 with cells=550, same error. Can anyone see what I'm doing wrong? I'm using Unity 5.5.2 on Mac 10.11.5.

thanks!

 

You have only one managed terrain, but multiple sizes in the array. Cells are always square, so it takes only one entry in the array for one terrain.

 

Cell sizes count have to be of the same size of the managed terrain count (as pointed out by no0b25). You have 2 cell sizes instead of one. If it still doesn't work try the other cell size of '550' (instead of 1100).

 

Thanks @No0B25 and @Assembler-Maze!

So I fixed that and generated the trees....but performance was at least 2x worse than normal speedtrees. So then I went and got the demo project (which I should've done in the first place), and found that it too runs very poorly. But very odd -- the profiler shows nothing significant using up cycles, but the stats readout (and runtime feel) were quite bad. See screenshot. I'm using Unity 5.5.2 on Mac 10.11.5. Could this method perhaps not work on Macs?

 

It certainly does, your setpass call count would've been way higher if you weren't using the tree system with instancing. You could add a GPU profiler and see what that shows. I suspect it's too much geometry for your GPU to handle, or your GPU provides too little memory bandwidth. Exactly what Mac do you have? We have a 2011 iMac with the top end GPU and it can't handle our use case at all, too.

Probably the best thing to do in your case would be to reduce the tree distance (the slider at the top left).

 

Looking thoroughly into the problem, I think it is much more complicated that it seems at the first look. I will try to explain in a few words why. For the moment try the following thing:

My trees are sent into batches to the GPU for processing. On Mac it's a OpenGL implementation try lowering that sent batch size from 1000 (the default) to something like 50-100. It's the variable MAX_BATCH in 'TreeSystem' script at line 222: "private static readonly int MAX_BATCH = 1000;". I am thinking that on OpenGL if you send too many trees that might fill up the buffer and decrease performance instead on increasing it.

If no improvement can be seen, see how it performs when you disable instancing and decrease your tree density.


The problem in the bigger picture is that only the GTX video cards really implement draw instancing the right way. (unfortunately). I have received many more complains from people using AMD/Intel cards for poor performance while using my system.

There might be 3 possible explanations for that:

1. There is a bug with Unity instancing on non-GTX video cards. I have asked people to submit some bug reports to the Unity team (and they already did) to see why instancing fails on latest gen AMD and other video cards. The issue is still open.
2. There might be a hardware problem and a bad implementation my the manufacturers of non nvidia hardware of instancing. I am not sure about that, still waiting for a response on the submitted issues. I might have a clue that that might be the problem, from a GDC conference with the following graph:



It seems that 'DrawInstanced' works at least 2x slower on non GTX video cards. As, I said I am not 100% sure about that but if it is confirmed I will have to implement the more complicated 'SoftInstancing' solution. I am not happy at all about that, but if it is a must then we'll have to do it sooner or later.

3. Your PC's spec are too low. See if the fill rate is the problem and not the batch count. Fill rate takes up GPU time while batch count takes CPU time. See which out of the two is your bottleneck. See what kind of hardware you are targeting and test your game based on it. Nowadays I consider a GTX750Ti a minimum system requirement.

 

Thanks for the detailed reply. My MacBook Pro has a GeForce GT 750M....so is that at GTX card or not? I guess that is a bit below your GTX750Ti minimum spec...but if that's really the minimum spec, then that rules out this system for my projects, since I have a lot of players with non-gamer computers.

I changed MAX_BATCH to 75, but that didn't help much. I reduced the distance to 150 or so, and that helped a lot on the CPU, but not on the GPU -- see screenshot. I also tried disabling three of the terrains in your demo project, and that didn't help hardly at all. I also tried disabling shadows on lower LODs on the tree models, but that didn't help the GPU issue either.

 

I see, it is quite bad. Would you have time sometime for some remote debugging? If not, try some 'deep profiling' maybe you can provide some more information for me. To see exactly where on the GPU the stall is. Also try disabling instancing.

In the future (unity 5.6 with DrawMeshInstancedIndirect) I really hope that I can provide some more smarter methods of 'instancing' that are a lot more stable across platforms. Unfortunately, until then all you can do is to either bail the system or wait

 

Sure, I'd be happy to help. I'll PM you my Skype.

How do I disable instancing?

 

There is a checkbox "Use Instancing" just below the 'Distance'.

 

Here's a screenshot showing profiler with Instancing (left third of profiler) and without (right third) Instancing. GPU is unaffected, but CPU is much worse without it.

 

I see. You can try 2 more things:

1. Check the "Use SpeedTree (WARNING MIGHT KILL PC)" checkbox to see how it would work WITHOUT my system at all, but only using the default Unity implementation.

After that post one more screenshot here. I'll tell you the second idea that will probably fix the problem for you after you posted the screenshot here.

Thanks!

 

Well, it is much worse with "Use Speedtree":

 

Well, using the default implementation of SpeedTrees made things at least 4x times worst, I see...

You can try the following:

1. Further lower the tree distance

2. Make a stand-alone build. It should work considerably better when not in the editor. Since in the editor you have '40-60FPS' at the stats, while the widget displays 10-15. Test in a stand-alone build the results. I consider the editor ones quite irrelevant

3. The GT750m you have is about 4-5x times slower than my minimum requirement of a GTX750Ti. If your client's/users PC specs are so low you would be forced not to use SpeedTrees at all, no matter if you use my system or not. Try migrating on TreeCreator or further lower the tree distance/density.

My system is using some hardware optimizations (when they exist) it isn't supossed to make your hardware faster.