Using Tree gameobjects vs Unity's built in system

It's not such a huge job, I think that a good coder could come up with something well polished in a week or little more.
But it's definitely not something that anyone can code, this is sure.

It would be nice to find it on the Asset Store

 

A lot more work than im willing to put into it at this time anyway : p

 

Yes sure, and especially if anybody wants to do something like this he must be inspired.

 

personally i would be happy just with an in editor solution… no need to create any imposters at runtime if the static ones have normal and depth maps and come with a shader that allows real time lighting as those of c4 engine.

lars

 

It all depends on the quality you want to achieve and on the mass of work.
Real time impostors require NO TIME to set up and, as I wrote, they could work with ANY mesh, when well coded.

 

Yeah...I'll probably be doing good to finish the leaf optimizer anytime soon. I'm out of town this week...and what few hours I have to spare otherwise, I spend them on other projects. It's just not a huge priority atm. I'm pleased already having ditching the built in tree solution.
Plus...I have to start looking at a terrain replacement. And grass/details. Wheeee!

 

Resurrection!
Im coming to a tipping point here were i really need to decide what solution to use and currently its leaning towards using a separate system for trees.
Any one feel they have just a small bit of time to spend working on this thing?
Just to get the basics up and running i don't think it needs a lot of effort.
Personally i feel that just get TerrainTree->prefabTree conversion, editor integrated and a simple billboard system in place would come a long way.
Did some work today and made a simple script to convert from terrain trees to prefab trees without any need for setup at all.

 

Well, I had switched to tree prefabs instead of Unity's built in system, and personally like it better. I also put in PoolManager 2, to help with pooling since there are so many trees. I don't like that there are so many instances, but what can you do? I was happy with it (for the time being), and have started working on a custom terrain system.

Well...holy crap. I was reading up on something and came back across this, in the scripting reference:

http://docs.unity3d.com/Documentation/ScriptReference/Graphics.DrawMesh.html

I don't freaking believe it. How the crap did I forget about this
So yeah...looks like I won't be using PoolManager for this after all. And all those tree instances will be gone. I have to switch back to working on trees now, to get this in. It just seems like system that draws a lot of something (trees, grass, etc) is far, far better off using this than creating a gameobject.

One thing to keep in mind, this is only for non-interactive trees. There's no collider as far as I can tell. So nearby trees will still need to be gameobjects.

Currently, the game world loads a 4x4 grid of detailed world around the player. Each grid chunk is about 512 meters in size, so the player is roughly in the middle of a 1km square area of detail.
But with the DrawMesh functionality, I think I'll be changing that. Around the player will be a smaller, high detail area, with trees as gameobjects for interaction. Maybe .5km square.
After that will be the larger detail area, with trees drawn using DrawMesh. Anything outside that will probably be a billboard.
Crap, who knows? It's amazing how you think you've got your direction figured out...and wham hey need to take a different approach!

Virror...as far as time to work on this, I guess the question is: Is there a common approach that meets our needs?

For today at least, I think what I need is:
Draw very distant trees as billboards. Maybe using Graphics.DrawMesh, maybe just using the particle system. I don't know yet.
Draw somewhat near trees using Graphics.DrawMesh
Draw nearby trees as gameobjects, so that they can be interacted with.

If this approach is generic enough, there are some details to work out. I think scaling support might be an issue.

 

So, what did you miss? I think you missed to paste something : p

Did some more work on the scripts and now i have the automatic LODgroup + billboard + texture generation working fully, both with a single object but also with a whole folder, all with a single button click. Texture, material and prefab all gets created on the filesystem and everything is assigned correctly.
Also fixed some issues with the convert terrainTrees -> prefabTrees script to organize everything into correct parent objects and a "trees" root gameObject.
Will post what i have later here when i have done some small fixes and improvements to it, this also works with a single click and no need to assign anything and includes options for random rotation and scale..

 

Sorry, I fixed it. But the thing I missed was Graphics.DrawMesh. Seems like an awesome way to quickly draw many non-interactive objects (distant trees), and you don't have to have gameobjects for them. I guess this is how Unity currently handles the trees with its built in system, so you don't see all those instances.

 

So, what about putting a empty GameObject with a script that calls DrawMesh() in the LOD object between the gameObject and the billboard? That way it would be managed automatically together with the billboard and the other stuff. Think it would work?

 

I think it would...but it would still mean having one gameobject instance for each tree, even if you grouped them. This probably isn't an issue with a small number of trees, but even using pool manager I get a hit with mine, but I also have a somewhat dense forest.

