24 replies to this topic

[roxtar]

Hi, I was trying out terrain rendering using heightmaps in OpenGL. Till now I have the heightmap correctly loading, and I am able to display the terrain as a wire mesh. But, I still have very less clues as to how to go about texturing the terrain. It would be nice if someone could point out a simple way to go about it. Thanks.

[Reedbeta]

Well, a very simple way is to use a 1-D texture that contains different colors for different elevations, and then assign the height of the terrain to be the texture coordinate at each vertex. A better way is to use a program like Terragen to import your heightmap and render a texture using its orthographic camera mode, which you can then just apply to the entire terrain. An even better method is called texture splatting - google for it.

[roxtar]

Thank you Reedbeta, I will try that out.

[roxtar]

The 1D texture method worked :yes:



I have another query though. How does one decide on the texture coordinates of each vertex when using a 2D texture instead of a 1D. I took a naive approach and assigned random texture coordinates to each vertex. The result, without doubt, was horrible.

[Ed Mack]

Use the same coordinate system as the heightmap - i.e. just stretch the entire 2d texture over the whole landscape (and perhaps look into using a detail texture via multitexturing - google)

[roxtar]

Thanks, that now seems so obvious.

[Nautilus]

Sorry to resume an old thread, but being interested in Texture Splatting
I too have read Bloom's article.
(Google --> "Texture Splatting" --> Bloom is the 1st item found).
I've read it many times, but without fully understanding his technique.
Despite the efforts, many dark points remained in my mind.
(My dog says Bloom is a dog at explaining. I agree.)

Bloom's article:
http://www.cbloom.co...s/splatting.txt

Fortunately, right after Bloom's, I came across Glasser's article, born in the
attempt to clarify Bloom's obscure points.

Glasser's article:
http://www.gamedev.n...article2238.asp

Good Glasser fully succeeds in his effort, and the dark points are no more.
All except... one (gotta stop with D2...)

In the paragraph The Problem of Seams, Glasser comments on the one and only
big problem affecting this technique: the seams.
If I understand correctly the seams appear because we are supposed to use the
same Alpha masks with the same materials.
This leads each material to blend always in the same way.
By looking for a moment at the last three pictures in Glasser's article it is
clear why seams form.
Glasser then says "this is not an easy problem to fix [...]".

