A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'World Building' started by N1warhead, Oct 10, 2018.
This made my day.
Hi all - cleaned up thread so it's relevant to OP. If you have specific questions that aren't related to what the OP discussed please use a new thread.
Can we expect any updates in this area in 2019.1 or 2019.2?
Even a 'simple' update for terrain objects that would allow to use custom prefabs (same like for terrain trees already) and expose settings like using terrain angle (instead of no 'up vector rotation') would be great as a starting point.
At the moment it's possible to somehow use 'terrain trees layer' for objects/detail/grass but it has few flaws.
The smallest brush radius is quite big, It's not possible to use terrain angle for rotation (which is usually necessary for grass and detail), it's not possible to mix multiple prefabs at once when painting (same as for tress but in case of grass/detail it's very useful) and NavMesh baking process treat everything in this layer as trees.
It could be much more advanced off course and I'm sure you have a lot of nice features planned. I'm just thinking about basic stuff at the moment - some basic set of features that would allow users to use terrain system for grass/detail/debris/bushes/etc.
Any answer would be much appreciated!
How do I copy all the textures/layers from one terrain to another? Copying and pasting the component seems to bug out as it copies more than just the layers. I'm using 2018.3b11
Hi, it's great news that you are working on updating the terrain system because that's something we've really been struggling with for a long time. Just wondering if there are any plans for adding occlusion culling support for terrain trees? What about any other performance upgrades? Adding support for GPU instancing is great but unfortunately it's not supported on the oldest devices our product needs to run on.
Can you help me with this. After upgrade to 2018.3 I got this error: "Terrain Layers cannot be populated at the same time as the splats". I used my script wich I made a year ago. How can I use this new layers instead of splatPrototypes? Thanks/
Sorry but a bump for the OP is needed again now with these subjects mainly in SRP:
Height texture for terrain layers
Easily customizable terrain shader with guide
Terrain support in Shader Graph
I can't even use the new terrain in Unity 2018.3.0f2 the terrain inspector ALWAYS says: "Note: Inspector tab is a duplicate. Paint functionality is disabled". and I can't paint height, textures or anything. A clean project doesn't even fix this, do I need to enable something?
Why not close the duplicate inspector?
It's bugged and stays that way until you close all inspectors and reopen one (atleast it did for me a minor version ago).
I did close all inspectors and re-open just one, tried resetting the terrain component ect. and I still got that message no matter what I tried, I updated to 2018.3.3 about an hour ago because of this, that seemed to fix it.
Question to people using the new terrain system. Is the splatmap resolution (Control Texture Resolution) still limited to 2048?
I hope and think so, yes.
Would like an update please Chris, do you have details to share - anything welcome.
Is this still the most efficient way to get the terrain texture index for a given position for the new Unity terrain system? Are there no built-in functions for this? https://gist.github.com/unity3dcollege/f4e7b3fdb95210561580a0d14c4c4f8a
@Ziplock9000 looks about right. nothing built-in that i know of
Thanks. It's just that I've seen comments from various places casting doubts on the performance of this method.
What I wish the terrain had was a detailed color map and detail normal map to make it look more natural, or at least give us the ability to blend the first texture layer above all of them with overlay blend. Like this! I would not complain about parallax if I had that at least but that two is something that needs implementation
An overlay texture with alpha masking is something I need for my game too. I'm going to have to go for a 3rd party solution for this.
Overall, after all the song and dance about the new terrain system and a dedicated team, little has changed. AFAIK, nothing has been added to 2019 either, which I don't understand.
For the standard terrain, I'm kinda hacking it with a simple trick, by adding the color map on the first tile layer and setting to 30-50% opacity in the brush settings. It's not a very good alternative as it makes your terrain 40% more milky looking and the standard shader has plenty of it already lol. That's definitely a feature I would love to see in the new terrain, two things I want "color map and parallax/tessellation"
I am thinking they are first developing the terrain tools features and UI so I'm guessing the visuals isn't the top priority atm.
Hello, i've come into some trouble using the terrain.SyncHeightmaps() introduced with the new terrain system. Its very poorly performant if used each frame during runtime. I am hoping that some of the devs could shed some light on how this method works and how to maximise it's performance. I've parsed the 2 main functions inside the SyncHeightmaps() method which produce 99.999% of the lag and have come to these findings:
1. The Terrain.RecomputeInvalidPatches() method performance is based purely on the amount of heightmaps that have been changed in the terrain and the heightmap resolution of the terrain. After some testing, i've noticed that it's performanced was scaled greatly by the heightmap resolution, leading me to believe that perhaps there's room for improvement for this functions with the Draw_Instanced option on the terrain componant. From manipulating 1024 heightmaps in a 65x65 resolution terrain and 1024 heightmaps in a 513x513 resolution terrain the avarage ms for the former was 0.05 and 2.5+ for the latter, fluctuating from the avarage by about 75%. The performance seems to scale evenly on the amount of heightmaps manipulated and the heightmap resolution.
2. I wasn't able to pinpoint the RenderTexture.SetActive() performance on anything. I've tried to troubleshoot this method for about quite some time and have come to no conclusions on what influences it's performance other than the first time this is called inside SyncHeightmaps(), it causes a lot of lag. Sometimes after manipulating 1024 heightmaps on any terrain heightmap resolution i will get from 0.3-8.0 ms on the cpu, while manipulating x5-10 more heightmaps will lead to either the same or quite often lower ms. It also seems like the more time Terrain.RecomputeInvalidPatches() takes to process the less time needed to initiate the first RenderTexture.SetActive().
Here's some of the data:
1024 heightmaps changed in 513x513 heightmap terrain:
CPU - https://i.imgur.com/mBbKM0E.png
GPU - https://i.imgur.com/fBrD4kB.png
4096 heightmaps changed in 513x513 heightmap terrain:
CPU - https://i.imgur.com/Gf6vQvq.png
GPU - https://i.imgur.com/dH60UAE.png
My question is this:
1. Will there be SyncHeightmaps() support coming in the future to make it perform much faster? The TerrainPaintUtility tools have greatly improved procedural terrain capabilities based on heightmap manipulation in terms of speed, the only thing that's missing is the performance of turning the terrain changes into a mesh collider.
@crysicle Just posted a reply on your original forum post. Let's take the discussion over there again. Here's the link for everyone else interested:
Hello, i have some questions about the way extraBorderPixels inside of TerrainPaintUtility.BeginPaintHeightmap() work and the RenderTexture which is stored inside of PaintContext.sourceRenderTexture.
1. Currently if you use extraBorderPixels to get extra heightmap information, it will get extra heighmaps in all directions. This, however, will no longer be the case if the extra pixels reach the edge of the terrain that you're passing through BeginPaintHeightmap() method. Once all of the passed terrain's heightmaps will be selected, the method will start to choose the closest neighbouring terrain's heightmaps like a compass : NE, SE, SW, or NW and will only gather extra heightmaps from the terrains which are in the selected direction.
For my project, i'll be splitting the terrain into lots of small pieces and it would make more sense for the extra heightmaps to always be selecting the closest extra heightmaps without restriction. Will the way this function work in the future be changed to accomodate this?
Furthermore, i'm getting "PaintContext pixelRect is too large! It should touch a maximum of 2 Terrains vertically" warning when using it my way due to the splitting, it'd be great if there was a way to disable it.
2. At the moment i'm manipulating the sourceRenderTexture inside a compute shader, however i can't do that directly as the context's RenderTexture itself lacks the enableRandomWrite flag set to true. This leads me to create another RenderTexture and use Graphics.CopyTexture before i can manipulate it and send it off to destinationRenderTexture. Could this flag be enabled by default? It'd save some processing time.
Also, why does the destinationRenderTexture exist? It seems like all of the information could be derived from sourceRenderTexture. No?