That is brilliant!! Thank you for posting that! I have been trying to work out a low-impact way to texture a terrain, and I think this would work wonderful. Say with mountaintops, I could have a snowy texture… then a corresponding mask that you just airbrush in where you want those bits.
Can anyone modify this shader to allow for a ‘splat map’ for RGBA? Ty VERY much for this EXCELLENT project & keep up the great work!
What exactly do you mean? Is this about using the A-channel as well - because that I did not get arount yet too, so I would second that request.
@Fedor_van_Eldijk Yes, Alpha channel. Just like this example splat map image I have created that contains Red, Green, Blue, Alpha, Red-Alpha, Green-Alpha, Blue-Alpha, and FULL Alpha ( full transparency ) ::
and the ability to use 256 different types of texture channels via the shader. If not, RGBA & being able to change the texture’s quality per-texture would be just GREAT!!!
Once again, thank you SO kindly for the GREAT project!
I’m a bit confused. I don’t understand how you plan to be able to use 256 textures. Could you please explain?
Currently, I use 4 diffuse textures and 1 RGBA splat texture which dictates proportions of diffuse textures on each of 4 channels: R, G, B and A. So there are 256 possible “strength” contributions for each of the diffuse textures. I can imagine how a single channel can be split into 8 bands, and have basically binary blend states with a single bit: ON or OFF, but I still don’t see how to get “256 different types of texture channels”.
I’ve made such a technique for Tesseract, basically the possible 256 materials result by a 8 bit indices map, that could be a larger too of course, but 256 is quiet a lot and has to be in memory as well. It is quiet more complicated though, The indices management is prepared while brushing, since you don’t work with a splat-map per material.
@Fyrestar could you elaborate a bit. I don’t get it
What’s a “material” for you? Do you mean something like a material ID in a deferred rendering? How do you deal with blending if your “indices map” is discrete and each of 256 byte values corresponds to a “material index”? So many questions.
This is what I mean by 256 textures:
Okay, took a while, but I think I understand now. So splatting is binary, meaning that you get to pick exactly 1 “material” per vertex, then inside the fragment shader you sample from 3 textures (1 per face vertex) and interpolate. It’s pretty neat, not too bad for GPU cache either, I think. Problem is only in the fact that you can’t do any blending aside from that between 2 vertices. It’s an interesting approach, I have considered it in the past, but I wanted smooth transitions, so I didn’t go for it. You can probably do smooth transitions with some trickery, like packing multiple copies of a texture into the “ArrayTexture”, but it wastes a lot of GPU memory.
Thanks for the link @Aerion
What i meant with materials is the map stack for a tile/material in the atlas (consisting of diffuse, normals, depth, roughness etc)
Actually storing in vertices is one way to go, but my technique is still based on a weightmap (one for all). Like i said it is about spatial distribution since you rather not need to always blend between all/many materials you have, what happens in the default splatting approach.
With mine you have a constant amount of texture fetches for a theoretically infinite number of materials. I’d say it works similar by storing indices of materials but doing it with maps, since i need a consistent material mapping over huge distances and can’t rely on the tesselation density, as well a varying falloffs still being possible.
Asuming the PBR maps (such as normals, depth, roughness etc) are already packed, with the regular splatting approach, for a number of 16 materials (or called layers there) it will take about 80 texture fetches, while with my spatially based approach it is a constant number of 14 fetches. The more fine details are added with stacked material patches and decal patches for details like puddles, branches, plants or rocks more supposed to be spot-details, but that’s a little more engine specific.
Sounds pretty cool, is there a paper you have based it on, or some other source?
I don’t understand how you’re making the decision about which materials to blend out of many for a specific texel fragment. Personally, i thought about encoding material index and blend, naively that would take a channel each, so say: R: Index0, G: Blend0, B: Index1, A: Blend1. That gives you ability to blend (up to) 2 materials per given texel. Can pack more than 2 into Uint8 RGBA too.
Sorry i don’t have sources, i came up with this technique myself like the rest of the engine
Basically it gives the ability to blend between 4 materials per texel (+1 by using a ground base), this is why the processing on brushing has to be aided and ensure a padding of at least one texel if the channel uses 2 different materials, what happens at a “conflict” then is simply a replacement by the current brush. This isn’t really a limitation though especially when you base your terrain on biomes and use other techniques like i mentioned for additional details. The stacked material patches basically offer something similar the compositor for LOD based tiles would do by giving a much higher texel density by being a local area.
EDIT : So I’ve been working for weeks on this & to no avail.
EDIT 2 : It’s now been a month & still to no avail.
Does anyone know a demo to do this?
If you mean megasplat i don’t think there is a JS one, but it isn’t hard to implement. For the other, i’ve created this technique myself, there is no public demo.
Can you possibly show a demo of the technique you created? RGBA splatmap?
This is too complicated since it requires a different handling of the data, but if you’re interested i’m starting a early access on the planar terrain engine soon, it provides a full system for very efficient large scale LOD terrains.
I’d love to! Sure! When is it going to be out? Can you release an example of LOD terrain with RGBA splatmap?
There are examples and documentation included, the planar + static data based one will be separate from the procedural components and planetary one and be available at a lower price.
I intended to start this month but other work has been busy, so next month i guess.