There are a couple of minor things in VS that could be improved by some of the new graphics api’s, but for the most part it’s already doing stuff right.
Hybrid Renderer V2 has potential but also a lot of problems. We are still undecided on whether we will use it or BatchRendererGroup directly at release. And are gambling a bit on if either will be ready a year from now. DOTS rendering hasnt’ been a smooth ride so far.
Unity’s default terrain+foliage+tree combo has been utter rubbish for several years and seems nobody at the company is willing to touch that mess. So we are left juggling asset-store solutions, DIY solutions, or waiting for their miraculous new (old) tech that is forever two years away.
From my experience, I can only guess (because the terrain system is one of the most opaque of Unity’s black boxes - even getting staff to spill the beans on its inner working is rare) that the CPU problems are caused by shoddly-written single-threaded code for culling and redundantly setting the plethora of material parameters used by the terrain and its brethen.
Basically, the terrain was written for a time when PCs, consoles and mobiles were so weak you wouldn’t notice its CPU cost because your game would struggle with everything else. Time passed, but it was never modernized to scale. Just like ports of very old games for modern consoles need to be re-factored to run well (examples: Ion Fury, Turok), code designed to deal with N things ten years ago often won’t magically be able to handle N^2 things on newer hardware as is.
It looks like the function/method PerpareSceneCullingParameters is one of the performance bottlenecks. Maybe a conversion on how it works to multi-threading (with a dash of Burst optimisation) would be enough as an interim solution without having to go full DOTS?
Someone at Unity needs to bother first. But they hate working on existing code and prefer shiny new things, so the terrain/foliage/trees trio will remain unofficially deprecated until they bring their new terrain which I bet $5 bucks will only work with SRP/ECS, be experimental for two years, and miss some fundamental feature or two.
My advice? Forget the terrain trees and see if one of the myriad asset store replacements suit your needs.
Unfortunately not, either I read it here in the forum or in one of the Unity now videos. I think Unity will only use the heigtmap / mesh part of the terrain.
Currently there is VegetationStudioPro if you need something off the shelf right now that uses Jobs/Burst to procedurally place as much foliage you want with great performance. Its has its own LOD & Culling system. Worth looking into.
Without it specifically going into detail about foliage, roads and cities it could just be referring to the improvements in the terrain generation tools (the demo only shows terrain manipulation).
The thing is the current system could probably be fixed to work with more foliage and quite quickly.
Let’s hope Foliage is not the new Prefabs (what everyone wants to see working in the engine but not a fancy and new enough project to excite the developers).
Wasn’t sure if you saw my posts in World Building forums. But Unity trees can already handle millions of trees if they are set through billboard renderer. And tens of thousands when using custom imposters . I am also quite keen to wait and see what comes up with Environment System as well but from talks slides only saw empty landscapes there without trees, so not sure if trees will be there. What would be good if trees would be written in DOTS would be C# approach which would allow us to better customise these…
I am GPU-instancing around 900 million Creosote-bushes for my WebGL-game at 60 fps with custom jobs-based occlusion culling. It was not that hard to set up either except the calculations for how to set the density/spread of the shrubberies. (And I forgot about shader upwarmings but I know about it now…)