Looking for more articles, I have found nothing really good, except a pair from
flipcode (I presume they were good articles).
Of course, flipcode no longer exists... Not even in the Cache of Google :(



Now. I've made some thinking into Splatting and its seam problem.
But then I realized how stupid was the idea I came up with.
Still, I'd like to hear your impressions.

As Glasser points out in his article there's no need to keep a separate Alpha mask
for each Texture/Material.
Suppose we have four materials we want to use to texture all our chunks.
Each material would want its own Alpha mask, but this doesn't mean we have to keep
in memory four diferent Alpha masks. Being Alpha a single Channel we can combine
four of them into one texture and then treat each of the Channels (ARGB) as if
they are all Alpha Channels (AAAA).
There. Some memory is saved, but nothing new so far.

Then I thought about the seams. How to avoid them?
The perfect solution would be to use a dedicated Alpha mask for each chunk of
terrain.
But wait, this is so easy that it's too easy (my dog agrees).
Can't be that easy, come on. Where's the problem?

My resourceful dog, barks that if we have a terrain of 1024 chunks, then we need
1024 different Alpha masks.
And this without counting the memory needed for the Texture/Materials.
Man, that's ugly! (my dog nods).

But then, I thought again... an Alpha mask containing four channels is the same
thing as a regular texture after all.
So why not just prebuild the final blended textures, save them somewhere maybe,
and then load the appropriate texture for the chunks we are going to render?
In this way we can drop the whole multitexturing (and its overhead), make happy
our fillrate, and save some memory since there's no longer need for separate
materials.
Great!

Maybe not... I'd still have to keep loading/unloading the textures for the chunks,
since each chunk would be rendered with its own unique texture.
Seams would disappear completely and texturing would perfect...
but what about the performance drop to the continuous load/unload?

I'm stuck. Can't think of a good solution.
Texture Splatting isn't that great after all.
And my dog is looking down on me now...

Any idea?
Ciao ciao =/

[Mattias Gustavsson]

I've found texture splatting to be quite useful, I've posted a couple of examples below. What I do is use 3 textures for each splat:
One blend texture, for the alpha channel. This is stretched across the entire terrain

Then, one terrain texture, generated from blending 4 textures based on the heightmap. This is also stretched across the entire terrain

And finally, one tile texture (in full color, not just grayscale) which is heavily tiled over the terrain. It is modulated with the terrain texture, giving more color variations.

All my textures are 256x256.

Here are a couple of renders using this technique. Note that shadows are missing from these shots, and they make a big difference to the look.



The textures used here are from the excellent Dungeon Pack by Frogames http://www.devmaster...read.php?t=5247 which I really recommend! It's very good quality, and they are extremely helpful people.

I don't really understand the problem with seams... surely that's just poorly created blend textures? I currently render all the terrain as one chunk, but when I come to splitting it up, I will just make sure the right part of my big blend texture is used for that chunk texture. Or am I missing something here?

[geon]

If you stretch the alpha mask over your entire terrain, there obviously will be no seams. If you still need to use multiple alpha masks (ie. for very large terrain), you can hide the seams by making sure every pixel-pair in the edges between 2 masks are identical. That should be pretty simple/efficient to do even at runtime.

[Nautilus]

Thanks for helping, but I don't know.
I'm pretty much confused.
The more I read Bloom's article, the less I get it.
I'm thinking that Glasser himself didn't fully understand what Bloom wanted to explain...

Look in Bloom's article, at the beginning, there is a link pointing to his website.
Have a look at the few pics shown in there, please.
Honestly I do not see the horrible seams Glasser speak of.

Yes there are seams in a couple Bloom's images, but they are not that awful sight. What do you think?

That's why I'm suspecting that Glasser did not completely understand what Bloom described, and eventually encountered a problem which Bloom did not (or at least Bloom solved).

Please, can anyone help me with this?

Regards,
Ciao ciao :)

[Mattias Gustavsson]

Ok, let's see if I can get this straight.. What I have at the moment, is one blend texture stretched over the entire terrain with bilinear filtering:

To the left is the blend texture, and to the right is a section of it (the part marked in red on the left) stretched up using bilinear filtering. This is what I currently get.

Now, let's say I need to break my terrain up in two chunks, each with their own blend texture. I make the split just across the middle of that section we zoomed in on above.

Again, this shows the parts of the blend texture marked in red strecthed up using bilinear filtering. When both them parts are placed next to each other (rightmost image above) they blend together smoothly.

Now, if I didn't render the two chunks with blend textures that fit together smoothly, I would get terrible seams. Also, as geon said, if you don't make sure to repeat the edge pixels, you would get visible seams.

I don't understand what it is that's causing you problems, but please, try and explain and I'll try to help.

/Mattias

[Nautilus]

@ Mattias:
That's very kind of you.
Your explanation makes perfect sense, but my problem is different.
I can't apply one big blend texture to the whole terrain, because it's supposed to be huge and can't be kept in memory all at once.
(my bad I hardly explain things right)

Assuming you have read Bloom's article and made it out sane

Let's see...
Bloom makes an example to better (b-better...) illustrate his technique.
Now, I get confused over the size of the textures he's using.
He talks about different sizes, somewhat multiples of each other.

I *think* to understand he uses 'materials' (textures) of size, say, X and then forges at run-time an Alpha texture of size 2X (I mean, an Alpha texture having an area 4 times bigger than the materials).
I don't understand how exactly he makes use of this bigger Alpha, nor why it has to be bigger than the materials.
But things get worse. He later talks about a Texture of size 4X, and I completely miss the purpose of it.

