Converting layered lerped alpha splats to coverage maps

Tuan, imagine I have splatting alpha maps that came out of a terrain editor such as Freeworld or L3DT where the alpha maps are created to be rendered in a certain order using lerping instead of the method you use for coverage maps and the splatting shader which is that all alpha values add to 1 for any particular pixel.

I think you can understand what I mean. If there are 4 alpha splatting maps that are supposed to be splatted, they are rendered one on top the other using the alpha value as a lerp with the previous output.

Can you think of a way to convert the lerped splatting alphas to the coverage functionality? It doesn't have to be perfect, just look reasonably decent.

Instead of
oColor = tex2D(textureUnit1, iScaled0.xy) * Coverage.x
+ tex2D(textureUnit2, iScaled1.xy) * Coverage.y
+ tex2D(textureUnit3, iScaled2.xy) * Coverage.z
+ tex2D(textureUnit4, iScaled3.xy) * Coverage.w;
you have
oColor = tex2D(textureUnit1, iScaled0.xy);
oColor = lerp(oColor , tex2D(textureUnit2, iScaled1.xy), Coverage.x);
oColor = lerp(oColor , tex2D(textureUnit3, iScaled2.xy), Coverage.y);
oColor = lerp(oColor , tex2D(textureUnit4, iScaled3.xy), Coverage.z);

Not idea about how to generate that from a hieghtmap.
a way to convert the lerped splatting alphas to the coverage functionality
you mean N alpha texture merge into N/4 coverage textures ?

oColor = tex2D(textureUnit1, iScaled0.xy);
oColor = lerp(oColor , tex2D(textureUnit2, iScaled1.xy), Coverage.x);
oColor = lerp(oColor , tex2D(textureUnit3, iScaled2.xy), Coverage.y);
oColor = lerp(oColor , tex2D(textureUnit4, iScaled3.xy), Coverage.z);


Yes, that's what the shader would look like, however, I would like to convert it to your style of coverage textures.


you mean N alpha texture merge into N/4 coverage textures ?


Yes, I'd like to be able to import terrains from Freeworld and L3TD, convert the lerped style of splatting to the N/4 coverage textures, and use your existing shader as well as subsequently be able to paint the terrain using your existing splat painting functionality.

So... to recap... I want to be able to take 4 alpha maps that don't have their pixels add to 1, and convert them to a version where they do.

Like I said, it doesn't have to be perfect ... just sorta look right.

I'm thinking there must be a way to do it. Something like taking the layers and applying them one over the other to come up with final alpha values in the same way as you do your coverage painting. If you're adding a value to the top you subtract from those below, know what I mean?

From headeaches it gives me it seems to best solution I can found mathematically, which luckily can be turned into a simple algorithm :

_ using a single color channel only for each splat (1st splat is Red only, second is Green only, etc...)
_ Applying all the "lerps" should result in a final RGBA color.
_ Read each color channel of the resulting color
_ Red value is alpha1, Green value is alpha2, Blue value is alpha3, and Alpha is alpha4

You're done, no ?

If I Recall Correctly, Lerp (x,y,alpha) = x (1-alpha) + y * alpha

rewriting tuan's code, we have :
using
T0 = tex2D(textureUnit1, iScaled0.xy);
T1 = tex2D(textureUnit2, iScaled1.xy);
T2 = tex2D(textureUnit3, iScaled2.xy);
T3 = tex2D(textureUnit4, iScaled3.xy);
and x = Coverage.x
y = Coverage.y
z = Coverage.z

C0 = tex2D(textureUnit1, iScaled0.xy);
C1 = lerp(C0 , tex2D(textureUnit2, iScaled1.xy), Coverage.x);
C2 = lerp(C1 , tex2D(textureUnit3, iScaled2.xy), Coverage.y);
C3 = lerp(C2 , tex2D(textureUnit4, iScaled3.xy), Coverage.z);

can be rewriitten as

C0 = T0
C1 = lerp(C0 , T1, x);
C2 = lerp(C1 , T2, y);
C3 = lerp(C2 , T3, z);

