Speed tree optimisations?

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

• Can Cast and receive real-time shadows
• Performance improvements via batching

 

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...

• SpeedTree: Billboard batching performance is improved a bit.

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

https://unity3d.com/unity/beta

 

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!

 

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!

 

Thanks Yao! your efforts are always appreciated!

 

Is SpeedTree batching performance impacted by scaling (I know the generic dynamic batching is)? Are there other factors that impact batching? I would suspect shadows etc. ruins batching?

 

For my team trees are also a big topic since ever. We have our own solution for trees that are in distant(non reachable) areas. it outperforms speedtree billboards by a factor 100(just a wild guess). It is only for the distance though.
This may come off as shameless advertising but actually its a bonus feature that i added to my asset Horizon[ON]. Somebody might find it usefull, so here are some screens:

 

That makes sense, thanks for the explanation!

 

Unity 5.3... speedtree performance is still horrible. I should had never bought the speedtree packages. They are sitting ducks on my assets list. Completely useless due to the performance that seems to be near to 20 times slower than regular unity trees.

Anyway, I hope eventually things change, but it sure has been a long time without a real improvement!

 

Yep, same here. I wasted a fair bit of money on it all. Performance up close is great and the LOD transitions are fantastic. It's only the billboarding performance that prevents me from using SpeedTree with Unity.

 

It is quite clear they are not working on the Speed Tree implementation itself. Rather they are slowly improving the core batching functionality in Unity. While that is good, it also means that the SpeedTree functionality in Unity is a potential dead duck. It might not reach the promised potential within a reasonable time, or ever.

I have to wonder, what is the real point of implementing features only halfway? Still no proper billboards (just crosses from above) and horrible performance if you attempt to use SpeedTree for the very purpose it was created - lots of foliage. Disappointing...

 

What's just as bad as SpeedTree doesn't seem to care one way or another. They are still selling trees and waving their academy award in the air. I don't really think small developers are of any concern to them. I think they could be putting more pressure on Unity to implement them correctly.

 

Hey Guys! I understand the frustration and we hear you. Believe me, when I say that we are doing everything we can to push for more functionality to make SpeedTree+Unity the amazing combination that it can be we mean it. Yao can speak more to where the integration is and there are some improvements slated for March on the Unity Roadmap, but to say that we don't care about small developers is simply not true. We're very excited for what we have in store for 2016!

 

Thank you for your reply, that's great to hear, it is! And I apologize for being jerky like that. What I meant was that your (SpeedTree's) involvement in much higher profile pursuits is visible. Your daily interaction with Unity about them supporting your product or sympathy for those who have invested in it, not so visible.

Would you be willing to provide SpeedTree's Roadmap? Or possibly some incite on what's being done or has been disused? Or what the specific challenges are? Anything really. Thanks.

 

I'm looking into speed tree, I'm reading a lot of conflicting reports about its performance , quality and potential billboarding issues.

Can anyone offer some clarification?

I'm using deferred lighting and have problems with fog and billboards with tree creator trees.

My target is desktop and console systems.

Any insight would be appreciated.

 

Speedtree is by far the best still IMHO. Quality wise and convenience at least. 5.4 should have some nice optimisations.

 

Hey thanks for the quick response.
One more question.

How does the billboarding look with fog in deferred lighting?

 

Haven't the foggiest.

 

haha very funny.

Anyone else ?

 

Guys I know that it could be talked on other forums but I haven't found reliable one.
Speedtrees should ba as a part of the terrain or simply objects ? Which option will perform better ?
I've done some tests earlier in Unity 5.2 and I found out that objects are performing way better but I found some information few days ago that Unity Terrain should be better in 5.4.
Can You give me any clue about that ?

 

Hey!

Using SpeedTree in 5.4 but the performance is not incredibly different from the other versions of unity unfortunately...

Lack of decent trees, terrain and grass, keep Unity from catching up with other engines out there.

But hey, when you are focused on mobile and little games make 50mil a week on mobile why bother with AAA gaming? Leave that for others... (Unity mentality)

Edit: Not huge improvements for the terrain either, seems like the good ol' unity terrain.

 