He also -briefly- explains of a weight formula he uses to calculate the Alpha of each pixel (texel) he's going to blend.
Easy: given two Texel coordinates, he calculates the final Alpha-weight for the Texel he is interested in.
I understand this weighting formula could be anything I like (he's just explaining the one he uses), but I don't get all the passages.
At times he seems to be talking about single texels, other times he's talking about entire textures (or chunks of terrain... he even fails to make the proper distinctions).
After the explanations on his weighting formula, he then invents some 0.63 number...
I'll quote:
- "So the weight from my '*' to the lower right tile would be 0.63"
Yeah, what he said!
Let me point out that his '*' refers to a single pixel (or Texel) while his 'tile' refers to an entire Texture (or material... or chunk).
How am I supposed to interprete that sentence? Where does that 0.63 come from?

The only thing I'm sure of, is that you have to find all the adjacent materials to the one you are processing to calculate the Alphas of each Texel (of the processed material).
But then he focuses only on one material, the center one (in his example there's a grid of 3x3, containing 3 different materials A, B and C. Center material being of type A).
And outta the blue he says you have to normalize all the weights you have calculated for all the materials similar to the one you processed (?) so that all the Alphas sum up to 1 (?).
I know what normalize means. I don't know what he's talking about.
Exactly why do I have to normalize only the Alphas of the similar materials? But wait, do those similar Materials need to be treated as distinct entities or as a whole?
And what about the other 6 chunks around, containing 2 different materials?
They should influence the weights, but he says nothing about that...

Look, I don't want you to go nut like me.
Feel free to pull out anytime.

TIA for any help,
Ciao ciao :)

[geon]

It seems to me bloom is not a very gifted writer. (No offense, but not everyone can explain their thoughts in an easily understandable way.)

I suggest you drop the papers for a while and try to understand what you are doing. Then see if you can fix any problems that might arise on your own. (Or together with our helpfull community.)

[mysticman]

sorry I hijack, but....
Hey Nautilus!!! :p finalmente un italiano!
I'm Typhontaur (old mysticman)
ciao ciao! :)

[SigKILL]

After a fast read of blooms article:

Nautilus said:

@ Mattias:
He talks about different sizes, somewhat multiples of each other.

I *think* to understand he uses 'materials' (textures) of size, say, X and then forges at run-time an Alpha texture of size 2X (I mean, an Alpha texture having an area 4 times bigger than the materials).
I don't understand how exactly he makes use of this bigger Alpha, nor why it has to be bigger than the materials.
But things get worse. He later talks about a Texture of size 4X, and I completely miss the purpose of it.

