This should be the top most priority. Right this minute, I’m struggling with this limit. A while back, I was running a modified copy of the built-in terrain shader that was hard coded to 12 instead of 8 layers. I moved away from this in order not to have to maintain it, but I will probably go back to this unless Shader Graph lets us output any number of layers we want.
1 Like
Definitely possible, I do it in my asset (The Visual Engine), but I send the textures and layer settings to the material with a custom script. This way I can support all render pipelines with a single approach, and also support any number of layers (limited to 16 in my shaders).
The only problem right now is that unity limits the shaders in URP/HDRP to 64 unique texture units, which is easy-ish to fill up with 16 layers (with default packing using 3 tex per layer), a bunch of features and the built-in textures for lightmaps, cubemaps, etc… This limitation seems arbitrary, as we should be able to use 128 on desktop as far as I know, and it is not happening on BIRP deferred.
Edit: I forgot to mention, I use Amplify, but the same should work with SG if you manage the layer tex and settings yourself.
3 Likes
Yes, decoupling the draw call count from the terrain layer count is a totally reasonable request. Supporting an arbitrary number of bound terrain layers is also interesting. Currently these things can only be done with workarounds, basically you assign a terraindata with a lower layer count to the terrain, copy over all the data except for the terrain layers, then use Material.SetTexture to assign all your various textures that you need bound.
As for the texture arrays approach, yes it is totally reasonable! This is how microsplats does it importance sampling. You can also dynamically generate these texture arrays with the contents of your terrain layers using the ObjectChangeEvents.changesPublished to track the changes to your terrain component and your terrainData.
2 Likes
Hi @BenCloward
Well i’m really excited about 6.3 update soon. I’ve been wondering around 6.3 for preparing my large project to migrate to 6.3 so when LTS ready we are clearly have minimal errors. But i just notice on New TerrainLit ShaderGraph there’s no Tessellation options/check box. Will tessellation be available in the LTS release, or is it not supported at the moment?
I know tessellation is a heavy feature, but it would be great if it were available in Shader Graph. I’ve already used LayeredLitTessellation on my terrain, and I hope tessellation will be supported in Shader Graph so I can improve performance without relying on manual coding.
2 Likes
tessellation is not supported for terrain lit shadergraph 6.3, and will not be supported in the 6.3 point release.
3 Likes
Hmm, I guess that means manual coding until the next LTS, hahaha… but do you know if Shader Graph support for TerrainLit might be coming anytime soon? Like, when 6.3 becomes LTS, will there be any update or consideration to support tessellation?
1 Like
Perfect! This will be really usefull.
Does the newly updated terrain shader in Shader Graph only support a maximum of four terrain material layers? Why can’t I sample textures beyond four layers in Shader Graph?
In both HDRP and URP, you can use more than 4 layers, but the method for supporting more than 4 is different in each render pipeline. In HDRP, you can build a shader with up to 8 layers directly in the shader itself. In URP, the same 4 layer shader is rendered again in a separate pass to support 4 more layers. So URP can support 4, 8, 12, or 16 layers by rendering the terrain multiple times, repeating the same 4 layer shader but with different parameters each time. This is not new with Shader Graph support but is how terrain rendering as always worked in URP and HDRP.
The problem is that more than 4 layers do not support Density Blend (Opacity as Density option), which is essential for our stylized game, and I wasn’t able to find an alternative or replicate it in my own shader
You can make a chunk group terrain in terrain toolkit and asign with same base layer but differennt 2nd/3rd/4th layer. For years i only use 4 layer but it put more effort. Idk am i wrong use this technique but it work for me.
I see that with some work I can hook up some nodes to affect the ALPHA of the terrain which is great. However, this unfortunately has no affect on the alpha / visibility of any tree or detail instances on the terrain. Is this very real aspect of the terrain system not exposed / accessible to the shader graph I’m assuming? Tree / Detail visibility seems to be only linked to a refresh after painting (or updating in code) the terrain holes values / texture.
Crucially and very annoyingly however this updating of the holes texture seems to very much be a destructive action - the trees and details visibility is not affected instead they are being destroyed. This means that a whole host of things are very difficult if not impossible to do, such as for example having terrain (and its trees and details) slowly disappear then reappear etc. I am I correct in my assessment of how this (still!) unfortunately works?
The use-case you are describing seems unusual (“a terrain and its trees slowly disappear and re-appear”). The hole painting is meant to remove parts of the terrain. It makes sense that details in those areas will be destroyed.
1 Like
Maybe so. My use case is to show a terrain appearing over time to illustrate some construction phasing.
Materials go black as you get closer to them in HDRP with Forward Rendering. Changing mat variables fixes until next reload. 6000.3.0b6.
Can anyone point me in the direction of how to affect the alpha of the basic terrain fallback shader? I can add terrain holes to these shader graphs by enabling alpha clipping and reading the terrain holes texture and hooking it up to the alpha input. You actually don’t need to do this to have the holes render correctly in the fallback shader (so the current examples are a bit incorrect really, someone has forgotten all about the fact that terrain holes exist).
Separately from the terrain holes I can affect the alpha using nodes in the shader graph but this has no affect on the fallback shader - is this currently not possible with this added shader graph support? Are we only really able to affect the expensive close up shader as regards alpha (resulting in interesting alpha affects being a bit useless for now as they have no affect on the the further distance fallback shader)?
Hello I am trying to add Tile Breakup to the layers of my Unity Terrain like in the samples.
What I did is create a new Shader Graph from the template “Terrain with 4 layers”
Then I replaced all the “Layer Standard” nodes in the graph with “Layer Hex”, it seems to work as the tiling is gone, but it seems that the terrain does not get lit properly, any Idea why it is the case?
When using the terrain shader graph from the template (using the “Layer Standard” nodes)
When replacing them with “Layer Hex”)
Here is a screenshot of the graph with the changed nodes
I am pretty new to shaders sorry if it is not clear, thanks in advance 
What about Holes? When I try making some holes, is not working.
I just wanted to say… F*** YES! thank you… FINALLY! also Thank you @BenCloward~!
1 Like
Amazing! Thanks Ben and Unity team! I can’t say how excited I am to finally have this in Shader Graph
Are you aware of any support for Unlit Terrain in future?
My current Terrain uses an Unlit Shader Graph with a Custom Lighting Model and a bunch of hacks to get it to work with Unity Terrain. I’d love to transition my shader over to this new system to use all these new features