Personally, it would suit my project better to display near trees in full detail, with LOD groups. Maybe a couple of hundred trees.
After that, I would prefer to use Graphics.DrawMesh to display far trees, at the lowest LOD mesh (not billboard). I think this would be fast, and not require individual tree instances.
Past that...billboards for distant trees.

So...I know it's not as generic and straightforward and just using LODs, but for a project like mine the performance could make all the difference.

 

But even billboard trees would create an instance right? Since you need to use either a plane mesh, particle system or some similar trick.

 

From what I understand about Graphics.Drawmesh...no. It only draws the mesh, there is no instance.
So, to draw all billboard planes for a particular tree, you would just do this (pseducode):

Code (csharp):

1.     public Mesh planeMesh;
2.     public Material treeMateriall;
3.     void Update()
4.     {
5.         foreach(TreeData tree in BillboardTrees)
6.         {
7.             Graphics.DrawMesh(planeMesh, tree.Position, tree.Rotation, treeMateriall, 0);
8.         }    
9.     }

So if you wanted to do it this way, you would have one gameobject that draw all pine tree billboards. Another would have one gameobject that draw all oak tree billboards.

I think I would have one gameobject, a TreeBillboardManager. It would have a reference to the plane mesh, a material array that holds a reference to each tree's billboard material. So, if you had three different types of trees, the code would do something like this:

Code (csharp):

1.     public Mesh planeMesh;
2.     public Material treeMaterial[];
3.     void Update()
4.     {
5.         foreach(TreeData tree in BillboardTrees.GroupBy(tree => tree.Type))
6.         {
7.             Graphics.DrawMesh(planeMesh, tree.Position, tree.Rotation, treeMaterial[tree.Type], 0);
8.         }    
9.     }

This would draw all billboards for the first tree type, all billboards for the second, and so on. Granted..the code is just pseudocode and not correct.

And this is probably a bad initial approach...I wouldn't do the grouping every frame, only when the player moved position enough to warrant it. But the grouping stuff could be done on another thread.

 

Yes, if you use DrawMesh for the billboards thats correct, but i think a simple plane is still cheaper than DrawMesh for billboards.
Also, does the instance reference actually create any extra performance drops at all? Are you sure about that?

 

Nah, this is all theory until I get home and try it. But I have a hard time seeing how DrawMesh could be slower. And the billboard mesh for the tree would just be a plane...two triangles, 4 vertices.


It doesn't create an instance for each mesh (avoiding slow instantiate and memory usage). No need to pool objects.

If you don't have a shader that orients the billboard, you have to modify the transform, which would work the same whether you did it in the drawmesh call or in the Update() function.

I don't know how LOD groups work internally. If it is really just a script that unity checks on each LOD group, that unity calls every Update()...seems like that would be slow with hundreds (or thousands) of LOD tree instances out there.

If they instead have a LOD manager, where the object is registered with the manager and it just loops through them, then that might be faster.
But if then...would it really be as fast as that tight DrawMesh loop in the previous post?
I'm just saying...I'd use regular LODs for nearby (interactive) trees, a relatively small number. But I'd use DrawMesh for non interactive or distant vegetation.

[edit]
Also, in the MaterialBlock properties for DrawMesh, I see this in the docs:

Unity's terrain engine uses MaterialPropertyBlock to draw trees; all of them use the same material, but each tree has different color, scale wind factor.

Graphics.DrawMesh copies the passed property block, so the most efficient way of using it is to create one block and reuse it for all DrawMesh calls. Use Clear to clear block's values, and AddFloat, AddVector, AddColor, AddMatrix to add values.

This just reinforces that internally, Unity uses this to avoid the tree instances showing up.

But the proof is in the pudding. I need to setup a benchmark I think.

I would also like to say...it would nice if someone from Unity tech were more involved in discussions like this. Not trying to be egocentric, but this is a discussion by people who are very interested in Unity, and more contributions by Unity tech developers could shed so much light on things.

 

Also...couldn't AddMatrix be used to provide a simple shear effect to trees or grass, creating a simple wind effect?

 

I guess only way is to try and and make a few benchmarks to see : )
Might be a good idea with the matrix thing.

 

So far...so good. I got 30 more fps by using DrawMesh, than the built in tree implementation. I'll upload the project in a little bit.
Unfortunately::::
DrawMeshNow is shown as being obsolete. Which is odd, since it does exactly what I want. DrawMeshNow is what it says to use, but the functionality is different and NOT What I want.

So...hopeful but concerned also :|

Here is the script:

Code (csharp):