The alpha textures does not have size 2 times the materials, but 2 times the size of the 'chunck' ( i.e. the 32x32 vertex terrain block). He is using this alpha texture instead of doing per vertex alpha (he don't want to touch the vb (Hardware T&L friendly)) for the splatting. The texture of 4 times the size of a chunck, is the base terrain texture. He only does splatting near the camera, and splats after rendering with terrain texture (gets rid of some artifacts explained earlier in the article).

Nautilus said:

@ Mattias:
He also -briefly- explains of a weight formula he uses to calculate the Alpha of each pixel (texel) he's going to blend.
Easy: given two Texel coordinates, he calculates the final Alpha-weight for the Texel he is interested in.
I understand this weighting formula could be anything I like (he's just explaining the one he uses), but I don't get all the passages.
At times he seems to be talking about single texels, other times he's talking about entire textures (or chunks of terrain... he even fails to make the proper distinctions).
After the explanations on his weighting formula, he then invents some 0.63 number...

He doesn't invent 0.63, plug his values into the formula and you get
1 - 2*((1-0.25)^2)/(1.75^2), now plug this into google or your favorite calculator. You should be careful inventing your own formula since it might result in wierd blending. You should also remember to normalize (i.e alpha values should sum up to one).

The textures hes talking about are the textures you're blending in the splat (i.e. grass, rock, whatever), he then create a alpha textures for each chunck and each texture (so he will render each chunck several times with different texture and alpha texture, remember this was written in with GeForce in mind). To avoid some artifacts when rendering he first render the chunk with a base texture.

Hope this helps, I might have some errors since I really didn't read it thouroghly :/

There should be more discussions like this in the forums.

-si

[SigKILL]

Well, just to clarify with an example (I'm a little bored right now ;)), what he does is something like:

pass 1: render chunk with base texture
pass 1: render chunk with grass texture and grass alpha texture.
pass 2: render chunk with rock texture and rock alpha texture.
..
pass n: render chunk with n'th texture and n'th alpha texture.

There is ofcourse no problem with generating a 'splatted' texture at load time (as long as you make sure the seams are OK). This will probably take some more texture memory (since the alpha textures have (far?) lower resolution than the finished texture), but should be OK on modern hardware, I think (maybe not for consoles though). I'm not sure if this would be much faster though, since you can do several textures (4?) in each pass on a modern card. AFAIK, almost all games are CPU limitied (not GPU limited as many think), so some extra passes might not be that bad a at all. Actually, how many times would you have more than 4 or 8 textures in a 32x32 block?, and when you're only doing this close to the camera I don't think the fillrate issue would be too bad most of the time... However, YMMV...

-si

[Nautilus]

@ SigKILL:

SigKILL said:

After a fast read of blooms article:

The alpha textures does not have size 2 times the materials, but 2 times the size of the 'chunck' ( i.e. the 32x32 vertex terrain block). He is using this alpha texture instead of doing per vertex alpha (he don't want to touch the vb (Hardware T&L friendly)) for the splatting. The texture of 4 times the size of a chunck, is the base terrain texture. He only does splatting near the camera, and splats after rendering with terrain texture (gets rid of some artifacts explained earlier in the article).

[...]

-si

That was neat! Thanks!!!
But there's still one dark point (don't abandon me now, please).

You say the Alpha texture is twice the size of a chunk, instead of the materials.
Ok. Since every chunk will have it's own Alpha texture, doesn't this mean that every Alpha will not only affect its own chunk but also the neighborhood?
Why Alpha-affecting the adjacent chunks if the materials do not?
What's the use for the extra Alpha data?



@ mysticman:
Ma che bella sorpresa, ciao!
Non è che per caso sai aiutarmi con 'sto Texture Splatting?
Sto diventando matto...



Best regards,
Ciao ciao :)

[SigKILL]

Nautilus said:

@ SigKILL:

That was neat! Thanks!!!
But there's still one dark point (don't abandon me now, please).

You say the Alpha texture is twice the size of a chunk, instead of the materials.
Ok. Since every chunk will have it's own Alpha texture, doesn't this mean that every Alpha will not only affect its own chunk but also the neighborhood?
Why Alpha-affecting the adjacent chunks if the materials do not?
What's the use for the extra Alpha data?

Not sure if I understand the question. But by saying the alpha texture have twice the size, I mean that the alpha texture have twice the resolution. This is adds up allright since he's having a chunk with 33x33 vertices (however we say that somewhat wrongly (but it makes perfect sense when it comes to texturing) that the chunk is 32x32) so we get four texels for every square of height value ( That's square as in four neighbouring height values ).

-si

[soconne]

My terrain editor Freeworld3D uses the technique you guys are discussing. You can add as many alpha layers as you want. Each alpha layer contains a texture and an alpha texture ( 8 bits only ).

Then the terrain is rendered over and over for each layer you have.

http://freeworld3d.org

[Nautilus]

Hi Sig,
I'm not sure the Alpha texture doesn't overlap with the neighbouring chunks.

I'll quote from Bloom:

Quote

The result is an alpha channel which is all white around the middle of a
splat, gray where it blends with another, and black where the splat has
no influence (there aren't any triangle there either).

This is found, ooh, 16 lines after the stylized 3x3 grid in Bloom's text.
He talks of missing triangles. Assuming for a moment that the Alpha texture is bigger than a single chunk and thus overlaps with the 8 adjacent chunks... then a case of missing triangles, to map the Alpha onto, could be when the chunck in exam is at the corner or along the edge of the terrain.
(I can be wrong, of course)
What do you think he means?

Thank you,
Ciao ciao :)