Hiya,
In our tests, speedtree should be slowtree since regardless, it’s not performing anywhere near as well as I suspect it could. Would like to see some lower level engine integration of what is an advertised feature. It’s a feature that doesn’t actually do anything other than import meshes and set them up. There’s no special rendering or optimisation.
Maybe I’m just doing it wrong. We don’t use Unity terrain and just place them manually. Any advice? We don’t even have many of them.
Also having similar issues. Speedtree looks great, but it is slow. Also just been placing them manually throughout scene. Culling and LODs are on and working, still slow.
Well, until some of the lower level integration gets worked out, there’s a lot of options for reducing the impact of SpeedTrees through the modeler. It depends on what you are using the trees for as far as what you may be able to sacrifice. Sometimes adjusting the LOD curves can help, or even just tweaking the LODs in unity or removing some of the collisions if your tree is out of reach of the player. Can you share a little bit more of what you are working on?
Disable SmoothLOD, this should speed things up
Hey Danny, thanks for the reply. I can’t share yet, but it’s a lot of trees, mostly mobile/desktop quality. We try to restrict hero as much as possible. It just seems as if the engine treats these as objects “we don’t know anything about” ie generic rendering. This is far from the case, so I was hoping that Unity would be able to get these fixed up speed wise.
Target hw is PS4. Unfortunately with speed tree we’ve hit a sub-30 fps which is worrying considering replacing them with just meshes hits 60. I will try the lod curve thing to see if this helps.
How much have you toyed around with the wind quality settings? That would be another place to check.
I agree
What? Are you waiting on Unity? What kind of integrations are we waiting for? I’ve had the same experience as the @hippocoder . They take an unreasonable amount of FPS off of my scene, It’s almost like something is wrong with them. I didn’t know much about them, but I was undoubtedly expecting quality and performance. For the price I was expecting them to be miracle trees that would solve all of my unity tree problems. So far they have added to them. They don’t support real-time GI, I dont know about lightmapped. Up close they look terrific, but LOD1 looks frosted or cartoony or something, it’s hard to put my finger on. And the way they are packaged with dozens_of_textures_with_extreamly _long_names makes them cumbersome to access in the interface. When can we expect improvements? Thanks.
The billboard shadow popping was an issue I raised and it’s being fixed thankfully. However, the billboards do look very different to the nearest lod in terms of shading so I think that’s also another area to look at since they’ll ideally take on light probes and surrounding colour like the other lods do.
Perhaps this will be addressed also?
We we’re taking a look at that yesterday. We’ve logged it to address it A couple ways to adjust it inside of unity, (depending on your lighting situation) is to adjust the hue color by pulling down the alpha or adjusting the hue color as a whole. If you needed to you could also edit the billboard atlas directly. You can also turn on light probes on the billboards but this apparently affects the billboard batching right now.
Are you referring to the first LOD or the billboard? As far as the integration is concerned there is a lot involved with integrating SpeedTree directly into Unity and its an ongoing process. Hopefully we’ll see some improvements in upcoming releases.
Game has constantly changing lighting conditions which makes things a little tricky batching wise. I think I’ll just rewrite the shader for less headaches with a per vert approximation which takes skybox. That should do it!
Just checking in to see if there has been any update to the performance of Speedtree in the latest (5.0.1) version of Unity. These trees look great in engine, but since we’re building VR applications and have outdoor environments, the framerate drops to unplayable levels even with a modest amount of trees.
We’d like to be able to upgrade and take advantage of this added fidelity, but with such massive performance drops, it appears that this will not be an option in the near future.
Same here. I tried SpeedTree but eventually dropped it because it’s too slow in Unity, even though they look spectacular. The transitions from billboards through the LODs are remarkably good.
The main issue for me is the rendering speed of the billboards, not so much the up close models because you can tune the LOD distances and so on to get the performance to be good enough there. The trouble is in large outdoor scenes where you have lots of trees and 99% of them are just billboards. Here’s a test I just ran which is 100% billboards due to the way my test cam is set up:
10,000 billboard trees
Unity Tree (Alder): 2800 fps+
SpeedTree (Broadleaf_Desktop from Free SpeedTrees package): 100 fps. If I turn off some options I can get it up to about 104, or about 120 if I turn off wind quality.
So I’m getting something like 28 times the speed with Unity tree billboards. As far as I can see, there are only double the number of polys in a SpeedTree billboard compared to Unity tree billboards, so that can’t be the main reason for the difference. It’s not caused by the SpeedTree billboard shader because when I swap in the standard shader the performance is the same even though the billboards aren’t even being rendered anymore. I don’t really know, but my guess is it’d be something on the Unity side when the billboard meshes are being prepared to render that’s taking up all the time.
EDIT: After looking at it more, it looks like it’s all about batching. In the Unity tree case I have this:
Batches: 35
Saved by batching: 0
In the SpeedTree case it looks like this:
Batches: 11
Saved by batching: 9247
So for whatever reason it looks like SpeedTree billboards are processed in a fundamentally different way from Unity tree billboards on the batching side which is probably the reason for the speed difference. It takes a long time to batch up 9247 things every frame. I can’t be sure, but I’m inclined to blame Unity for this one, not SpeedTree.
Hey, how are you doing with Speedtree performance? Does your custom shader help? Is it available anywhere of can I by it if it does? I’ve had to use all Mobile variants and adjust the LOD’s significantly to get my app playable. Thanks.
AFAIK 5.3+ will fix perf.
Yep, they have Speedtree billboard improvements listed in the roadmap as an on-track item. Hopefully it doesn’t get delayed, but I doubt that it will.
SpeedTree: Billboard Improvements
Perfect. Thanks, guys. The batching thing sounds like it could be the one I’ve been waiting for.
From the 5.3.0b1 release notes…
I’m curious how a ‘bit’ factors into them being usable or not. I wish the SpeedTree guys would put more pressure on Unity to get them up to speed 
I am probably late to the party, but I want to express my extreme dissatisfaction with Unity.
The SpeedTree implementation is a joke. The whole point of SpeedTree is having nice looking trees and the ability to place a lot of them without a big performance hit.
However, the team at Unity did not bother properly implementing SpeedTree support so adding a multitude of trees or grass assets to a large terrain will fail horribly. Since the SpeedTree implementation relies on the SLOW Unity LOD system, culling takes forever. And if you are doing anything dynamic you cannot rely on Umbra or other tricks.
I have just spent two weeks working around the slow collider generation (meshes primarily) performance of Unity/PhysX, and now I have to spend more time figuring out a fix for the poor performance of SPEEDtree?
Mark my words, had we not been 2+ years into a project (fulltime, professional and paid team) I would have ditched Unity for UE.
Unity needs to start taking feature implementation seriously and not just implement something half-assed to get a tick on the feature list. Otherwise people will move on, and quickly.
Grrr. Sorry for the rant, but it is relevant and deserved!
Hey,
In 5.3 SpeedTree batching speed is improved by jobifying the code that prepares the dynamic mesh for a batch of billboards, making them run on multiple cores. In our test scene it helps the performance of ~0.5ms per-frame when ~2500 billboards are rendered on a recent MBP.
SpeedTree billboards are implemented differently to TreeCreator billboards as individual renderers are used for culling, LOD-ing and are passed down to the renderloop, as Todd said. This brings lots of implementation side advantage, but doesn’t perform very well when we have thousands of them.
We are actively solving the problem of “big-scale rendering performance”: in the upcoming 5.4 the whole renderloop will be offloaded from the main thread. Additionally we are implementing the instancing feature that hopefully can improve the batch rendering performance (we are trying our best to catch 5.4 train but can’t give the promise).
Cheers,
Yao
Thank you for taking the time to respond to this. It’s always nice to see numbers attached to something in order to help level set expectations.
I am curious if the number of different SpeedTrees has an impact on the batching improvements. E.g. if I have 2500 billboards of one SpeedTree, will I see a different improvement against 2500 billboards of 6 different SpeedTrees? Pardon my ignorance if the answer is obvious.
Thanks again!