1. public class TreeManager : MonoBehaviour
2. {
3.     public Terrain _Terrain;
4.     public Mesh TreeMesh;
5.     public Material TrunkMaterial;
6.     public Material LeafMaterial;
7.  
8.     private List<TreeData> trees = new List<TreeData>();
9.  
10.     // Use this for initialization
11.     private void Start()
12.     {
13.         foreach (var tree in _Terrain.terrainData.treeInstances)
14.         {
15.             TreeData newTree = new TreeData(tree.prototypeIndex,
16.                                             new Vector3(tree.position.x * _Terrain.terrainData.size.x,
17.                                                         tree.position.y * _Terrain.terrainData.size.y,
18.                                                         tree.position.z * _Terrain.terrainData.size.z));
19.             trees.Add(newTree);
20.         }
21.         Renderer a = new Renderer();
22.     }
23.  
24.     // Update is called once per frame
25.     private void Update()
26.     {
27.         Camera main = Camera.main;
28.         var treeBounds = TreeMesh.bounds;
29.         var planes = GeometryUtility.CalculateFrustumPlanes(main);
30.         foreach (var tree in trees)
31.         {
32.             treeBounds.center = tree.WorldPosition;
33.             if (GeometryUtility.TestPlanesAABB(planes, treeBounds))
34.             {
35.                 Graphics.DrawMesh(TreeMesh, tree.WorldPosition, Quaternion.identity, TrunkMaterial, 0,main, 0);
36.                 Graphics.DrawMesh(TreeMesh, tree.WorldPosition, Quaternion.identity, LeafMaterial, 0,main, 1);
37.             }
38.         }
39.     }
40. }

 

Ok, I come bearing gifts. Not benchmarks, I ran out of time. But I did bring a webplayer (with a little fun), and the actual project itself.

But it -is- faster.

Here is the project link:

https://dl.dropboxusercontent.com/u/174731243/Tree%20Drawmesh%20Project/TreeDrawMesh.unitypackage

And here is the web player:

https://dl.dropboxusercontent.com/u/174731243/Tree Drawmesh/Tree Drawmesh.html


There are 10,000 trees in this scene.
Enjoy!

 

LOL, nice one!
So you say DrawMesh gives you 30 more fps than using terrainTrees, have you compared it with using meshTrees?
I sadly have no time today to look at this but will look into it tomorrow afternoon : )

 

I think that when Unity is running the scene, after it's been loaded...it probably is on par with just using instantiated trees. Because at that point, resources are loaded and it's just drawing.

But it gives pretty much INSTANT startup time. Instantiating those trees would take quite a while. DrawMesh does it in a blip. That's kind of nice.

 

Any idea why in treebench, the framerate stalls completely on movement but not rotation?

 

Greetings, Hippocoder!
Last night, I seem to get 120+ fps with the trees just sitting there, even if I had rotated them on initialization.
When I "animated" them by making them bob or spin, I seem to recall the fps dropping to around 110fps. Is this what you are referring to?

I'll get some more time tonight to fiddle with it, and include a fps counter in the display. I just ran out of time.

 

In the webplayer trees are rotating and floating up and down is this correct?

 

Yes, I was just having some fun, showing how easy it was to change the tree positions and such. I probably should have included one that didn't get so annoying.

 

hi there,

the script does not compile for me:
"Assets/TreeSpeedTest/TreeManager.cs(19,18): error CS0246: The type or namespace name `TreeData' could not be found. Are you missing a using directive or an assembly reference?"

any chance of getting this fixed?

lars

 

Sorry Lars. When I pasted that last page, I forgot to also paste the TreeData Class.
I'll have to recreate it from memory...it's basically just a data class, to hold tree information. It should just look something like this:

Code (csharp):

1.  public class TreeData
2.     {
3.         private readonly int _treeIndex;
4.         private readonly Vector3 _worldPosition;
5.  
6.         public TreeData(int treeIndex, Vector3 worldPosition)
7.         {
8.             _treeIndex = treeIndex;
9.             _worldPosition = worldPosition;
10.         }
11.  
12.         public int TreeIndex
13.         {
14.             get
15.             {
16.                 return _treeIndex;
17.             }
18.         }
19.  
20.         public Vector3 WorldPosition
21.         {
22.             get
23.             {
24.                 return _worldPosition;
25.             }
26.         }
27.     }

If you are using the sample project I posted, though...that -should- have this class in it, with some updates. If it is missing from the project, I'll have to see what the deal is when I get home. My apologies for the inconvenience, I was getting too hasty last night.

