Speaking for my teams and many others I’ve raised this with over the past few years…
…the most important thing SpeedTree can offer is hyper-optimized rendering of large quantities of decent looking trees in Unity games. However, the focus has seemed to be on modeling instead. We’ve been using home-grown or 3rd party assets to do things like instanced indirect rendering with GameObject-less workflows in order to render forests and large worlds with SpeedTree assets in them. This is painful and has high maintenance costs and poor editor integration for tech artists.
Why isn’t this already what SpeedTree does? Isn’t the entire point to support trees in realtime, 3d, Unity games?
Ever since the acquisition by Unity, it seems that SpeedTree has retreated from its roots as a high performance rendering solution into the relative safety of just being a niche modeling package for vegetation. That was never the most interesting aspect of SpeedTree.
It’s the name itself since the beginning: SPEED tree. But for a few years now, the “Speed” part of the name seems to have been abandoned and has stagnated.
Is there a roadmap for modern approaches to rendering vast numbers of decent looking SpeedTrees in Unity 6+ now, or has SpeedTree fully made the transition to just being a modeling solution and little else?
For what it’s worth, a LOT of the market does NOT want to model trees at all. We want to simply purchase good looking, highly performant trees from your store, drop a million of them onto our terrains, and then press play. Most SpeedTree releases for a while now have been all about yet more hyper niche vegetation modeling features - very frustrating.
Any feedback anyone can provide about whether this is the future or not would be appreciated.
We’ve always said that SpeedTree makes both creating AND rendering trees fast. So yes, the Modeling tools have advanced. We’ve added new features like photogrammetry workflows, free hand brushes, and of course the whole new modern interface in SpeedTree 10. But we’ve also added features that help game performance as well, such as shade pruning, mesh packing, and better cluster creation using cameras.
If you just want to purchase trees instead of create them, then you absolutely can. We release new trees all the time on our store at https://store.speedtree.com/speedtree-store/
But I’ll have to apologize that perhaps we haven’t touted our advances inside Unity enough. If you take a look through the release notes, you’ll see SpeedTree comes up a good bit. In addition to bug fixes, performance has improved in a number of areas, such as in terrain batching and the GPU resident drawer. This work will continue.
As for roadmap, if you caught the video during this year’s Unite, you might have seen the new Worldbuilding system. SpeedTrees will absolutely work with this, providing fast creation and rendering of expansive worlds.
And if you haven’t seen our introduction to Rules, a new feature in SpeedTree 10, be sure to check that out. Rules are a way for trees to have a simplified editing interface so you don’t need to be an expert at SpeedTree to tweak a tree in certain ways. We’re building a library of these rule-powered trees, and you should expect to see rule editing on SpeedTrees start popping up in more places.
Thanks for taking the time to reply! It’s good to hear that perf is a priority. I haven’t yet tried SpeedTrees under GPU Resident Drawer so maybe there is some goodness there. I will experiment with that soon.
@Claytonious how were you able to get gpu instancing to work with speed tree? when we use the speed tree 9 shader with our instancing setup and drawmeshinstancedindirect, the trees render as expected, but the wind doesnt work. were you able to get it to work with wind?
it seems that the speed tree 9 wind relies on the renderer having a “tree” component in unity. this really sucks cause when you look at past forums, it seems that the plan for speed tree 9 was to be more gpu driven (source). hopefully it can be looked into further in the future…
I haven’t noticed any improvement while using gpu resident drawer in Unity 6 with speedtree assets or with any tree meshes in general. Seems the gpu drawer instancing is working only on game objects, so terrain instanced trees are ignored by the new instancing. Indirect instancing with vegetation studio pro or other assets remains the best way of handling vegetation.
I think there’s a fundamental disconnect here between the SpeedTree product owners and the community. I think you’re describing an approach where your SpeedTrees are “just another 3D mesh that gets rendered by Unity, so it will speed up gradually over the years as Unity gets faster at rendering things generally, and of course we will make targetted efficiency improvements here and there like any other provider of assets would, such as this” - so you would rely on generalized improvements like GPU Resident Drawer to be able to render forests on mid-range devices someday in the future, whenever that day may or may not arrive, based on general Unity rendering progress.
On the other side, large parts of the community are clamoring for a different strategy specifically for trees and vegetation, which does not settle for treating them like other commoditized visuals, but which acknowledges that the problem of rendering millions of instances of animated trees to get a great forest is a very different problem from most other rendering needs in a game. Thus, solutions like Foliage Renderer and GPU Instancer (with specific support for SpeedTrees) and many others are born. Some of these work amazingly well to a point, but they are all hobbled by having to do the best they can without core engine support.
We keep thinking you guys should offer something like this “out of the box”, which seemed like the core mission of SpeedTree. But you guys keep hearing something more like “please make rendering my dozen hero trees in a garden scene faster”, or something. There is some basic disconnect where the message never seems to make it from the community to you, and we end up with a small set of micro-focused optimizations for individual tree rendering in the release notes here and there and “new procedural bark pattern editing!” instead of “render vast forests in your game at high FPS”.
We want “render vast forests in your game at high FPS”.