using lerp's formula
C0 = T0
C1 = T0(1-x) + T1(x)
C2 = C1(1-y) + T2(y)
C3 = C2(1-z) + T3(z)

expanding C2 -->
C2 = ((T0(1-x) + T1(x))(1-y) ) + T2 y
expanding C3 -->
C3 = (((T0(1-x) + T1(x))(1-y) ) + T2 y )(1-z) + T3 z

so
C3 = T0(1-x)(1-y)(1-z) + T1(x)(1-y)(1-z) + T2(y)(1-z) + T3(z)
There you have your four multipliers :
alpha0 = (1-x)(1-y)(1-z);
alpha1 = (x)(1-y)(1-z)
alpha2 = (y)(1-z)
alpha3 = (z)


I'm not really sure about this, but ... if someone want's to check my math ...

Shadow, that makes a lot of sense I think!

I'll give it a try!

So Any news ? Did it work ?

Falagard, once you get L3DT terrains able to load up using PLSM can you wiki some info? I'm using L3DT terrains, but I'm still learning about PLSM, and using the Outdated Terrain Scene Manager... lol.

KungFooMasta

Haven't tried it out yet, won't get to it for awhile. I brainstorm things that I need to do and add them to a list. I knew that I had to support importing L3DT into PLM2 terrains so I asked about performing the splat conversion, but I wasn't actually in a position to try it out yet

Sorry.

One thing to keep in mind is that L3DT exports its Alphas to use eight layers instead of four.

Personally I found L3DT to be useless EXCEPT to get the starting terrain shape. The terrains it makes are more suited for flight simulators. What I did was this:

Create the basic landscape in L3DT.
Create an alpha map in Photoshop using the alphas exported by L3DT.
Use Mapsplitter to split the map and the alpha I made into Coverage.
Add a Terrain Deformation and Painting to my game. ( Stealing.. umm... I mean borrowing... a lot of code from GOOF )
Walk around the world editing the terrain to my liking.

As a result of eight layers to four I end up with ugly black splatches where the other four layers belong which I just paint over in the game.

L3DT doesn't really map the textures all that well anyways. It likes to put sand around water which lakes and rivers usually have dirt and grass. The ocean edges tend to be too perfect so I paint them a bit to get a more realistic look.

However I did get a really nice starting point from L3DT. Not implying not to use it, I just don't want anyone thinking it is ever as simple as just exporting from L3DT and instantly you have a perfect usable terrain.

Also @kungfoomasta:

and using the Outdated Terrain Scene Manager


There is nothing outdated about the TSM. It is up to date and very usable. It just isn't quite as fast as PLSM2 though you really have to push things to notice if your terrain is small. It is also nowhere near as powerful. Lastly a medium or larger terrain will make it crawl. However you have very little hope of understanding PLSM2 without using it first. It teaches you basic terrain management in a simple environment. Then all you have to do is take what you learned and use that on a per page basis and you're ready for PLSM2. So there is nothing wrong with what you're doing. I got lost even getting PLSM2 to compile. So I went to TSM and when I was comfortable with it I graduated to PLSM2. I still haven't used all of its features yet but between PLSM2 and Falagard's incrediable work with GOOF I have a beautiful terrain.