[Edit] I just downloaded the package and verified it has both the treemanager and TreeData classes, so it would be better to look it if you wanted a more "complete" picture of what's going on. The script I pasted was really just to show the main way of using DrawMesh to draw all trees in a scene.

 

Here is an updated webplayer. Some changes:

FPS display.
These are not mexican jumping trees.
You can toggle between Unity's standard trees, and the DrawMesh ones.
This show how the DrawMesh trees give you more power over color. Instead of just shades of gray, I show the oaks can go from shades of white (full green oak) to a shade of brown (fall oak).

https://dl.dropboxusercontent.com/u/174731243/Tree%20DrawMesh%202/Tree%20DrawMesh%202.html

One thing to note: Changing the colors has a slight performance hit, but it still comes off as faster than Unity's. But this way, you can change the color of just the leaves, instead of the whole tree.

And here is the project download:

https://dl.dropboxusercontent.com/u/174731243/Tree%20DrawMesh%202%20Project/TreeDrawMesh2.unitypackage


Anyway...I think that concludes my investigation into DrawMesh, unless something comes up. Now to make use of it!
I hope this has been useful to someone else. Maybe we'll see a new tree system on the asset store before long (not from me though, I have other things to focus on).

Cheers,
JC

 

Clearly shows difference in performance for me when looking at a valley filled with trees, DrawMesh can sometimes almost be 2 times faster. This really has potential, good find

 

Hiya, no...

1. if I turn the camera, there's a few stutters but it's generally ok.

2. if I walk somewhere the framerate stalls, becomes <1fps (same for both unity and drawmesh examples actually)

3. the drawmesh example appeares to be 0.5 fps slower.


All on mac mini intel HD 4000 - probably just a limit of that thing, or unity shadows or such. Although its odd that its relatively smooth (10fps) if I'm not moving.

 

Hippo, here's a another version to try:
https://dl.dropboxusercontent.com/u/174731243/Tree%20DrawMesh%20Forward%20Fast/Tree%20DrawMesh%20Forward%20Fast.html

It's with no shadows, "fastest" quality settings, and I also switched to forward rendering. Also dropped down to 2000 trees instead of 10k.
Would you might trying that one and let me know what results you get?

 

hi jc,

thanks a lot for the treedata class. adding it made the script compile without any errors.
i also had a look at the latest webplayer but could hardly see any difference as far as performance is concerned:
draw mesh: 20.1 fps
terrain trees: 19.4 fps

i like the feature of just adding color to the leaves, but using "draw mesh trees" i have noticed some sudden popping shadows when looking around and trees get culled.

and i guess using draw mesh instead of regular game objects does not let you take advantage of any static batching or occlusion culling so i wonder under which circumstances using "draw mesh trees" will be faster.

lars

 

I'm not sure why some people are seeing a performance difference...and some are not. My first thought is, is there some other bottleneck? I suspect (though I don't know this for a fact) that Unity's tree drawing and mine are close cousins. Running the project on my desktop, there is quite a big fps difference. In the weplayer, I see about a 20 fps difference...but drawmesh caps at 50, so it might be more.

Hmmm I'll have to check the popping issue...it shouldn't happen, it only culls trees that are outside the shadow distance. Maybe it's happening on the boundaries, where shadows 'stretch' from outside the boundary inside, and the tree that is removed outside the boundary shows a shadow pop when it is culled. I could add some leeway, but if the sun is very low to the horizon, you will have a long tree shadow. Basically, I would have to get the tree height, and depending on the angle of the sun (and the tree boundaries) it would allow for a greater culling distance if the sun is at a lower angle to account for a longer shadow.

This is really an alternative to the built in tree system, and as far as I can tell it works about the same, with performance improvements in some cases. Like the built in tree system, it doesn't take advantage of any batching at all. As far as occlusion culling...I honestly don't know that it benefits from that either. but I would suspect it doesn't.

I might add some raycasting against the terrain to add culling for trees behind the landscape, it would mean every X milliseconds, each tree's visibility is checked. I've done some initial testing, but for the life of me...I can't get linecasts to work right so far. I've set the terrain to layer 8, but when I linecast against the terrain layer it hits nothing. When I linecast against everything, it works. Errrrrrr.

 

that’s it i think.

btw i have done some tests using
a) 72 trees as game objects, lods (no simplified geometry but just a more simple shader without bending on far away trees) and static batching
vs.
b) 72 "drawMesh" trees both on a flat terrain

