starting simple performance tests on my local computer I mentioned some performance differences concerning trees with Unity 2.5.1:
Rendering “hand placed” Mesh Trees is about 10% faster than using Unity’s terrain engine to render trees.
Using a root node for all “hand placed” trees and Unity’s simple “CombineChildren” with deleting original trees after generating new “combined trees” the cardinality of Draw Calls will be about 10% lower but the FPS the same as in 1.
Conclusion:
As far as I know Unity’s terrain engine draws trees on my computer group wise in about 4 trees in 1 group. PerfHUD is your friend. Using “hand placed” trees you are able to draw all trees with more FPS than terrain’s tree engine. Using “CombineChildren” with some modification to delete original meshes that will be combined and so avoiding drawing trees twice you also gain the possibility to draw all trees with only 1 Draw Call.
I underline that this behaviour is on my computer, I don’t know whether the same happens on other computer too.
So my question and discussion to you is:
Is this behaviour generally applicable?
Who has made different experiences with Unity’s terrain engine placing trees?
Only if you only have a few because the integrated terrain system has a few unique benefits like auto billboarding and the ambient occlusion which helps with the lighting etc
also the hit on the performance is more or less a 1 time hit, adding more trees requires a lot of trees do degrade the performance furhter.
Its the shader thats beeing used that causes the hit.
thats to expect. combining them blindly will result in many trees sent to renderer although they are not even in view frustrum, just because a single tree / the bounding box is.
Right…a few trees or 100,000 trees will be about the same speed and take about the same memory using the terrain system, whereas 100,000 hand-placed and combined trees would be a slideshow and take far more memory. (Not to mention you’d hit the 65,536 vertex limit relatively quickly and would need many draw calls.)
OTEE doesn’t exist. And there’s nothing for UT to look into; terrain trees work pretty optimally.
not really.
the initial hit is the cost of having high class visual quality on the trees. if you don’t like it, don’t use the ambient occlusion shaders on the trees
@dreamora
Yes, this simple test was made with a few trees. That’s an important fact I have not metioned. Sorry for that.
@Eric5h5
Memory consumption I have not treated. I don’t know how far you can rely on Unity’s “Stats” Window. The FPS Counter is definitely not correct as mentioned in this forum before.
What happens if you handle “placed trees” in groups divided them space-wise? That means not having a root node for all trees, but having many root nodes for smaller groups. Expects from the memory consumption I think that is the same effect the terrain engine uses? The drawback is that you have as many Draw Calls as groups on screen.
on windows, fps measuring is simple: FRAPS
can’t get any better as it uses the real dx flipchain switches (and with a logitech g15 keyboard you have a live graph of the past xx seconds)
and no even if you group them area wise you will still lose a lot of performance.
your models will remain models even if 1000 units away.
Unity trees become billboards either when too far away or if they are closer but more trees are beeing rendered than you allowed in full details and a billboard with 2 triangles will always be significantly faster than a tree with 500 polys
additionally you have the draw calls that you need to fight.
also, the performance hit of the terrain system won’t raise if you additionally drop detail objects / grass in, something you can totally skip with your approach
I have perceived the performance and optimization of Unity’s terrain engine. But I dont know I can use this for my Use Case making trees transparent if character is behind them. With TerrainData I can access all needed data but how efficient is this approach?
in that case you would potentially run into problems, thats right.
question is what camera perspective do you have? do you use a 3rd person iso alike camera that you need the transparency?
In that case single model trees for example will work easily (you would need them to be on their own otherwise you can’t make them selectively transparent)
with a 45° view its no problem to place single trees
most will never be in view frustrum, so you don’t even need the combine, because a tree thats not within the view frustrum is not beeing sent to graphic card and will neither add rendering work nor a drawcall
above things were to a high degree posted under the assumptions that you have a “flat angled cam” (FPS or follower 3d not much above head)
the only thing you need to ensure is that the cam does not go away too far or you might have to implement your own imposter (rendering trees to textures for billboard usage)
And there’s nothing for UT to look into; terrain trees work pretty optimally.