Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only.

    Please, do not make any changes to your username or email addresses at id.unity.com during this transition time.

    It's still possible to reply to existing private message conversations during the migration, but any new replies you post will be missing after the main migration is complete. We'll do our best to migrate these messages in a follow-up step.

    On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live.


    Read our full announcement for more information and let us know if you have any questions.

Official World Building Public Roadmap and Feature Requests

Discussion in 'World Building' started by EricDziurzynski, May 16, 2023.

  1. EricDziurzynski

    EricDziurzynski

    Unity Technologies

    Joined:
    Mar 11, 2022
    Posts:
    53
    We want to hear from you about what you need from Unity most to succeed when building large, open world experiences in Unity!

    We do our best to manage the public world building roadmap in terms of publicly showcasing what features and technology we are considering and have recently added some cards here. If you have any feedback on the specific features on the World Building roadmap, please do add it there as those cards are tied to features in our backlog and this is the most efficient way to route your feedback to ensure it doesn't get lost. You just need to be logged in with your Unity ID to do so.

    If you don't see a specific feature, or want to request something that isn't yet listed, please add this to the 'submit new idea' card. Much of the time your feedback gets added to features in the backlog that just aren't shown publicly.

    If you have more specific questions or want to start a dialogue about feature requests, please add to this thread and I'll do my best to monitor and respond in a timely manner. I'm also available for direct messages or dialogues through the forum.
     
  2. shikhrr

    shikhrr

    Joined:
    Nov 19, 2013
    Posts:
    69
    Can we have some better tools for in-editor modeling? Probuilder is very limited.
     
  3. jalbastefan828

    jalbastefan828

    Joined:
    May 8, 2019
    Posts:
    17
    milifer and mattb-unity like this.
  4. PaulMDev

    PaulMDev

    Joined:
    Feb 19, 2019
    Posts:
    74
    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.
     
  5. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    5,251
    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.
     
  6. Onigiri

    Onigiri

    Joined:
    Aug 10, 2014
    Posts:
    505
    I hope scattering and instancing will work on regular meshes too
     
  7. EricDziurzynski

    EricDziurzynski

    Unity Technologies

    Joined:
    Mar 11, 2022
    Posts:
    53
    @shikhrr, thanks for the comment, and noted. We are definitely considering how unity can provide these types of capabilities.

    @jalbastefan828, thanks for the link and I'll respond to that thread as well. Being the Product Manager for World Building is a relatively new assignment for me so I'll be catching up on as much of the threads as I can here. Many of these features are in our backlog for consideration so all of the posts and threads do indeed help us prioritize what we work on and when.

    @PaulMDev, layers, not graphs should be expected.

    @DevDunk, noted. Android and standalone VR are tough platforms for performance and optimization for sure and we appreciate you using Unity to deploy to them. Reducing draw calls and providing tools and tech to support these platforms is definitely our intent.

    @Onigiri, noted. I will add this to our insights for scattering and instancing. Appreciate the feedback!
     
    GDevTeam and DevDunk like this.
  8. EricDziurzynski

    EricDziurzynski

    Unity Technologies

    Joined:
    Mar 11, 2022
    Posts:
    53
    Thank you to all of you that have already submitted feedback and feature requests through the roadmap! We do read and triage these!
     
    GDevTeam and DevDunk like this.
  9. AdrielCodeops

    AdrielCodeops

    Joined:
    Jul 25, 2017
    Posts:
    58
    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.
     
    Last edited: May 17, 2023
    Virishii likes this.
  10. mgear

    mgear

    Joined:
    Aug 3, 2010
    Posts:
    9,566
  11. EricDziurzynski

    EricDziurzynski

    Unity Technologies

    Joined:
    Mar 11, 2022
    Posts:
    53
    @AdrielCodeops , while it's not the team I represent, Unity does have a team looking at improving our coordinates for large open worlds in addition to a number of other improvements. This is definitely a major problem for many large open real time 3D experiences so it's something we'd like to address at Unity.

    As to the tree and detail systems and object type, thank you for the feedback. This is helpful to see and hear and certainly something we've seen and heard before as you mention. But all the feedback helps us prioritize.

    And the other aspects of terrain performance on mobile and the errors are helpful to hear as well. Thanks for raising them here.

    @mgear , we have extensive feedback for ProBuilder over the years and we definitely have it captured and look at it all, but yes, all valid for certain.
     
    GDevTeam likes this.
  12. MechaWolf99

    MechaWolf99

    Joined:
    Aug 22, 2017
    Posts:
    296
    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 :p )
     
  13. EricDziurzynski

    EricDziurzynski

    Unity Technologies

    Joined:
    Mar 11, 2022
    Posts:
    53
    Hey @MechaWolf99 , glad to be here! Yes, that would be a procedural detail and placement system. And glad you like the proposed UI. We're definitely looking at how we can make a system that is more accessible and familiar to artists coming from Substance Painter.
     
  14. Misaki_eKU

    Misaki_eKU

    Joined:
    May 3, 2018
    Posts:
    106
    Will that be node based?
     
  15. useraccount1

    useraccount1

    Joined:
    Mar 31, 2018
    Posts:
    278
    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.
     
    Last edited: May 25, 2023
    PaulMDev likes this.
  16. Gokcan

    Gokcan

    Joined:
    Aug 15, 2013
    Posts:
    289
    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.....
     
    useraccount1 likes this.
  17. shikhrr

    shikhrr

    Joined:
    Nov 19, 2013
    Posts:
    69
    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.
     
    MrBigly and pm007 like this.
  18. useraccount1

    useraccount1

    Joined:
    Mar 31, 2018
    Posts:
    278
    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.
     
    shikhrr likes this.
  19. Jack_Martison

    Jack_Martison

    Joined:
    Jun 24, 2018
    Posts:
    159
    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.
     
    Last edited: May 26, 2023
    mgear likes this.
  20. EricDziurzynski

    EricDziurzynski

    Unity Technologies

    Joined:
    Mar 11, 2022
    Posts:
    53
    Hi All,

    First off, thank you all for taking the time to provide feedback! This genuinely helps us prioritize our backlog and develop of features so that we can provide the most value in the shortest possible time.

    Just know that anything close to a feature request from last week has been logged and treated as such. @useraccount1 and @Jack_Martison , thank you in particular for the detailed lists and prioritized requests. At a high level, I think you both will be very pleased with our current plans if you can be patient enough to wait for their release.

    @Misaki_eKU , any procedural system planned will be layer based, not node based, however we do have more of a node based creation workflow in the backlog, just no plans to develop that as of yet. In short, the time and cost of developing a robust node graph based procedural mesh generation tool have not seemed worth the investment when much more complete tools like Gaea, Houdini, and World Machine are much more complete and capable and have been available for a long time now.

    We can't commit to a timeline yet for any release of new features, tech, or workflows, but as soon as we have a set timeframe for release we will definitely share more specifics. Our goal is to give much more accurate timeframes for feature and tech releases moving forward to prevent anyone from basing their own timelines and projects on ours without confidence in our release schedules.
     
  21. jwinn

    jwinn

    Joined:
    Sep 1, 2012
    Posts:
    89
    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?
     
  22. EricDziurzynski

    EricDziurzynski

    Unity Technologies

    Joined:
    Mar 11, 2022
    Posts:
    53
    @jwinn,

    I'm involved and continuously working with the teams responsible with all of these tools and I think we all agree with your assessment 100%. As someone that did game dev for over 15 years as a Tech Artist, and eventually as a Creative Director of a 90 person development studio before coming to Unity as a Product Manager, myself and others had to constantly shift contexts and train new hires to workflows and systems and the more consistency between workflows and tools, the faster the context shifting and training becomes. I genuinely care about all of this and remember these types of pain points all too well.

    So, to that point, making the interfaces more consistent is definitely the plan but will be a bit slow. That mockup for ProBuilder would be building upon the overlays system and what was released for the Splines package. But there is still more development work, coordination across teams, and planning to be done before we can make this happen.

    The other areas you called out, shader graph integration, blending objects with terrain, painting objects, and an improved LOD system are definitely things we'd like to address as well and your feedback does really help us prioritize and provide specifics to our dev teams.

    I can't speak to any timelines yet officially for shader graph or any other terrain related features so we'll all need to just be patient (myself included) while we align across teams and can make more official announcements. What I can say is that myself and everyone on the teams I represent are all very excited for what we have planned. In the meantime, please keep the feedback and any feature requests coming!
     
    florianBrn, jwinn, saskenergy and 3 others like this.
  23. Jack_Martison

    Jack_Martison

    Joined:
    Jun 24, 2018
    Posts:
    159
    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.
     
  24. sarbiewski

    sarbiewski

    Joined:
    Sep 8, 2017
    Posts:
    27
    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.
     
    MrBigly and Lymdun like this.
  25. useraccount1

    useraccount1

    Joined:
    Mar 31, 2018
    Posts:
    278
    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.
     
  26. EricDziurzynski

    EricDziurzynski

    Unity Technologies

    Joined:
    Mar 11, 2022
    Posts:
    53
    @sarbiewski , we appreciate the feedback and we're using this thread to have a conversation around feature requests, priorities, and provide as much transparency as possible and to answer any questions we can. We've had to restructure many teams and plans in the past year in the attempts to focus our development, coordinate, and collaborate more effectively. Thankfully, the world building team and our efforts are a priority.

    While we coordinate, myself and other product managers will be holding off on many announcements regarding timing until we can do it for the entire company and product ecosystem, hence items in the under consideration section until we can say more. The current efforts had specific dependencies still in development that are now unblocked and allow us to move more quickly.

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

    Yes, exactly! And thank you for responding before I could!


    As soon as we can provide more specific timelines for releases and updates we will communicate them.
     
    saskenergy likes this.
  27. sarbiewski

    sarbiewski

    Joined:
    Sep 8, 2017
    Posts:
    27
    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
     
  28. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    5,461
    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.
     
  29. EricDziurzynski

    EricDziurzynski

    Unity Technologies

    Joined:
    Mar 11, 2022
    Posts:
    53
    @sarbiewski , thanks for the specifics in your last post. This has been logged in our feedback for DCC import pipeline in our backlog.

    @jbooth , thank you as well for the detailed and specific feedback! Will be sending this to the dev team for a look and logging all of this feedback to the appropriate backlog entries. Extremely helpful! I can say that all of the areas you touched upon are high priority for us. As an aside, we genuinely appreciate everything you do for us and our users!
     
  30. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    5,461
    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.
     
    ron-bohn, Rowlan, ontrigger and 10 others like this.
  31. alsharefeeee

    alsharefeeee

    Joined:
    Jul 6, 2013
    Posts:
    80
    @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.
     
  32. MrPapayaMan

    MrPapayaMan

    Joined:
    Feb 16, 2021
    Posts:
    43
    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 .
     
    EricDziurzynski and jwinn like this.
  33. alsharefeeee

    alsharefeeee

    Joined:
    Jul 6, 2013
    Posts:
    80
    Rotatable terrains would be nice.
     
  34. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    2,256
    probuilder has the option to center the pivot, but Id rather have center bottom - can we have some pivot editing options?
     
  35. pbritton

    pbritton

    Joined:
    Nov 14, 2016
    Posts:
    160
    Folders in the hierarchy. This will make management of assets in the scene easier. Overtime the hierarchy becomes a scrolling nightmare.
     
    Freakish likes this.
  36. LumaPxxx

    LumaPxxx

    Joined:
    Oct 3, 2010
    Posts:
    352
    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.
     
  37. JaredMerritt

    JaredMerritt

    Joined:
    Oct 8, 2012
    Posts:
    53
    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.
     
    alsharefeeee likes this.
  38. Drivecity324

    Drivecity324

    Joined:
    Aug 2, 2018
    Posts:
    8
    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.
     
    stonstad and alsharefeeee like this.
  39. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    2,256
    Theres a free asset to do that I think
     
  40. pbritton

    pbritton

    Joined:
    Nov 14, 2016
    Posts:
    160
    I would like for the feature to be built in.
     
  41. EricDziurzynski

    EricDziurzynski

    Unity Technologies

    Joined:
    Mar 11, 2022
    Posts:
    53
    First off, thank you all for continuing to provide feedback and feature requests here. I’ll reiterate that the fastest way to get these logged is to comment on the public roadmap. We do read these requests and it does help us prioritize our feature development and capture specifics on use during production.

    @alsharefeeee & @Drivecity324 , we’ve heard a lot about the needs for large world coordinate improvements and from previous studio experience I can definitely relate to this need and we’ve added this feedback to our backlog for this feature request and can relay this to the appropriate team.

    @MrPapayaMan , managing streaming worlds memory is definitely a complicated one and touches many teams here at Unity. We’ve logged your feedback and agree with you. The same goes for the Navmesh feedback.

    @bugfinders , We’ll add this feedback for pivot editing in ProBuilder

    @pbritton , Folders in the Hierarchy is on the Editor Usability roadmap in the ‘under consideration section’. We’ve logged your feedback there and agree that having this functionality built into the editor makes sense. We’ll do our best to prioritize this as it’s a long standing, highly requested feature.

    @LumaPxxx , We’ve logged your feedback on LODs and culling distances. Completely agree on this and it’s in our internal backlog.

    @JaredMerritt , appreciate your feedback and if you’d like to have a more candid conversation in a private thread I’m certainly open to that and genuinely want to hear your feedback so thank you for posting. I can assure you that the needs of terrain and support for large open world development tech and tooling are high priority for Unity and aren’t being sacrificed in favor of AI features. Modern Terrain tech and tooling that is production ready is complex and time intensive to develop but can assure you that we hear you and agree that these features are necessary.
     
  42. Hertzole

    Hertzole

    Joined:
    Jul 27, 2013
    Posts:
    424
    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!
     
  43. EricDziurzynski

    EricDziurzynski

    Unity Technologies

    Joined:
    Mar 11, 2022
    Posts:
    53
    @Hertzole , thanks for the feedback and I'll add this to our product backlog. We've definitely looked at this tool internally and have assessed the pros and cons of recreating this tool's functionality internally. We don't have any timeline for this type of functionality being added to something like ProBuilder or native level design tools but if this becomes a higher priority we will add it to the external roadmap.
     
    Hertzole likes this.
  44. Flavelius

    Flavelius

    Joined:
    Jul 8, 2012
    Posts:
    945
  45. Rowlan

    Rowlan

    Joined:
    Aug 4, 2016
    Posts:
    4,536
    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.
     
    Last edited: Sep 17, 2023
    Lymdun likes this.
  46. PaulMDev

    PaulMDev

    Joined:
    Feb 19, 2019
    Posts:
    74
    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...
     
  47. useraccount1

    useraccount1

    Joined:
    Mar 31, 2018
    Posts:
    278
    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.
     
  48. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    5,461
    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.
     
  49. sarbiewski

    sarbiewski

    Joined:
    Sep 8, 2017
    Posts:
    27
    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.
     
    shikhrr likes this.
  50. Rowlan

    Rowlan

    Joined:
    Aug 4, 2016
    Posts:
    4,536
    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 :)