Texture Splatting for the hundred thousandth time

Started by
8 comments, last by SiliconMunky 17 years, 3 months ago
Named the thread to get some attention, but I'm sure these kind of questions get asked here alot. Basically I've implemented something similar to the bloom article on texture splatting. It all looks pretty good, except on certain edges where the alpha transition apears to be too "slow", resulting in a transition fading to gray instead of black. Here is an example of this http://img113.imageshack.us/img113/7461/exampleti0.jpg My theory &#111;n this follows. The article instructs you calculate weights in the middle of each of four quadrents of a tile (ie at (-0.25, -0.25), (0.25, -0.25), etc, relative to the center of a tile). These samples are then saved to an alphatexture (twice the size of my terrain chunk) and my texture uv's are set such that tile[0,0].upperleft = (0.0, 0.0) and tile[w-1, h-1].lowerright = (1.0, 1.0); Now with my limited understanding of textel sampling I imagine it's doing something like this for an individual tile/quad <pre> 0,0——-.5,0——1,0 | .5 .25 | 0 0 | | | | | .5 .25 | 0 0 | 0,.5—–.5,.5——1,.5 | .5 .25 | 0 0 | | | | | .5 .25 | 0 0 | 0,1——-.5,1——-1,1 </pre> In the diagram above the texture coordinates are at corners and each tile contains four samples. This would all work fine of course if the two right tiles were actually rendered with terrain texture/alphamap. The problem is that in this example none of these four tiles is actually the type of terrain I'm currently rendering. All four are grass lets say, now not shown in my diagram are the snow tiles to the left. Because the two left tiles in my diagram border the snow they will be rendered along with the snow using the alphamap shown and the snow texture. However, the two tiles &#111;n the right are not adjacent to snow in the original tile map, and as per bloom would not be included in the snow render pass. So based &#111;n that understanding I'm guessing that when the linear texture sampler (usinga tex2d lookup in my pixelshader if that matters) gets an interpolated coordinate for say the far right side of the upperleft tile (at 0.5, 0.25) it does some kind of average of the near by texels to find the value of the alphamap at the current pixel. Thus the alphavalue assigned at (0.5, 0.25) is something like 0.125, when infact I <b>need</b> it to be 0, because this is the last tile I will render with the Snow texture, and if it doesnt go to 0 then the snow will end aburptly instead of transitioning smoothly as intended. Thanks for reading my rather length post… Any ideas &#111;n how to correct this problem I'd love to hear.
Advertisement
62 views and 0 replies... :(

Is there anything I could do to explain my problem better?
Quote:Original post by Illumini
62 views and 0 replies... :(

Is there anything I could do to explain my problem better?


Hmm. I read your post, and I didn't understand it well enough to be able to suggest how to improve it - sorry. Perhaps if you just give restating your question differently a shot?
Basically, based on my understanding of the article, I've implemented a system where the interpolated texture coordinates at the tile vertices land between the the texels that store the alpha data. The end result is that the fringe vertices on the fringe tiles of a splat are given a alpha value that is the average of the closest textels to it. The problem is that these fringe vertices need to have 0 alpha for the transition to completely fade off.
well ive read it... and i have no idea what ur trying to do.. maybe u could link to that article ur talkin about?
I don't like Bloom's method of texture splatting, or at least not his paper. Perhaps I just didn't have the patience to read his, quite frankly, poorly-written paper thoroughly enough.

I see your problem, and I think I understand what's causing it, but I'm not sure if your implementation or Bloom's design is to blame. Here are my thoughts:
If you alter the rendering pass of each splat to include one more tile in each direction, then you'll be guaranteed to catch the transition to alpha-zero, right?

Edit: I refer you to this paragraph, straight out of Bloom's paper:

Quote:I should note that the base texture and the alpha maps both have the
"usual problem" with chunked textures, that is, there will be seams at
the chunk boundaries due to bilinear filtering problems. This can be
fixed the usual way, by duplicating the pixels along the boundary and
making the uv's [sic] start half a pixel into the texture (instead of at 0,0).


I guess my main problem with this method is the need to subdivide each tile and have so many alpha values to deal with. It seems to make much more sense to keep alpha samples at the vertices, where they belong; and not at tile-centres, where they don't. It certainly worked for me.

Admiral
Ring3 Circus - Diary of a programmer, journal of a hacker.
Bloom's method is outdated and overaly complicated anyway. The best way to do texture splatting is to use blend textures... could be alpha channels, or a seperate rgba texture. Of course your blend textures need a different tex coord than your detail textures. Just use each greyscale channel as a blend value for a shader lerp function like:

lerp(finalcolor.rgb,grass.rgb,grass_blend);

With this method you dont have the problem of vertex density affecting your blending. Also, you can use a seperate greyscale texture to make the fade better, like adding some roughness, so its not a standard smooth fade which looks bad.
Quote:
I see your problem, and I think I understand what's causing it, but I'm not sure if your implementation or Bloom's design is to blame. Here are my thoughts:
If you alter the rendering pass of each splat to include one more tile in each direction, then you'll be guaranteed to catch the transition to alpha-zero, right?


Yes one extra set of tiles per batch would fix my problem, but I was trying to stick to the bloom method, since thats the only article I found, and it seemed to be pretty reputable.


Quote:
Edit: I refer you to this paragraph, straight out of Bloom's paper:
Quote:
I should note that the base texture and the alpha maps both have the "usual problem" with chunked textures, that is, there will be seams at the chunk boundaries due to bilinear filtering problems. This can be fixed the usual way, by duplicating the pixels along the boundary and making the uv's [sic] start half a pixel into the texture (instead of at 0,0).



This quote is refering to seems between chunks, currently I only have one chunk, and my problem is seems between splats.

Quote:
I guess my main problem with this method is the need to subdivide each tile and have so many alpha values to deal with. It seems to make much more sense to keep alpha samples at the vertices, where they belong; and not at tile-centres, where they don't. It certainly worked for me.


I agree, I think a 33x33 alphamap would be much better than the 64x64 one that bloom suggests. I think this is the route I'll take.


Quote:
Bloom's method is outdated and overaly complicated anyway. The best way to do texture splatting is to use blend textures... could be alpha channels, or a seperate rgba texture. Of course your blend textures need a different tex coord than your detail textures. Just use each greyscale channel as a blend value for a shader lerp function like:

lerp(finalcolor.rgb,grass.rgb,grass_blend);


I'm not sure I understand your example, what is grass_blend?
Maybe check out this article:

www.gamedev.net/reference/articles/article2238.asp

It is much more understandable (in my opinion) and contains a demo.
Hope this helps you somehow.
I'm with Gage64 on this one, bloom's article has the theory but is a bit outdated with todays hardware. I used Nate Glasser's "Texture Splatting in Direct3D" article to implement texture splatting. In the end I rewrote it all in hlsl, with different a slightly varied blend method. Let me know if you need some help on the hlsl.

This topic is closed to new replies.

Advertisement