( Actually one is better off using PLSM2 with a single page rather than TSM for speed purposes but until there is a reliable demo app to show how to do this it is way too hard to figure out on your own. Also when you are just learning speed isn't important anyways. )

It can output as many layers as you want (such as 4).


As a result of eight layers to four I end up with ugly black splatches where the other four layers belong which I just paint over in the game.

L3DT doesn't really map the textures all that well anyways. It likes to put sand around water which lakes and rivers usually have dirt and grass. The ocean edges tend to be too perfect so I paint them a bit to get a more realistic look.


I'm not sure what version of L3DT you're using, and I haven't exactly tried to take the exported maps out yet, but you can control all the parameters for where the textures get created, the number of textures, etc. In my version there's a dialog called the Climate Editor which gives you everything you need for editing how the splats are generated (slope, percentage, noise for blending, etc)

I intend to add functionality to PLM2 so that you can specify any 4 textures per page, instead of only being able to use 4 textures for your entire world.

I'm using L3DT pro which supports mosaics, which splits the terrain for you in advance. The reason this is critical for very large terrains is that mapsplitter takes too much memory when splitting huge terrains, whereas L3DT splits during creation, which means it can keep memory usage down even on HUGE terrains. I can't see map splitter fixing the particular problem of taking a huge single file and splitting it without massive memory consumption, unless Tuan can read in bits of a large raw file in smaller segments without loading the whole file. Regardless, that's a ways off so L3DT is great for this.

The other solution that could be used is using Libnoise to generate terrain in the same way, in pieces, since you can specify offsets. However, L3DT does create nice terrains if you know how to work with it. Not sure what kind of problems you're having, Patrick.

The other thing I intend to do is to take the pre-split alpha splats out of L3DT and determine the 4 splats that contribute the most to a particular page, and ignore the rest... then do some sort of blending along the edges of the textures so that the transition isn't really jarring. This in addition to each page supporting it's own set of 4 textures means that you can have desert, tropical rainforest, and snowy areas, for example, in a world.

It's going to be a lot of work, but I have harder things on my list of todos as well.

Thanks for the information guys, very helpful to beginners like me.

There is nothing outdated about the TSM

I do not agree. Have you read any of the posts regarding feature requests for this? Something as simple as adding in the function "clearWorldGeometry" to match the "setWorldGeometry" have not been taken up by anybody, nor can anybody provide me with information. I myself have dug into the code, and looked at OctreeSceneManager as well, trying to create this function, but I didn't invest the time necessary to absorb how the scene is created as pages, how the buffers are filled with data, relationships with OctreeNodes with respect to regular SceneNodes, etc.. When I showed my efforts and asked for help, people just told me to do it myself, and tried to defend why this function is not needed. I have had other people (don't remember) tell me that this has not been maintained since 1.0.x, and I believe it. The simple fact that everybody recommends using the PLSM for terrain tells me that the TerrainSceneManager is used as-is, and nobody is working on changing this manager in any way. Prove me wrong.

I am also on my 3 month trial for L3DT pro, and will definately buy it down the road. Although I haven't walked around my world yet, I am impressed with its quality, as I generated a decent terrain in 10 minutes, following the startup tutorial. Comparing effort to output, nothing would be faster to getting me content to work with.

KungFooMasta

It is the pro version I used but it's been a while now so who knows what I set it to. lol.

I couldn't really get the mosiacs to work. I got white strips along the page edges and other assorted graphically glitches like a whole page being light and the page next to it being dark. Seemed if it didn't come out of mapslitter it just didn't work.

Mozaics out of L3DT do not have the proper overlap that PLSM2 needs. The better solution is actually to fix mapslitter but that is an incrediable amount of work. AT least for me since I don't really understand it much.

I also plan to use different textures per page however it will never work out of L3DT. Let's say you have a page with grass and the next page has snow. One could replace the grass texture with snow. However there will be a straight line where the snow ends and grass begins. So you need to have snow also in the grass page so you can transition. Manually editing this isn't hard, just time consuming. L3DT will not do it for you. You have to plan out the four textures per page considering what four textures the adjacent pages use and whether or not a transition is needed. If you are using paths, like I'm using dirt to mark roads like paths, then you only have three textures left for this process.

As you can see we are both on the same road, I'm just a little further down it than you. Unfortunately I'm not far enough down it to have the answers you seek.

The only real solution I can see is to have materials per tile. The same problems exist but less noticable since tiles are smaller. That would mean though that PLSM would have to support per tile materials and be smart enough to batch those with the exact same material. However I don't have the time for anything so grand so I'm just using painting the terrain by hand to get something pretty.

I need to visit the whole terrain by hand anyways since I need to place the trees, buildings, and such. Doing so programmatically hasn't really made any results I like, I'm way too picky. So while I'm there I deform the terrain and paint it.