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.
Now in Beta! Get 1:1 live lessons on any Unity topic or help troubleshooting your project – Connect with an expert on Unity Live Help
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?
We need to be able to pass through the terrain collider, like Unreal, Cry does. for caves, so for example, many games use a 3d mesh for the actually cave..but to pass through the collider of the terrain, we have to hack it..So be able to pass through areas of the terrain collider is really needed badly.....Check Unreal...or Cry. They do it very well....
The hole feature in Unity terrains is already doing it and will be public soon:
2019.1 is already out so how do I create a hole?
Don't you know we have minor versions too? Unless they have postponed this!
Isn't minor versions just bug fixes?
Terrain Holes got moved to 2019.3
@MCrafterzz not necessarily, a feature can come in any minor version too. @Rowlan thanks for the confirmation.
anyone has tested the new terrain on mobile? My game on android using unity terrain was way too slow so I had to replace it with a mesh and only use the unity terrain to render trees (terrain draw disabled). I would love to be able to enable the terrain draw again and free memory by disposing my existing mesh. I tried it to compare and I didn't see much of an speed improvement from the <2018.3 terrain on mobile.
Does the new terrain system support physic materials per texture layer? Or is it limited to one physic material per terrain object (as it was in the past)? If the latter - will it change?
Did you get an answer on this?
It's one physics material per terrain still. You will have to handle the 1-to-1 mapping of terrain layer and physics material yourself
With the system we are currently working on, that should be easier to accomplish but wont be available for a while
I discovered another solution that works for me.
Use terrain tool (Physics material 1).
Add a probuilder object (Physics material 2).
Raise terrain around probuilder object so that it looks relatively seamless.
It works quite well.
Manual or is there some automatism?
I do it 100% manual, I wouldn’t even know where to start with automating it.
You could render a topdown orthographic projection of the mesh to basically get a heightmap of it and then use the Terrain painting API to raise the Terrain around that mask
Raise to which height?
Raise/lower the Terrain height to where the mesh is or around the mesh. It won't be exact because you might effectively get some overhangs depending on the mesh you are using and a top down projection wont care about that.
So the projection you mention is a black/white mask with no height info? I was hoping you'd tell us about some magic I still need to find a good way to lift my terrain to eg a street, a ramp or a house and have no idea how to do that effectively on a global scale. Or with a painting brush
no magic yet haha. mostly naive musings.
you'd want a single channel mask. something like the middle texture on the first column of textures shown here:
This is some debug stuff from our Mesh Stamp Tool
you would get the heights or distances of the mesh from the terrain for each pixel in the paintcontext sourcetexture or projection rendertexture.
the result would be the left-most middle texture shown in the gif. you could then do a radial blur/falloff or blur the mask itself a few times to get the stamp you'd need for use with the painting API. you might also want to "flatten" all the pixels in the mask based on some height threshold ( the assumption would be that anything above this is definitely far away from the terrain surface and any blending with terrain can be ignored ) and then apply the blur so you are dealing with mostly a silhouette of the mesh and the falloff you get is only for the bits of the mesh that is close to the terrain.
im thinking each mesh would have a paintcontext associated with it and you'd update it when the mesh is given another orientation. if these meshes overlap, you may want to batch them into one projection to avoid artifacts
this type of effect/system is something i want to try but havent gotten around to it yet. we'll probably make it eventually. the other side of it would be modifying the mesh to fit the terrain so you can also get texture blending on the mesh
And I just noticed you have a 3d preview. The display in the middle:
Is that accessible for us?
The rendertexture debug part should be public in the 19.2 TerrainTools package (not released yet)