Hey!

I made some tests with speedtree and I have found out that since each tree is basically an object with a LOD group the FPS drops NOT due to the ms it takes to render them on the GPU (renders them at 0.9MS at 10k trees all billboards) BUT the actual batching that takes 20MS on the CPU due to dynamic batching granting me a horrible 47FPS with 10k trees, with 10k trees 'saved by batching' with a bare bones color billboard shader. (Just compare with 2013' unigine valley benchmark where all the trees are displayed).

The unity standard terrain trees are working at 700+ fps just because all the trees are added to the terrain and their billboards are combined & drawn in a few passes only and that WITHOUT GPU instancing. And that instancing shouldn't be required for a decent terrain system...

So the question is how do we solve it, since if other games by now did it there ought to be a solution that looks good and runs at 1000FPS with billboards only (not 40-50). The first thought that crossed my mind was creating a custom LOD system that uses the speedtree but when a tree becomes a billboard it should be added to a mesh that will render many of them in one go. Unfortunately unity does not provide any API to see at which LOD level the LOD group is so maybe a distance based LOD system might work? Any ideas?

PS: Unity 5.4 was used in the tests.

 

..(Making SlowTree SpeedTree again)..

Hey!

In the meantime I did some experimenting and tests in order to get some decent fps from SpeedTree. It required a new tree system.

Current Unity's performance we have:

50k SpeedTrees added to a terrain:

(7.5 FPS, 132MS on the CPU due to batching! The Billboards have everything off. Tried dyn batching on/off same bad result)

50k SpeedTrees added as objects:


(5.8 FPS, 173MS on the CPU, everything looks broken with dynamic batching on. With batching off FPS is at 3.5)

Keeping that in mind our tree system requirements are:

1. Look as good as speedtree
2. Have tree transitions
3. Run at 500FPS with 50000 speedtree trees that are at their billboard LOD
(4. Maybe have horizontal billboards?)

Since transitions are already contained within speedtree I've built the system on top of the already existing speedtree one. No need to overwork it.

So the idea:

1. Detect when the billboard LOD is enabled
2. Move the activated billboard to a particle system (or any system that combines meshes together on the CPU, particle system style) and disable it's LODGroup
3. Detect when the billboard has to become a tree again
4. Move the activated tree back to it's SpeedTree state and activate it's LODGroup

Due to the fact that we need to access data on a per-tree basis, we need to have the trees as objects and not added to the terrain. That is not very cool due to the performance implications, but with the new system those problems should be mitigated.

Ok, let's get started.

1. We need to find out when a certain LOD is enabled for a tree. There are various workarounds for that. The first one is to get the tree's billboard renderer and using 'isVisible' to detect if the LOD is active. Very cool, just that you need to have the tree on screen. That might not be desirable sometimes. But using that we can detect when the tree has been 'billboardificated' and we can add it to out list of particles and disable the LODGroup for that tree.

2. We need to find the possible current LOD even if the tree is DISABLED and we can't use 'isVisible'. I managed to do that like:
- compute distance from camera to the LODGroups's position ofseted by the LODGroups's localReference
- calculate the size of the lod in a virtual camera space so that it is always perpendicular to the view direction
- transform the virtual camera space by the camera's projection matrix so that it is in clip space
- optimization: so that we require only one matrix multiplication by the projection we will reconstruct the second position by mirroring around the x axis
- calculate the distance between the 2 vectors in clip space and divide it by 2 (since clip is [-1..1]) so we get the screen height percentage

Operations required: 1 matrix multiplication, 2 vector distances, 1 addition, 2 multiplications, 2 vector constructions. And for getting the current actual lod, we just iterate throught the LODGroup's lods and compare with the calculated screen percentage, biased with the value from the quality settings. The results are exactly the same as unity's.

Not something that we want to do every frame for every tree, of course! We'll use a coroutine and update trees over many frames in 500 - 1000 batches. And due to the fact that some of the data is unavailable we have to emulate unity's internal working to have access to it. It should be trivial to do when you have source code access.

This is the system very roughed out. Result:

50k SpeedTrees


(159 FPS, 6.3MS on the CPU, 2.5MS on the GPU)

Sorry guys, forget about the 500FPS promise . Can't be done without native access. But it's still pretty decent at 50k trees... It's actually usable!

Ok... this is the first easy part. The part 2 is having the particles use the correct billboard at different angles. The problem with that is that probably the unity's particle system won't do, at least with a default shader. That is still work in progress. Probably a personal particle-system like system should do. But, of course, less FPS is expected then due to CPU calculations, more complicated shader etc... I'll try to rig that in the shader using the standard particle system. But another workaround at the existing workaround is have the particle billboards pop out at a larger distance than the tree's standard billboardification distance (if at 13% it billboards let's billboard it in our system at 10%). In that way only very distant trees will be billboardificated and the pop won't be noticeable. Of course, I hope to do it 'the right way' but I will probably need one more day or so for that. But even if we want to implement our own billboard choosing system, that brings us to the second problem.

How are the billboards oriented in the speedtree's atlas? Ow dear... SpeedTree does not give us any idea on how the billboards are orientated/layouted in the provided atlas. Emailed the SpeedTree guys and they were very kind and that provided me with some data on how to extract the UVs/image count/vertices from the billboard renderer. Since they are packed we'll also have to use a custom mesh on the particle system since the unity particle system vertical billboards won't do. Also a horizontal billboard exist there so maybe, just maybe if we rig our own system we could also support that . And due to that I am thinking that a custom system, but again that will bring the FPS further down due to the necessary CPU calculations. It is way better when done natively, that's why we all prefer the Unity team to do it.

Anyway, that is still work in progress, will not update any further on it for the moment.

Of course there is a lot of work for improvement:
1. Chose the correct billboard from the atlas based on the player's orientation
2. Add the trees to a grid system and using the 'GeometryUtility' class only update the visible terrain cells disabling the others
(in that way we can also help out unity with culling when we will discard entire grids)
... (ofc still thinking at others but those crossed my mind just now)

And ofc, if you have suggestions, improvements, existing solutions, corrections etc.. feel free to post them. Maybe we can figure out together the most optimal solution until unity will come with their own system.

But this solution is only partial, if you want a huge view distance for mesh trees the system won't help at all . That doesn't mean that you don't have to do the other speedtree optimizations required.

And if inexperienced me working at his first game managed to do that in a day and a half, Unity tech has no excuse to keep us waiting (we're waiting for about 2 years already right?) for a decent speedtree billboard solution. Especially when the job requirements sound like "10+ years AAA game development experience with multiple titles shipped on PC and/or Console" "Low level skills such as SPU / DMA / shader / assembly language knowledge" (I only have the shader/assembly language from those ). A guy with that experience and with access to unity's internals (not like I had to 'emulate' the LOD system) should get it going in a few hours and at 5x performance. I just really hope all those guys are not working on optimizing mobile pokemon games

PS: Lost in the depths of the new now deprecated forum I also rigged up a gridified grass system that used SpeedTree grass. Anyone interested on the grass subject? (Had 400k grass blades rendered at 30-40FPS)

 

Awesome research!
The only excuse i can give to unity is that since they are working on a new terrain and vegetation system, they decided to focus their attention on that , than coming up with half-solutions for the current system. Its awesome but at the same time a bit sad that you managed to improve speedtrees in half a day without access to the source code.

BTW, of course we are interested in the grass system!

 

Thanks for that info! Do you know when we should be expecting some visible results? Months is not quick enough for us, maybe weeks would do .

And for the grass system I think we'll post all the techy info when we're going to have the game forum post on the 'Work In Progress' section. But we still need some time for that, hoping that we can post it in a week or so.

 

Forgot to answer earlier! There is a thread for the new terrain and vegetation system. They said that they are working on the vegetation system at the moment, and that it will come some time in the next months. You will be able to paint anything on anything (not just grass and not only on terrain) and it will batched automatically etc.
No word at the new terrain system yet, so i wouldn't expect that for a year at least

 

Autch, months not very cool. Well it's cool that they are finally working on it, at least. But until the new terrain system we still probably have to use the current workaround for speedtree and grass.

 

@Assembler-Maze what's your plan for the 'a-mazing' work you described above? Internal-only / Asset / Open-source / ...?

 

Quoting myself here:

"First I will try to finish it in order to see all the problems that exist with it and if/how they can be mitigated in order to get the best looking result.

While I don't know if I'll make an asset (I don't think I have the time to make it work with one button click, it requires some complicated setup) or publish the code (working on some proprietary game) I will for sure make a tech post on how I managed to do it and how anyone can replicate the results."

When that will happen I do not know for sure, but it is probably something more like weeks than months

 

Hey!

Related to the foliage rendering engine, I would have a little update with some work in progress. However I am a little stuck and would like to have people share some ideas.

So, my goal was rendering 1M blades of speedtree grass on a 2kmx2km (can be extended to anything an any count) at 100+ fps.

Result:

1M grass blades, 140 FPS, 60 meter view distance, 10 meter shadow drawing distance, 0.5 density. (GTX 970 video card)

Update:

(with thicker clumps you can't even see the ground and still have a decent 70FPS)

Of course we can set those values at something lower (40-50meter) on older video cards to get a decent fps. Since the grass is not the only thing in the scene, there are also trees and other stuff and we must keep the grass only computation at something less than 10MS. The grass presented above is only 'fill grass'.

For ultra settings like 90 meter view distance the FPS is at something around 50.

Technique: divide terrain into cells, see which cells are visible and render the grass with 'Graphics.DrawMesh' if it is visible in a cell and within range.

Yea, that is the dreaded grass circle around the player but that can be mitigated by having some grass that is not in the system, some bushes, trees etc. in the distance to make the effect less noticeable.

The problems are:
1. Wind animation, all the grass is still due to the fact that we use 'Graphics.DrawMesh'. The grass are not objects and therefore their wind animation is not updated
2. There is some kind of workaround but it doesn't always work for all grass types (a mystery for me) is using the prefab's shared material and have some grass that animates always visible. In that way the material is updated and we can use it for the other grasses. But it is highly unreliable
3. Cannot use object instances which would be the best solution imo (we could also calculate player interaction with instances). Why? Because even though we had manually culling in unity we CANT tell unity to NOT CULL IT AGAIN. So even if we nicely did some very smart manual culling and updated the positions of objects unity will perform CULLING AGAIN on all objects that cost and extra 10 milliseconds on the CPU which is out of the question.

Again, why is not Unity open-source like unreal? Do we have to wait an extra 10 years for something that minor like disabling culling for some objects again? That if we'll ever have that feature.

So before making the post with all the detailed explanations I would require help with some issues so that I can get the system working properly.

1. How could we use 'Graphics.DrawMesh' to draw animated speedtrees?
2. How could we disabled ANY culling on gameobject instances?
(3. Final solution, but I don't want to move in this direction, is creating a custom internal shader for grass animation but that would greatly diminish quality since we can't use any parameters received from speedtree. And speetree has some awesome wind editing stuff that I do not want to lose...)

Answering any of the above questions would solve the issues. If we get an answer to 1 the problem is that we can't calculate player interaction. If we can get an answer for 2 we can also calculate the extra player interaction.

Should we also contact unity for further help? But I would not like to wait an extra year or month just to have something that disables culling per prefab/object.

Thanks a lot and waiting for ideas!

Update:
I've also contacted unity with a 'technical inquiry' related to this. Standing by for a response.

 

Bump

 

hi there,

that is more or less the way the built in terrain engine handles and renders grass.
it is even a bit more "advanced" as it creates new grass patches procedurally when they are needed in order to minimize memory usage. unfortunately this is neither done multithreaded or split over several frames so you will get some hick ups on the cpu when huge chunks have to be generated.

i do not think that any of your points need to be addressed to create awesome looking, bending, interactive and performant grass.
all you need are proper grass meshes with baked bending information (vertex colors, uvs), the right global inputs like wind and interaction (position, strength, direction) and finally a nice shader which handles all this.
speedtrees are pretty heavy when it comes to vertex count, not to mention that each vertex is rather fat. and it seems that they need some work on the cpu done per instance – which of course for grass is just a no go.