Feedback Does this version support HDRP detail?

Before, I couldn't understand why this was such a difficult problem.
I only predict that they are probably making something similar to the procedural placement of Horizon Zero Dawn.

And I heard about storage to VRAM.
Perhaps, if foliage and detail culling and LOD streaming can be done without going through the system memory, you can guess that there is a serious problem with the current structure.
But, I hope it's not too late. This is because the terrain and foliage are too difficult to self-create and too important to be removed.


I think the quad overdraw debug mode would be very useful. With most of the bottlenecks disappearing in DOTS, the quad overdraw became the most important load.
For the time being, I'm going to stick with Adaptive Tessellation, but I'd like to have a blueprint for the mesh shader pipeline before that.

As the technical difficulty increases, it becomes increasingly difficult to convince executives of why this is a necessary feature. Is there any good way.

 

Unity is working on few separated things related to this:

1) Virtual Texturing is scheduled to get procedural virtual texturing support in 2021. This is something that's been used a lot in the industry already for terrain texturing, especially in Ubisoft's games (Far Cry etc). You can find a lot of technical talks on this topic if you just search around.

2) There's a new environment system in the works. There's no guarantees this will land during 2021 as it's been supposed to get out for years now.

3) DOTS will make proc gen stuff faster, especially with Burst and Jobs but I wouldn't go as far as saying it would make existing bottlenecks go away. If you use DOTS today, it actually introduces bunch of bottlenecks on it's own that didn't exist before and if you use it on typical game levels today, you are likely to get even worse performance today vs without it. Where DOTS shines today is really brute force computations but it's not trivial to make these gains help you on generic game x.

As for tessellation and HDRP, for some reason Unity doesn't want to support it in shader graphs. It's always been technically possible to implement but it hasn't clearly been any kind of priority for Unity. If you need this type of functionality, you have to go to 3rd party paid solution and use Amplify Shader Editor which does support tessellation on all renderers (built-in, URP and HDRP).

 

That's interesting. Please elaborate.

 

It mainly boils down on how job system works today. It has overhead and it gets increasingly inefficient the more cores your cpu has. I have "only" 12 core / 24 hw thread cpu, meaning Unity job system will by default setup main + 23 worker threads for the job system. This doesn't really work well at all on typical game levels even if you only use DOTS physics and hybrid rendering v2. Both of these will run that typical use case level fastest when you manually limit job system to use 0-6 workers max, depending on the system and level. Do note that I'm now mainly talking about DOTS framework / packages here on it's own and not about any custom ECS code you'd need for the gameplay itself.

I'm not kidding here even, sometimes you get best performance if you omit the job system workers fully. This of course means you will not get much cpu utilization either as most of your cpu cores are just sitting idle there. This is something Unity definitely needs to improve as now if you just let the job system to use the amount of worker threads it wants by default, your game will run slower and draw more power as you just waste the cpu cycles for nothing.

In addition, even when I manually dial the worker amount to be all around the fastest option at the given time, the typical gameplay levels (for cases that matter for me and what I've tested this with) STILL run tad slower with hybrid rendering v2 with HDRP than with traditional gameobject based rendering setup with HDRP.

DOTS physics itself is multiple times slower than built-in physx if you need bigger level with high physics update rate. DOTS just choked on these iterations on my previous testing where physx still performs nicely. I believe this is partly due to poor job system performance explained above but also due to lack of cache since Unity Physics package is stateless and doesn't get perf gains from certain optimizations that are only possible with caching. That being said, there's always Havok option if you need this and there are other gains from stateless physics engine so I can't really fault Unity too much from the physics part but it's definitely something people should test against as well.

One thing that could definitely see helping here in the future is if Unity will allow their job system to schedule jobs in parallel only to select number of workers per schedule/system. Right now the splitting across all workers seem to hurt a lot but I could still see gains on being able to schedule jobs for more than few workers total, just hope we will be able to limit these per systems somehow. Today your option is to just limit the worker amount globabally, meaning you cap the worker amount for all systems at once and not per system.

 

Ok thanks. It's interesting to read about production situation.