Official World Building Public Roadmap and Feature Requests

Can we have some better tools for in-editor modeling? Probuilder is very limited.

 

I find the new features and improvements presented in the roadmap impressive. Will these improvements be for unity 2023.2?

A list of some things I would like to see in world building/terrain tools: https://forum.unity.com/threads/imp...ke-to-see-made-to-the-terrain-system.1362709/

 

Very cool stuff!

I'm very interested in the rendering one and non-destructive workflows.
Would this tool be only working with layers (which is already great) or will it also work with a graph?

In any case, thank you for sharing this with us, I'm happy to see improvement in the worldbuilding part of Unity.

 

Glad to see the roadmap being updated!
Personally, I am unable to use terrain due to bad performance on Android. It has a huge amount of draw calls.
I have to use terrain-to-mesh tools in order to run it properly for standalone VR games, which is a bummer.

 

I hope scattering and instancing will work on regular meshes too

 

I would like to see unity solutions for float accuracy on large worlds. Maybe it is the responsibility of another team/system, like the future DOTS streaming system, but currently all monobehaviour solutions have very significant drawbacks, like breaking static batching when moving the whole world, huge impact on physics performance when moving rigid bodies on origin change., etc.

It would also be interesting to improve the tree system and details, as well as object placement on terrain. For example, the fact that trees cannot be normal gameobjects (or be converted when the player approaches) with more components is something that every unity user has asked for at some point.

What would be incredible is that somehow you could decouple terrain authoring from terrain managment. In fact, having an option to bake it into a mesh would save people a lot of time until "terrain managment/optimizations" are developed further. Right now, if you don't buy/build that tools to convert the terrain into a mesh, you are tied to unity terrain lod system, unity terrain shaders... Which wouldn't be a real problem if they performed well on mobile platforms, but that's not the case so most of the time you have to rely on packages like: https://github.com/jinsek/MightyTerrainMesh

And last, but not least, please take a look at all annoying errors and warnings especially when using the new terrain tools like: https://forum.unity.com/threads/unity-terrain-detail-mesh-warning-atlas-uncompressed.1410336/ which may have a solution, but there is 0 documentation on those warnings.

 

