Need suggestion for procedural sampling material graph (Removing terrain texture tiling)

Graphics
#1

I am building terrain material which has multiple layers. Each layer is made as individual materials to make graph clean (and to use Linear Layer Blend node).

image
image1413×704 110 KB

image
image815×690 82.3 KB

I want to apply procedural sampling to remove tiling when zoomed out, so looked for ‘Procedural Sample Texture’ node. But I am not sure where to put that in.

  1. Layer material : It has multiple textures to configure PBR, so I need to add multiple samplers and divide the output into RGBA to make the connection for PBR properties.

  2. Terrain material : The connection for Layer blend node gets Material as input, so the output of Procedural Sampler (Color) does not fit into the input of Linear Layer Blend.

image
image879×444 55.1 KB

I must admit that I am not experienced with shader graph or technical art thing, so any suggestions or teaches to make graph is thankful.

#2

Also, for making a triplanar mapping shader, “World Triplanar Texture” also receives a texture and outputs a float3 color, not an ‘UV conversion’. It would be simple if the ground material is simply an albedo painter, but it gets tricky as same as the Procedural Sampler above when applying other PBR maps (metallic, AO, etc) with it.

Is someone can teach me ‘the usual way’ to build Procedural and Triplanar shader material with current I/O nodes, if exists?

#3

Currently, ‘Procedural Sample Texture’ node outputs only one attribute from the texture - color.
It is suitable for final flat texturing, but hard to get along with other UV manipulation nodes.

I feel something like ‘Procedural Texture’ which inputs and outputs ‘Texture’ is needed to use anti-tiling capability with other PBR attributes position accurately.
Or is it normal to implement custom decorator graph for Texture Sampling myself (including normal/metalic/etc) ?

#4

Inputting and outputting a texture? How would that help? If it samples the texture to avoid repetition then you must output color. If you output a texture then you didnt sample and get back to the beginning.

Sadly due to the nature how GPU works you will need to do the procedural sample for every texture on the terrain.

Or you could sacrifice the blending you could have it output UV coords and put those to all textures but I dont think your use case would benefit from that

#5

If it is the inherent nature of shader code, there will be no hope.
But (if it is possible) ‘Inputting and outputting a texture’ surely will help, because nodes I mentioned above works independently from source texture and outputs result pixels independently, not chainable to achieve multiple effect of them.

#6

I believe it is inherent to shader code. You essentially program what each rendered pixel does in fragment shaders. If you want to get a color from texture, you gotta sample it. You cant convert it back into some other texture to resample, that would be immensely inefficient and not really GPU friendly (even moreso than just doing the anti-tiling samples for each layer)

#7

If your analysis is that trilinear sampling node is incompatible with antitiling node or else, complex terrain shaders should inevitably be made from ground up, not using built in features. That is a pity…

What I wanted to know was not making frankenstein with existing nodes and conventions, rather imagining the alternative way to replicate other things “already exists out there”. I understand that every engines are not same, but know that it can be impractical to clone the only fraction of feature, not a theoretically unprecedent thing.

#8

Triplannar sampling and Anti-tiling (Stochastic) sampling are by nature transformative operations.

They accept a texture, sample it (more than once) and output a final color.

Sampling is one of the most intensive GPU operations as you need to pull parts of the texture from vram several times.

Speaking of Engines, Unity nor Godot have functionality to do both triplannar and anti-tile sampling at once for terrains (or even just one of them at a time, excluding HDRP). In terms of Unreal I am also unsure that anti-tile is available off the shelf. Its not really that commonly used as it can be mitigated with better art direction in textures to avoid tiling which (in majority of cases) is a much better solution to the problem than having to spend countless more samples and have the terrain rendering that much slower.

#9

That’s right for Unity and godot, and thank you for informations. I agree that kind of operation is bandwidth intensive.

I hope there will be good ways to utilize existing nodes.