result:
a)
18 fps
main thread: 55.7ms
renderer 4.8ms
draw calls: 244
batched: 216
vbo total: 29 - 12.6 MB ?????????
shadow casters: 73
b)
18.6 fps
main thread: 53.9ms
renderer 6.1ms
draw calls: 439
batched: 0
vbo total: 25 - 409.6 kb ?????????
shadow casters: 145

 

It's 48fps either way with the drawmesh version dropping down to 47fps on occasion. Seems to be some other limiting factor, probably fill rate or something. So for this computer (so far), drawmesh is slower.

 

Well, drawmesh and instantiated trees should be pretty much the same when it comes to performance, the only major benefit from the drawmesh is probably thats its faster to create and might require a bit less memory.

larsbertram1: Static batching is generally not recommended on stuff like trees since it has a very big memory overhead as you can see since it needs to store the trees in memory.

 

Hello, all.

I am interested in what's going on here and would like some guidance! Instead of starting my own thread, I think it'd be better to revive this old one seeing as how a lot of good information can be found here that I think a lot of others beside me would benefit from reading.

This thread ended a little abruptly, so I've been unsure of the implementation of trees I have in mind, if someone could give me some feedback on it:

I'd like to place a lot of trees that the player, from a third person camera, can interact with. So judging from the observations made in this thread, I will have to go with instancing a bunch of trees from prefabs. I think everything's alright so far...

To go about placing the trees, I will just paint terrain trees over the terrain and have a script:

Code (csharp):

1. foreach (var tree in Terrain.terrainData.treeInstances)
2.         {
3.             Instantiate tree prefab at the location of var tree. The prefab will have attached the behaviour script from interaction
4.         }

After doing that, will I have to make sure I delete the terrain trees I've placed using the brush in the editor? Or will leaving them be not have any problems?

Sorry, this was all I could really glean from the thread. Any help with a procedure to approach my goal would be appreciated, I'm sure I can figure out how to script myself, it's really just the implementation that gets me.

 

If you do that then yes you will need to remove the old trees or you will end up with duplicates which will have a bad impact on the performance and also mess up our interaction with the trees.

 

I am confused about the importance (really the general handling) of the terrain trees, because in jc_lvngstn's package earlier there were no provisions made to remove the terrain trees when switching between rending the DrawMesh trees and rendering the standard trees, but the standard trees are hidden as if by magic when the GUI button is pressed.

Also, in his scene I am getting higher fps when using the standard terrain trees compared to the draw mesh ones. Isn't this the opposite of what is to be expected?

 

I have never used his package, so i have no idea how that works, sorry.

 

It was mentioned earlier that a possible solution to having 10,000 trees clutter up the hierarchy is to parent each tree game object to a tree parent game object.

I've put that into practice and it works as intended by seems to have a side effect of reducing my fps from 60 to about 2, so I'm not sure this is a viable solution.

 

So your saying that the actual parenting is reducing the fps in your scene? That sounds very strange, should not matter at all.

 

There is a "draw trees" checkbox in the terrain settings that you can turn on and off; that's probably what jc_lvngnston's plugin toggles.

 

Also, I'm kind of sad this thread didn't come up with an amazing solution, because I'm still fighting daily with Unity trees.

 

I did start with a nice shader that had multiple billboards from different angles that faded between them, bumpmapping and some stuff. But i suck to much on shader programming to iron out all the bugs : p

 

I just noticed this thread was resurrected heh. But yes, that is exactly what I did, just told Unity to stop drawing the terrain trees.


As far as an amazing solution...I guess it depends on your problem and your project. In some cases, Unity trees are just fine. Using Graphics.Drawmesh should be the fastest solution for mesh trees that you don't need to interact with. Using trees as gameobjects is great for nearby trees imo.

I think internally, the built in system uses graphics.drawmesh to draw the trees, and combines the tree colliders into one batch (or batches). In fact, graphics.drawmesh probably handles drawing all mesh objects if I had to make a guess.

If you are talking about billboards...yeah, I know what you mean. Virror is probably more knowledgeable with shaders than I am, and I don't have a nice, dynamic billboard system. I don't even think a billboard shader is the hardest part. I needed very dense forests, and ultimately for that you have to batch stuff. Not to mention once you batch things and start moving around, you have to "un batch" the trees then when they are close enough to be a mesh tree. But most people may not really need that.

 

Has anyone found a decent solution to the "see through the bottom of the tree" problem?

 

Screenie?

 

I mean what was mentioned on the first page of the thread; how Unity treemaker trees don't have a cap at the bottom of the trunk, so if they fall over you see through them. I was hoping someone had a script to fit a poly in the bottom or something.