i hope the old threads about ProBuilder are also checked, many have good suggestions/complaints
https://www.google.com/search?q=site:unity.com+probuilder+feedback
(there were some others, but haven't bookmarked them)

 

Hey Eric, cool to see you over here in world building now and thanks for this post. A couple of questions, does submitting the "How Important Is this to you" helpful?

In the "Non-destructive" car, there is "A mask based scattering system with occlusion making". Does that mean procedural terrain detail/tree placement? I just don't want to submit another idea if it is already covered by that.
Also, that UI for it in the screenshot looks lovely! (Even if a bit 'un-Unity'. But it is pretty, so I will accept it )

 

Will that be node based?

 

Things that Unity's terrain system lacks (from the most important to the least important):

- Performance
- The terrain system shouldn't require dozens of GBs of memory to create a world.
- A button to delete a terrain GO and the terrain file with one click.
- Layer-based system for the terrain creation (layers with heightmaps, splatmaps, and maybe layers with specific modifiers, like a possibility to mask out a part of the terrain that needs water erosion)
- Units for stuff like rising the terrain must be independent of the max height setting.
- Possibility to add more materials per terrain. An easy way to deal with stuff like biomes.
- Possibility to set up which grass, trees, and other assets are supposed to go on a certain material. The expected outcome is that I will paint a "green" texture, and the grass and trees will spawn automatically. With the possibility to select different variants based on some data (like heightmap, maybe some custom texture like the temperature map).
- Possibility to set up automatic painting based on the height map (and other custom maps?). I want to instantly see a "rock" texture on a slope by using only the "Raise or Lower Terrain" tool.
- Possibility to increase/decrease the maximum terrain height without breaking too much.
- I don't want to start editing the terrain at the bottom, but in the middle.
- Something similar to Unreal's "procedural content generation".
- Possibility to increase the size of the terrain without dealing with technical problems.
- Procedural creation of the terrain with some node-based toolkit.
- Multi editing of the terrain objects (I think there is a workaround for this in the terrain toolkit package)
- Shortcut for hiding the paintbrush (to see what's going on with the terrain).
- Maybe possibility to develop different types of terrain (3D terrain, sphere terrain, breakable terrain, low-poly terrain, etc.) without needing to recreate the default toolkit.

 

I was thinking Unity have been ralready working on these roadmap items and they will be ready to release soon. However, as I see roadmaps are just being created. Unity lacks a good terrain system for a long time. When all these will be released? 2025? Dissapointing.....

 

I don't think Unity is serious about worldbuilding. It is very important for faster workflows. Unreal is so ahead in this dir. Unity is just stuck with maintaining multiple render pipelines.

 

As far as I remember, there were attempts to do worldbuilding via DOTS, there is the terrain toolkit, some minor updates to the existing system, and splines. Now they are working on Shadergraph integration. You could also argue that cloud and water systems for the HDRP are related to worldbuilding.

I don't think there is a lack of commitment but rather a typical mess for this company.

Almost all terrain-related tasks are "under consideration" suggesting no one is actively working on these features. Possibly they have put on hold some packages due to the current situation at Unity.

All of this should mean that, as of right now, the team is only working on the shader graph integration.

 

Gosh, I waited for some kind of such topic for a while. We have a lot of decent systems right now, but let me be clear, terrain system and vegetation placement got stuck in Unity 5 at best.

After Using Microsplat and Vegetation Studio for ages, boy there are a LOT of systems that I would like to see some day.

• Triplanar UV shader, steep surfaces should be treated well in visual aspect

• Splatmaps and Heightmaps names that speak for itself, as well as blending options like Height based

• Proper PBR implementation. I think current PBR maps are somewhat lacks in terms of explanation for newbies, and requirements to make mask, I understand that 3rd party tools doing it's job, but we are speaking about built-in solution, so either make tool that merging maps or make separation for each texture slot

• Distance rescaling & Anti-tilling measures, this needs like fresh air, especially for big world where you see pretty far away and grass rendering stops at certain distance

• Procedural tool: I'm not familiar with it, but would be nice to do some kind of rules where you can put textures (angle, steepness etc.) same for vegetation per texture or using 3d mask with certain rule

• Terrain blending, ability to blend lower tips of models with terrain is not only crucial feature, but also immersion helper in terms of fidelity

• Terrain sewing, this one is not so popular, but certain artists can feel my pain, when you accidentally broke the height between two or more terrains, you can't "sew" it and you will left with gaps between terrains, technically they are connected, but height will be different.

• Tessellation, this thingy, one of the most important, if not the most important. Ability to make tessellation based on height maps or other system needs like fresh air now.

• Vegetation placement. I'll be straightforward, in HDRP it's just rip and tear, you just cannot place vegetation using built-in system, it doesn't have frustum culling, you cannot set distance for shadows per LOD group, overall system is outdated and should be re-made from ground up using new systems involving DOTS or similar. Instanced indirect (even though it's not even supported in base Unity, is not enough for this kind of task)
Again, we are speaking about built-in vegetation placement, not prefab or mesh combining and other hacks.

• Exact same for detail system & grass placement both are not optimized to use in full-fledged way.

• Ability to edit each tree placement manually: when you place trees on steep angles, it's really needed to edit it manually.

• Better system to spray grass across hilly environment (model grass, not sprite one) like Blanket shader or similar

• Overall optimizations for terrain, there is a reason why people almost instantly swaping from terrain to model, yes, base terrain eats quite a bit of resources.


Asset Store is full of assets that are more or less fulfilling those points, but having same features in base Unity would be blessing from heavens, no more fiddling with Discord channels, why N thingy is not working and why N thingy has memory leaks.

 

Thank you Eric for getting this conversation started. The terrain tools have been in quite a dusty corner of Unity's tools and features for a while, and I think a lot of this is long overdue.

Terrain Tools need a UI
One thing I didn't see specifically mentioned and that I'm surprised there hasn't been more talk about is...why is there no dedicated user interface for the terrain tools that makes switching between modes more efficient and user-friendly?

ProBuilder has an entry in the roadmap. This looks really nice:

Polytools has this:

Terrain tools have....a component in the inspector.


Having to select the most commonly used tools from a dropdown menu is slow and cumbersome. Especially switching between different sculpting tools and painting terrain textures.

Options for placing objects could be improved.

Paint details with LOD error
I remember also not being able to paint prefabs with LODs, it just threw an error about it not supporting it. Rather than throwing an error, couldn't the prefab still be used, just ignoring the LODs (or choosing an LOD), rather than needing another asset? [1]

Blending objects with terrain:
I'm hoping that the currently in progress Shader Graph Integration will make this easier. I'm really in need of this now. I've seen some techniques involving a render texture that has its drawbacks, and the other option I see is using MicroSplat.

Please keep up the communication!
I know you do not want to give specific timelines, but having a general idea of what's actually on its way is helpful. I have a sense of the terrain tools being neglected. Some of these features, like many in the link jalbastefan828 posted, have been requested for many years now. The allowing more than 8 layers comes to mind. It would be nice to know if any of this is ever coming.

Any general ETA on the Shader Graph Integration? This seems like it's been in progress for a while and I was thinking it might be out soon?

 

Actually, my hopes on you guys, don't let us down. I was considering switching to Unreal due to the amount of terrain tools built-in, but I might wait a little bit more.

 

Worldbuilding was already under the status "In Progress" in the roadmap, and that was for quite a while. It was recently downgraded to "Under Consideration". They even skipped Planned, down 2 tiers.
If you want an honest answer, you can even get it from Unity itself. So what does Unity say about the status "Under Consideration":
"we have noted this is an important topic for which some of you need solutions, but we are still collecting data and have not planned to build solutions for it yet."

And stuff like that, even though the terrain tool was pretty much the same in Unity 5 about 7 years ago. Even the few new features in the package manager were just a joke and some prankster came up with the idea of making the already bad UX when selecting brushes via a drop-down menu even worse by packing the additional brushes into sub-menus has. When I think about it again and again, I don't know whether to laugh or cry.
The bad thing is I'm only talking about terrain tools.

 

Is it though? As far as I know, Shadergraph can output to a render texture, and to generate a quality Heightmap / Splatmap a user would need 5-10 additional nodes. Creating an infinite world can be worked around by swapping render textures.

It feels more like a matter of making sure various parts of the engine can work together.

I feel like scattering should also be done via visual scripting. I know the tech isn't ready for that right now, but from what I understand, these features wouldn't come in years anyway.

 

I have an idea that basically serves as a bridging technology to counteract the perceived long development times. Why don't you create plugins for the big tools like Maya and Blender, where you can build your terrain there with the resources available there and then offer a possibility for a real exporter to Unity. I work in Blender and can create the heights, but later I have to output them in a certain format that Unity does not support. I have to open this image in Photoshop beforehand and export it to the format allowed by Unity (16bit BW). Only then can you import it into Unity. So, with the textures there is no more possibility!

I installed Unreal as a test and saw how they solve it. Well, with them you don't need any third-party tools anymore. However, they also allow, for example, 16-bit BW PNGs to be imported for the height maps. Where's the logic? You have a full-fledged importer system for all imaginable file formats and do not allow importing pngs for the height maps.
You have many types of brushes, but build them nested drop-down menus and make them virtually unusable for artists.
You can import elevation maps, but only some special format for terrain tools. Why not PNG? So simple means and you destroy possibilities that just have to be unlocked.

And again, I'm only talking about the terrain system and I could list a dozen other things that are even more absurd on the terrain system alone. At Unity you only need a professional UX designer. There are heaps of small things inconsistently scattered throughout the Unity Editor and will never change because hardly anyone reports anything like that.
You have so much unused potential lying around and you don't even know it

 

A new terrain system should:

Be fundamentally designed for streaming
This would require things like camera relative rendering, large world precision fixes (doubles or floating origin), objects associated with the terrain being bucketed for loading with that terrain, support for near/far distance object loading for hero objects to appear in the distance, etc.

Use Better formats
The current texture formats used are really bloated and cannot easily be compressed. Additionally, the techniques themselves (1 splat map for every 4 textures) are wasteful when going into high material counts. For instance, an index/weightmap can support 256 terrain types in one image. Texture Arrays or Bindless support is needed to open up the amount of terrain types as well.
Further, the current prefab system is not suitable for large worlds. Currently the system serializes the full object representation per instance in the scene file. This is incredibly wasteful when 99% of the instances will just be a standard prefab. So the system will need a way to serialize light weight instances with only the override data.

Be fundamentally scriptable with an open API, as well as be entirely in C# as a package
The current terrain system makes lots of assumptions, and new features continue to get worse in this regard. For instance, Terrain Layers assume that only the textures needed for Unity's shader are ever needed, when more advanced shaders make use of additional textures. This basically means we have to convert to/from terrain layers, but still have our own structure to store all the additional textures and parameters we support. Terrain also assumes things like my splat map format, etc.
Don't hide things via internal classes and such as new unity features are so prone to do. We just end up having to hack into everything anyway, and it's a giant PITA for your users.

Sane APIs
The current terrain has some terrible APIs, such as setting detail data as an int[,] when it's really a byte worth of data. All APIs should support things like Span<T>, NativeArray<T>, etc. And please fix the current ones, because there's no way we're not using the Unity terrain for at least 5 more years.
Also please optimize these calls. I can entirely recreate the world in MicroVerse from scratch - generating all height maps, splat maps, tree's, details, spline paths, etc, on 64 terrains with 1k height and splat map resolution in 6ms, only to have setting that data on the Unity terrains take 150ms and another 200ms per terrain to sync the height map data (which I amortize to not do more than a few per frame). I don't know what you're doing in those calls, but it's just insanely slow. Replacing the Terrain renderer with my own proxy renderer removes almost all of this time, but fully replacing the unity terrain system just because the API sucks is a ton of work and compatibility nightmare for users.

Use a virtual texture system to cache the shading inputs
The system should cache shading data into a virtual texture system, which can be easily accessed by externals for things like terrain blending. The layout of that data should be defined by the shader on the terrain or other easily scriptable way, much the way the current system can define the base map texture formats and resolutions inside the shader. Different shaders may need different layouts - for instance, some might want fully lit and shaded values written into virtual textures, while others might want to write the inputs to the PBR equation to those buffers, or custom data (height, porosity, flow, etc) which are then used for dynamic effects in the final shading. So essentially one shader to cache values, another for the final rendering, as that allows for dynamic effects to not invalidate the virtual texture.

Consider doing final shading in screen space
Rasterizing the final shading in screen space can eliminate micro triangle issues, which are a primary source of performance on terrain. Basically, because the topology is a height field, it's easy to LOD, meaning a 'mini-nanite' style renderer is fairly straight forward to do on terrains. In some previous projects I've seen 3x-4x gains from doing this.

 

a few more I forgot:

Tessellation/Physics
Tessellation should be handled in a way which is compatible with the physics engine, rather than via shaders. To avoid having to run the shaders on the CPU, the height data should be baked out into the virtual texture and read back in for terrain modification in the near field. This likely means no dynamic height map displacement which affects physics being possible in the dynamic part of the shader but, sure, that seems fine.

Runtime/Edit Time split
The current terrain engine makes lots of sacrifices because it assumes anything could change at runtime. And while I think runtime changes are very important for some users, being able to turn them off and make static assumptions for a terrain would be super useful.

No pops
Regardless of which technique used for terrain vertex LOD, it should not have pops, but favor some kind of geo-morphing instead.

Documented shaders
What every system or tooling you produce is going to be augmented by the asset store. Terrain is one of the most popular areas, and it's going to be a lot of work to convert existing products and figure out new ones. Documentation or even just comments on what those shader keywords do, etc, would be super useful.

Mobile
A lot of the newer techniques are not going to run well on low end devices. I don't envy the issues this is going to cause. As such, I'd expect that even if the system supports virtual texturing and some new form of tessellation, people will need to turn that off and use simpler techniques for lesser devices. One option would be to fix the current terrain system for those use cases and only cover more modern stuff with the new one. Another option would be having it run in a more traditional mode, without using visibility buffers/compute/etc..

BaseMap
The basemap optimization is an interesting case in the old terrain system- effectively poor man's virtual texturing. I do not use it in MicroSplat, because I instead use the alternative shader to swap between tessellated and non-tessellated terrain, since the cost of invoking the tessellation units is so high. So originally I thought to set it to 32x32 pixels automatically to save resources - however, other systems in Unity use it, such as GI, so you end up having to generate that data anyway. This example points out how several assumptions in the system - such as needing exactly 2 shaders switched on distance, and other systems using that base map for things without the users really knowing. These will all be even more true with virtual textures, since they will become an obvious proxy usage for terrain data that needs to be accessed externally and cheaply. So what I would suggest is to not hard code those types of assumptions- if your terrain may need multiple shaders based on distance, it might need N+1. If multiple systems might use the virtual texture for things, make sure those use cases are known/expected/generated when needed. For instance, if the layout of the virtual texture data is scriptable, perhaps systems can request certain buffers be filled out rather than pre-declared and expected. If I'm not using the diffuse texture, why generate it? And if I need to generate something custom to use later in the shading phase, I should be able to do that. For instance I might want PBR inputs + height, porosity, then shade later with that data. But your GI system might want final diffuse. In many ways, these end up like custom passes in a renderer, just for virtual texturing data.

Tree vs Detail rendering

Assuming we're sticking with 2 representations (though details could have a less bloated format, such as several indexes and weights rather than one weight map per detail object on the terrain); Tree Instances should have a Y offset value from the terrain, since the current system will read and render the position data you set just fine, then reset it to the terrain height when something in the terrain tools updates and does that. It makes sinking tree's into the ground require adjusting the pivot point of the tree, which can be a problem if you want them at multiple positions relative to the terrain. There's also missing capabilities, like terrain alignment, etc.
Users are highly confused about the differences between these two, and constantly ask me for things to work like the other one does in each system.

All data directly accessible on the GPU

Most of the terrain data ends up on the GPU, and while there are some sync back functions that accept render textures, it would be nice if all data can be accessed and adjusted directly on the GPU and then async'd back to the terrain in the background, so we don't have to go through the terrain API at all to adjust the data if we don't need physics to match right away. Further, any processing which needs to be done (such as the current LOD patch calculations, etc) should be optimized and off-main-thread to not disturb editing. We can wait for the data to appear on the terrain, but having it pause everything for 3 seconds is a non-starter for many things. Also, 70ms per 1k terrain for that height sync back is just brutal.

Meshes as Terrain
Meshes become an even bigger part of the terrain in a modern game, and making it so that various terrain systems can work with meshes kit-bashed into the terrain deserves consideration. For instance, being able to populate the vegetation/detail data across those surfaces, even if that data is still a top down projection. Terrain/mesh blending, obviously. Cliffs, caves, outcroppings, etc. World building, in general, is moving much more towards meshes than height fields - but I still think height fields are very useful - so augmenting the terrain with proper mesh tools is likely the more mainstream path.

 

@EricDziurzynski

Large worlds (64 bit/double precision) support please.



I already requested this years ago and the moderators for some reason locked the post, then @stonstad tried to continue the discussion.

Both Unreal Engine 5 and Godot now support large worlds except for Unity.

 

Need practical examples of how to manage the memory of streaming worlds. As far as I know, addressables is the current way to go. But, the garbage collector is a killer with this. What I am seeing is asynchronous loading/unloading is the way to go. But, the garbage collector just hits you when the loading is complete. Just overall better memory management.


Need a way better Navmesh and more examples. Extremely important. Unity navmesh has been neglected for how many (10+?) years now. Unless you want a big open world with nothing to do, we need to add AI to these worlds. Building navmeshes on various terrain sizes leaves too many islands where the AI has no where to go. Islands have no benefit to the navmesh and is a waste of memory. Current workflow is to spawn everything as a prefab with navmesh obstacles and hope the navmesh connects. Terribly inefficient.


Terrains. Quite a few gripes about terrain features on here. I haven’t found any cases where the actual Unity terrain is more performant than a mesh. With that said, need tools to do terrain conversion so we don’t have to spend all our time doing it ourselves. I feel like I’m spending more time building tools then the projects .

 

Rotatable terrains would be nice.

 

probuilder has the option to center the pivot, but Id rather have center bottom - can we have some pivot editing options?

 

Folders in the hierarchy. This will make management of assets in the scene easier. Overtime the hierarchy becomes a scrolling nightmare.

 

Terrain's detail renderer just needs one more step to be production ready:

support LODs or seprate culling distance for each detail object.

for now.it could only be used in some small projects not big projects,because the performance is too wasted on unneccessary far distance details.

 

Just here to beg for better support for terrain in Unity. It's so far behind competitors especially for large scale titles, that it's genuinely a detriment to the entire engine. Without @jbooth's plugins world creation is unusable for realistic and complex terrain, and the workflows in Unity are horrendously destructive as-is.

Seeing AI features pumped out while terrain is left in the proverbial dust is a pain. Our next games will currently as it stands not be using Unity, which is a shame because the engine with DOTS has so much potential via HPC#. Asset creators carry this engine which only punishes studios and asset developers who have to provide third-party support and updates, but so many other features feel underdeveloped and under-focused by management.

Sorry for the rant and I know the terrain team aren't individually responsible for direction, but it feels like an uphill battle to get modern features in Unity, that aren't just fluff that isn't production ready and is mostly intended to boost stock price.

 

Double precision would be nice. It would be awesome to be able to drive / fly, etc... for thousands of miles or kilometers without having to worry about flickering. Another thing that would be cool is increasing the max terrain height of 600 meters. Tried putting terrains that are high mountains next to each other that is beyond 600 meters height difference. Ended up putting multiple to try to close the gap. Lol.

 

Theres a free asset to do that I think

 

I would like for the feature to be built in.

 

I would love to see a CSG tool, like Realtime CSG. It was even made by a (ex?) Unity developer. The tool itself is pretty much perfect for prototyping or simple level geometry. Sadly the tool is not being updated very often and breaks with the most recent Unity versions. A official version of this tool, or something like it, would be great!

 

For a very long time now, the terrain has had a fundamental issue that could, in my understanding, be resolved without too much effort: https://forum.unity.com/threads/a-small-change-for-improved-terrain-shading-and-traversal.1481655/
It would be helpful if the terrain team acknowledged it.

 

So the Environment System that was announced years ago is dead. Instead there's now a "Non-destructive contextual workflows" tab as "Under Consideration".

Jason Booth implemented that within 1 Month, yes you read right. 1 Month did it take him. I know, because I was there from the start. And not only did he implement a layer based terrain editor, he also supports the 3 distinct Render Pipelines which is a feat on its own.

And last week he released MicroVerse Roads which is the ideal showcase for Unity's Splines.

Here's the vegetation stuff:

Here's the terrain heightmap stuff, an old version, but you see that's been a year ago and what did Unity do within that year?

Here's the road stuff:

So Feature Request: Work closely together which publishers who know their way around the engine and start listening to them.

I frankly don't see a point in the world building roadmap because whatever Unity intends to do has already been done.

 

I agree that Unity's development cycle seems rather slow, but I don't know if comparing them to publishers is fair.
Unity clearly imposes a high quality standard for their tools. They need to have a solution that is powerful, flexible, robust and consistent with the rest of the engine. It's not always perfect but most of what I've seen lately was very good.
It's not really the case with publishers. While there solutions can be good enough for a lot people it's far from being as good as something made by Unity themselves.

I also think that having a "vanilla" solution is better than only relying on tools made by publisher. It does make it a lower priority if they already exist but having something free and fully integrated in the editor is always better.

My hope is that now that DOTS is mostly finished many of the devs who worked on it can help in other parts of the engine.
That said, I don't necessarily expect to be able to test these world building tools by next year, but who knows...

 

I haven't used Microverse so I have to ask you. Has he used his terrain shader or block shaders for the terrain system?
One month sure sounds crazy fast, but I feel like he already has all the know-how and tech to implement it quickly for all 3 RP.

Unity was wasting the last few years going in circles. At first, they started a new terrain system with DOTS, then changed their mind and started upgrading the current system, now they fiddle with a terrain shader, shader graph, and render pipelines.

 

MicroVerse doesn't have a terrain shader, it's a terrain editing environment which is fully non-destructive and 100% realtime. I built it in 26 calander days, working regular hours, weekends off, and even gave a talk at a conference in Seattle during that period. No existing tech was used, though I have 30 years of game development experience making things at every scale (mobile -> mmo).

Block shaders is not available for use, just an incomplete prototype was posted a while back. I wrote Better Shaders in two weeks, though I had knowledge of the SRPs from having to deal with them for MicroSplat. Note though, that Unity has that knowledge internally and does not have to reverse engineer 60k lines of SRP shaders code like I had too.

Most of what slows large companies down is bureaucracy, a "no" culture, disempowering smart people at the company to actually do things, fear, confused vision, and an over reliance on process and consensus. MicroVerse was my largest upfront investment into an asset on the store, everything else has initially been created in shorter than 26 days. That said, I spend far more time working on my assets after they are released than I do before release.

Unity's development cycle is painfully slow because of all the reasons listed above, along with some additional ones.

They favor throwing out the baby with the bath water - if someone suggest a system be improved, they tend to replace the whole system rather than just fixing the one they have. Then they have to re-learn all the lesssons of the first system, because those people are gone or are not listened too, and they wrote something from scratch. Then the winds change and things either get canceled or started again by a new group (networking, UI). Their idiology of "never break anything" traps them into this cycle; the public API is considered sacred and they make changing it very hard, which means software stays safe from API changes, but encourages the above and also means nothing gets fixed.

They seem to want consensus on decisions - consensus isn't bad, per se, but it takes a lot of work and often makes software bland by trying to please everyone instead of just really nailing a technology. Most of the truely amazing tech is created by one or two people with an idea, not a committee.

They try to future proff too much. One of the reasons I've heard for not making a unified shader abstraction over and over is "they want to get it right", and "what about <some future tech>?". This is part of the endless ways in which an org can say no to everything. The reality is if they had spent the two weeks I had creating an abstraction layer for shaders in 2017 when they started the SRPs, we'd all have been fine this whole time. Instead, they are taking multiple years to write block shaders after 6 years of pure pain caused to the community. Switching shader languages twice would have been less pain than this.

It would be natural for Unity to take more time than someone like myself to get to launch of a new system- but we're talking hundreds of times longer than it takes me, which screams of mass inefficientcies in how they are operating.

 

Now they have also moved the only point that I expected down 2 levels to the level “UnderConsideration”. That was it for me. Even in the roadmap they don't keep their word. The topic of “worldbuilding” has also been downgraded from “In Progress” to “under consideration”. There were even some cards there. Not only does it make the “InProgress”, “Planning” and “Under Consideration” levels completely worthless. No, we now know that you can no longer believe Unity.
I'm going to Unreal. Terrain is miles ahead. Other things that Unity constantly shows off (ECS, Adaptive Probe Volumes) are also available at Unreal. They haven't even made it a big deal yet. At Unity you've probably heard nothing other than DOTS and Adaptive Probe Volumes for years.

 

It's an industry. However Unity provides awesome tools. While their world building is still long away and they're talking about layers and what not, others are painting entire biomes with Unity's Splines