Auto splatting based on slope and altitude

Tuan, does PLM2 have a splatting mode that automatically determines splats based on altitude and slope per splat texture?

I thought so but I can't find it now...

I have an interesting idea I want to try ...

Doesn't "Splatting" do that? I see it checking altitude and slope.

And you can use any 4 splats, as long as they are sand, snow, rock, grass.

Splatting5 is doing it using Splat.cg shaders.

Is your idea to do lighting base on the slope and height of the terrain, the same way it detemrines the splatting? Think its referred to as slope shadowing or something.

Is your idea to do lighting base on the slope and height of the terrain, the same way it detemrines the splatting? Think its referred to as slope shadowing or something.


Nah, it's actually to do "detail" texturing based on slope and altitude. In traditional terms, a detail texture is a repeating texture that adds extra definition to a low resolution terrain texture that is stretched over the terrain. Usually this is a single image, but I'm planning on it being a grass detail texture where there is green areas, rock detail texture where there are brown areas, etc.

It's similar to splatting but the original colour of the terrain base texture comes through while the detail textures just modulate with that to add extra detail.

How is this going to work, given the limit on splatting textures?

How is this going to work, given the limit on splatting textures?


I don't think you get it... I wouldn't be using splatting textures at all, I'd use detail textures instead.

Either the same amount of textures, or less depending on which I go for:

1. Base texture
2. Detail texture with each of the 4 channels containing a grayscale 8 bit texture that is modulated instead of a splat texture

Or

1. Base texture
2. Detail texture 1
3. Detail texture 2
4. Detail texture 3
5. Detail texture 4

Where each of the 4 detail textures are color blended against the base texture.

Hmm I'm probably still not getting it. It sounds like there is still a limitation of 4 textures for the entire map.

I'm toying with an indexed-splatting idea, where each pixel has a set of texture indexes and alpha values. 4 channels gives me two indexes and two alphas per point, out of a set of 256 textures.

There is probably a more elegant way of doing this, but my interest is on other topics at the moment, and I just want something which works.

Yeah, you're not getting it. Where do you think the limitation is?

This actually has nothing to do with the PLM2 - I could use the TextureFormat=Image and specify my own materials.

At that point, the limitation is on the 3d card. Most modern cards support 8 texture units, some older ones only support 4 (GeForce ti 4000 series I think).

Your example listed 4 detail textures.

Splatting seems to be limited to 4 textures (4 channels in alpha map isn't it?)

I looked at the Image format, and it seems to be giving me a base coloration. At the scales I'm using, one quad = one color = no detail.
I suppose I could crank up the scaling on the color map, but that seemed too expensive in terms of texture memory.

I considered multiple passes for the texture units, and maybe that is a viable way to go. But I think an indexed splatting mode would be less expensive.

How about letting us in on how you plan on applying your detail textures, or how to get more than 4 materials with splatting.

Note that someone asked the same question about a week ago without getting an answer.

Your example listed 4 detail textures.

Splatting seems to be limited to 4 textures (4 channels in alpha map isn't it?)

I looked at the Image format, and it seems to be giving me a base coloration. At the scales I'm using, one quad = one color = no detail.
I suppose I could crank up the scaling on the color map, but that seemed too expensive in terms of texture memory.

I considered multiple passes for the texture units, and maybe that is a viable way to go. But I think an indexed splatting mode would be less expensive.

How about letting us in on how you plan on applying your detail textures, or how to get more than 4 materials with splatting.

Note that someone asked the same question about a week ago without getting an answer.


If I recall correctly, TextureFormat=Image makes it entirely up to the developer to create their materials as they see fit, as long as they name the materials with a specific naming standard. In that case I'm not limited to anything that is built into the PLM2.

So for example, if I have a .material file with materials in it named under a certain naming convention I can do whatever I want with them since the PLM2 will just assign that material to a page.

It could be different now though for all I know.


But I think an indexed splatting mode would be less expensive.

I mentioned something like this to Tuan a long time ago, but I think the only way to do it is to use a 3d texture (use the index to look up into the z coordinate of a 3d texture) and for some reason it won't work. Can't remember why - feel free to look into it.

So for example, if I have a .material file with materials in it named under a certain naming convention I can do whatever I want with them since the PLM2 will just assign that material to a page.


Yes, PLSM easily supports one material per page, and could be persuaded to do one per tile without too much trouble.

The one-texture-per-pass is a bottleneck, and I'm curious if multiple non-overlapping textures could be applied in a single pass. It seems like this would be OK, but once again the number of passes becomes a bottleneck at some point.


I think the only way to do it is to use a 3d texture (use the index to look up into the z coordinate of a 3d texture)


Well that is one way of doing it, and is pretty much equivalent to tiling the textures in 2d (like was done in GPU Gems 2) I suspect the problem is the same for both approaches: the textures need to be the same size. One could stretch textures to match the largest, but then texture memory gets eaten up.

Frankly I was hoping to find another way of representing a set of textures within the GPU. I'm not giving up on this approach, but it is looking bleak.
No matter how much I read about fragment programs, it seems I turn over a rock and find someone doing some new crackpot thing.

Changing the tile representation would open up some possibilities. For instance allowing more than one renderable per tile, and then splitting the tile based on texture.

Or going further and dividing the page per material instead of tile-sized chunks. Since the page seems to be shown/hidden as an atomic unit, there may be nothing sacred about chopping it into fixed sized tiles.

Unfortunately both approaches will require a lot of studying to figure out what assumptions are being violated (and perhaps discover that there are other reasons for tiling the way PLSM is doing).

Please note: I am assuming static terrain which can be preprocessed as much as needed before rendering.