Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[agracier]

Right. I don't know nearly enough of the terrain texture system to comment on that. Does IL-2 absolutely require alpha channel to be able to use a terrain texture?

I think that ground textures do not necessarily require an alpha channel. At least in my experience when making my own ground textures, I never get a message from my graphics editor about alpha channels, but I sometimes do get messages when trying out textures made by other members or also on some aircraft skins ...

Nor do I create alpha channels when I make new ground textures. And I've made more than enough ground textures so far ...

[agracier]

Thank you. But seems that it doesn't works for the ground textures (at least for me). I will try another dll's, using "light" version now.

The light version is the only version so far that works for me ... I would definitively try that one ...

I tried the others umpteen times, with new clean installs, and other permutations, but for ground textures none of the versions worked. Until the 'light version' was posted and made available. And that one works like a charm ... just don't ask me why.

[SAS~Boomer]

Does IL-2 absolutely require alpha channel to be able to use a terrain texture?

No,ground textures for maps do not require.... an Alpha channel..,
But quite a few default IL-2 ground textures for maps do have Alpha channels

The Alpha channel on these textures,have a pattern on them with the Alpha channel,
that helps blend textures together when they sit side by side on a map slightly overlapping each other
It helps to blend opposite textures together with one another as they overlap one another on a map

A lot of default textures were done this way,it just has never really caught on with most map editors...

The default IL-2 sk_airfield texture below, shows the Alpha channel
while looking at the texture in Ifranview you see the dark and light green on the texture
when viewed in Gimp,the Alpha channel is clearly seen

[Herra Tohtori]

Yep, that was my point - only use alpha channel when you need it.

Including it on non-transparent maps is a waste of hard drive space and possibly also video RAM. It's a totally different story when you use the alpha channel to blend different textures together.

So whether you use 24-bit (RGB) or 32-bit (RGBA) should depend on the texture.


As for indexing, I don't think it should be used for the diffuse textures. However, if it can provide memory saving, using indexed textures for normal map files (Dot3 files) might be wise, but only if the conversion to indexing doesn't provide a noticeable drop in quality. This is highly dependent on the content of the file. In my tests, normal maps for water can be indexed without any obvious visible quality drop, but a normal map with lots of smooth gradients would probably suffer more.

[Avala]

How I see it, there is no need for alpha channels if texture are properly made. Which means it must be seamless and in the same tone as other textures on the map. Indexed textures are not so different than 32 bit textures if they are in the same size. Of course the bigger the better (in pixels)

As far as I know there is no need for indexing normal maps (in IL2 known as BumpH files) because they are in grayscale already, which reduces the "weight" much. People don't know this, but even before high resolution mod, BumpH maps was available in bigger resolution, you could have BumpH maps even in 4096 x 4096 pixels without any problem. The color textures (tga) are important but BumpH textures are also important in the ground textures, because they give "light and detailing" to the ground. Map makers usually make mistake by making BumpH files with grayscaling and inverting the color tga textures, which gives very harsh and "light" flat effect. BumpH maps must be made with the tools for the normal map making such as this one:

NVIDIA Normal Map filter

https://developer.nvidia.com/nvidia-texture-tools-adobe-photoshop

You just make the end result grayscale, instead of the blue and pink.

In these creenshots the color (tga) texture are in 1024px size and indexed (because I cant get high rez texures to work  ), BumpH texture is in 2048px (made from the file in that size) and made with that Nvidia normal map application. The effect is subtle but it could be made with many different variations, it even can simulate smaller hills.

Bear in mind that the terrain is totally flat and that it's only one textures on the ground.

[Herra Tohtori]

BumpH maps are not normal maps.

BumpH maps are height maps. They store the elevation (displacement from zero level) in greyscale, giving 256 values of different elevation, in the range of [0,255]. The middle grey is "unchanged" elevation of the surface (grey level 127-128), while darker makes a hole in the ground and brighter makes a bump.

Normal maps are an entirely different animal. They don't store the surface elevation relative to any particular level. Instead, normal mapping stores the angle of the surface. In mathematical terms, normal map stores normal vector values. There's two types of normal mapping.

One way is object space normal mapping, which stores the normal vectors for the surface in three dimensions, which means it needs three colour channels to do this.

The other way is tangent space normal mapping. This system essentially uses the normal vector of the 3D model's polygons as the default value, and the normal map adjusts the normal vector from this neutral value. Tangent space normal maps use two colour channels to store two values - the "horizontal" and "vertical" angle adjustment, relative to the texture coordinates (usually these are referred to as U and V coordinate directions).

In IL-2, height maps are used for a technique called bump mapping, which is to some extent related to normal mapping - it interpolates the gradient of the height map to produce a normal vector for the surface, and uses that to adjust the brightness of the surface (since surfaces with a more oblique angle to light receive less light per surface area and thus appear darker).

Normal maps seem to be only used for water - at least I have never seen any terrain textures have quite the same effect as normal maps on water. The water system is a bit more complicated than terrain rendering, since it actually uses the BumpH height maps for displacement of the water's surface, and then on top of that uses normal maps to facilitate additional detail to the specular reflections...

It would be interesting to see if normal mapping works for terrain textures, though...

[Avala]

I don't doubt your expertize at all. And I really don't have your expert knowledge on this, but seems that you didn't understood me. And seems that you don't know how the IL2 maps exactly are made (if I am mistaking I apologize). Things in IL2 doesn't work the so "normal" way, as in other games.

BumpH files, which are used for adding "shadows" to the maps, are not what you know as "height map". There is thing in IL2,  exactly what you have described here:

They store the elevation (displacement from zero level) in greyscale, giving 256 values of different elevation, in the range of [0,255]. The middle grey is "unchanged" elevation of the surface (grey level 127-128), while darker makes a hole in the ground and brighter makes a bump.

Which does that. And it is called "height map", and looks exactly as you have described it, but, that is used for map building, not texturing. The heights and elevations of the maps are made with that. We call that "map_H". BumpH textures doesn't do that. You cant change or affect height and elevation of the maps with BumpH textures in IL2 in any way. That is done with "map_H".

BumpH textures is more like this:

In IL-2, height maps are used for a technique called bump mapping, which is to some extent related to normal mapping - it interpolates the gradient of the height map to produce a normal vector for the surface, and uses that to adjust the brightness of the surface (since surfaces with a more oblique angle to light receive less light per surface area and thus appear darker).

With the big difference that you cant change geography (height, elevation) with BumpH textures in any way. You can just play with the light.

BumpH textures are there to simulate shadows in the wholes in the ground, uneven surfaces, and before all shadows of the hedgerows and the roads. If you made it lighter the color texture (tga) looks darker, if you made it darker the color texture looks brighter. In that way you can affect look of the map, but that is it. No changing in elevation and height.

If you make a BumpH texture which simulates bush, more precisely the shadow of the bush, and observe the map in 8X speed you will see that the shadow travels with Sun. As Sun moves, the shadow moves also. If you set Sun in some lower elevation, for example set  mission in the game in November or December, you will see how the shadow are longer, having different angle and looks different than in the July.

And that is exactly how the "normal maps" behave. Why BumpH textures don't look like normal "normal maps" you should ask Russians, I was puzzled too 

Maybe I confused you with suggesting Nvidia "normal" map tool for BumpH textures. But have in mind that I said when you are done with making normal map of your tga texture, you must make it greyscale.

Since the image tells more then words . . .

The color texture:


The usual way of making BumpH textures:


The color texture processed with "normal map tool" (but still not for our use)


"Normal map" made into greyscale, and thus can be used as BumpH texture (but not yet looking good)




And this is what I do. Its BumpH texture made in two layers, and with "normal map tool".

First, I made a layer with classic "greyscale, invert, and blur" technique. Much blurring, plus make it darker and with low contrast. That layer will be "the light" on the map.

The second layer I made with processing color texture in "normal map tool" and then placing it above first layer, make it greyscale and then enabling "overlay" in "general blending" in "layer style" options in photoshop.

In that way I have the light and contrast with the first layer, and fine details with the second. The shadows are not so harsh as in classic "invert" method. There is some depth and difference in the shadows, while with the classic invert method all the shadows are the same, for example the shadow of the grass is tall as the shadow of the tree.



And there is plenty of room for experimenting.

[Herra Tohtori]

Ok, this is going to be a long post but I feel there are a few things I want to help clear out, if at all possible.


I'm aware that there's a height map that is used to determine the terrain mesh geometry, and the terrain textures themselves do not modify the terrain geometry, only lighting. No worries on that regard, misunderstandings happen.

I'm using the term "elevation" because bump mapping uses a height map, and I use height synonymous to elevation, so no problem there. Also, in the case of water textures, BumpH maps actually do modify the water surface's geometry, but obviously not for terrain textures. The texture format is the same in both cases anyway - greyscale height map.


The reason I pointed out that BumpH maps are not normal maps is that bump mapping is a completely different technique for creating the impression of surface geometry than normal mapping is. The difference is mainly in that bump mapping uses a height map to interpolate surface normals on-the-fly, while normal map has all that already built into it so you have a more direct way of adjusting the surface normals - and not just that, but because bump mapping relies on interpolating the gradient of the height map, you get lower effective resolution as well.

And the reason why this is relevant is that a process to create a height map should never, ever involve converting it into a normal map and then back to height map. That's just going to throw all sorts of wrecking balls to the information actually present in the texture, and while it might produce some kind of results that look acceptable.


Let's see if I can make sense of this...

Here's an example height map. It's not a terrain texture, but it will do for the demonstration. It has a few recesses (darker areas) and elevated areas (brighter areas, like the pyramid):



And here's how you would expect it to effect the surface, assuming light is coming from above and left:



Now if you were to convert this into a normal map, you would get something like this:



And now we get to the problematic thing about the process you described.

If you now take this normal map, and convert it to greyscale, you get this:



...and now there's a problem, because what is bright on the normal map does not correspond AT ALL to what is bright (elevated) on the actual height map! In fact, you get a situation where you have lost all the gradient information from the original height map, and instead of a naturally changing elevation you have these flat areas of about equal brightness, but with very sharp jumps from one "plateau" to another.

If you use this in bump mapping, the end result will not in any way correspond to the original texture's possible height variances - which, by the way, are usually not directly related to the brightness of the texture, so at best the method of converting a texture directly into height map by desaturation is a bit iffy, and at worst produces completely bogus height maps - for example if there is a dark rock in the middle of some white sand, it will come out as a hole in the bump-mapped surface. But I'm sure you are aware of this. The bigger problem is that by including a normal map in this process you essentially destroy a lot of information and then treat the output as the same thing as the input, which isn't exactly a good idea.

For demonstration's sake, here's what you get when you use the desaturated normal map for bumpmapping:



...and a side-by-side comparison with the original height map bumpmapped:



normal map result proper height map result


If I had to make a height map of your sample texture with the rocks in it, I would do it like this:



desaturate by Average intensity:



Level so that the "cracks" between the rocks become dark and the stones themselves bright:



Applied gaussian blur to the desaturated texture and added a really small amount of RGB noise:



Add the black "cracks" between the rocks, from the earlier step:



Finally, I applied levels to reduce the range from "lowest" to "highest" elevation, instead of running the full gamut from 0 to 255 I made it run from 94 to 160:



This produces the following bump mapping results (in GIMP):



...and now all that's left is to do a little test to see whether the bump mapping results make sense, in comparison with the original texture:



Since the bump mapping seems to "blend" in a sensible way with the original source texture, it's probably going to work more or less well in-game as well. Yes, it's rounded - that comes from the gaussian blur applied to the thing, but to be honest I don't really see any obvious way to recreate the angular shapes of this kind of rocks just from the source texture alone. This result is what I would call "good enough"... but even better would be to make some randomized rocky ground mesh in 3d application, then make a height map based on that. Or make a laser probe that can minutely track the elevation differences of a surface, and use that to record some data from some actual rocks on the ground... and use that to make a height map.

But just for making a height map for rocky terrain, these include so much more effort that it's probably going to be better to just use the source texture and accept that the result isn't going to be perfect.


Now, I realize that the levels (range from darkest to brightest colour, as well as gamma curve) need to be edited so that the end result looks good in specific program use; in this case, IL-2 rendering system. However, the actual geometry of the height map should be retained as much as possible, and definitely not subjected to normal mapping in the process of editing.


Stuff for the mathematically inclined:

Height map can be consider a scalar field. Scalar fields have a property called gradient, which is essentially the partial derivatives of the field; for a two-dimensional scalar field, gradient H (height) has two components: dH/dx component (derivative by X axis) and dH/dy. When the gradient is zero, that means the RATE OF CHANGE in elevation is zero in either X or Y direction, so that will be interpreted as "flat" or "even" area. If the elevation is changing when you move along X or Y axis, then you have a non-zero gradient.

Normal mapping basically just interpolates these derivatives from the height map, and saves them as pixel values in two channels, ranging from negative derivative (values [0,127] on the channel information) to zero derivative (127 or 128 depending or both depending on implementation) to positive derivative (values [128,255]). So what you're actually getting is that a very high SLOPE on the height map will get either dark or bright values, regardless of their actual elevation. This is actually a classic case of losing information while performing derivative operation, and you cannot get that information back without knowing the integration constant... and actually it's nearly impossible to get height map information back from normal map once that step is done.

If all that just sounds like a lot of words, don't worry, this stuff is basically university level maths and is usually not handled in high school besides possibly cursory overview.

Finally...


I don't say this because I'm trying to step on anyone's toes or to insult anyone's intelligence. I made this post to help everyone get the best possible results from their modding, and to perhaps help clarify any misconceptions that might be going on in the theoretical side of all this modding, which might end up affecting the end results. If you have any questions, I'll be more than glad to answer them...

[agracier]

If all that just sounds like a lot of words, don't worry, this stuff is basically university level maths and is usually not handled in high school

I sometimes considered suicide when trying to make sense of high school mathematics classes ... and expressly choose a university field with no trace at all of that confusing and utterly depressing science ... ha ha.

Seriously though: since this is all so complicated it's beginning to look like a good idea to just forget about BumpH textures altogether. Making maps is so time consuming as is already, I can't imagine finding a step by step manner of implementing the above explanation.

I remember Uufllakke's method of making Bumph"s:

greyscale / invert / apply blur slightly / then brightness -58 with contrast -28

Now that is something that I can implement. But is it in any way a good method?

[carsmaster]

https://www.mediafire.com/?p1uyufyhay3tvsn

Here's my method of creating files BumpH.
Sorry, the text is in Russian.
My method may be imperfect.
But it is necessary make BumpH files without BumpH Earth looks very flat.

[Herra Tohtori]

I sometimes considered suicide when trying to make sense of high school mathematics classes ... and expressly choose a university field with no trace at all of that confusing and utterly depressing science ... ha ha.

Well, that was just a formulaic expression of what I said, in very specific terms, for people with the specific expertise to understand it.

You don't have to know all that to make good height maps or even normal maps. However, having a practical understanding of what a height map is, and what a normal map is, is definitely helpful in the process.

Seriously though: since this is all so complicated it's beginning to look like a good idea to just forget about BumpH textures altogether. Making maps is so time consuming as is already, I can't imagine finding a step by step manner of implementing the above explanation.

That's because source textures don't always have a direct correlation between brightness (intensity) and height (elevation of the surface).

In the sample texture, with the rocks being brighter than the terrain between them, such a correlation exists, so it can be exploited. In other cases, you need to look at the source texture and consider: Are these darker details potholes or protrusions?

A good example of this is to compare a ditch and a hedgerow. Both would probably be darker than surrounding areas in an image taken directly from above, but in a height map the ditch would actually be a dark area, while a hedgerow should be bright. A lot of how the map behaves when desaturated depends on what is on it.

The worst possible situation is when the source texture has shadows in it. Shadows appear dark, which makes them look like recessed areas in height map if you were to just desaturate the texture, but in reality they don't have such an effect on the geometry of the surface.

I remember Uufllakke's method of making Bumph"s:

greyscale / invert / apply blur slightly / then brightness -58 with contrast -28

Now that is something that I can implement. But is it in any way a good method?

It depends. It sounds like a very simplified method and it definitely will not work for all source textures. In some textures it works, assuming there is an inverse relation between brightness of the texture and the elevation of the terrain.

In other cases you would have to look at the terrain, form a mental map of what kind of elevation changes can be inferred from it, and then figure out a way to bring those elevation changes out into the height map, while (ideally) keeping false information at minimum (such as shadows causing holes in the ground).

Luckily, human eyes and brain are remarkably skilled at imagining such details, so you already have a very sophisticated comparison tool at your disposal.

All you need to do is to compare the end result to the source texture, and check if it makes sense. If bright areas in height map correspond to areas that you perceive are elevated in the source texture, it will probably work well and create the impression you want.

The worst case scenario is when the source texture has a mishmas of brightnesses at different elevations, making it impossible to draw any correlation between the brightness in the image and the elevation of the surface.

In some cases, it can be nearly impossible, or difficult enough, to make a GOOD height map from a source texture without manually editing parts of it.

If you have to resort to that, then it's a good idea to understand how gradients work on a practical sense, and how you can make different shapes in a height map by using gradient tools.

A linear gradient will create an even slope:



A spherical gradient will create an appearance of an upper halve of a sphere:



An inverted spherical gradient will create an appearance of a spire with round edges.

None of these shapes by themselves is very useful. However, if you combine a few of these, you can make more useful shapes, such as this...



...which is starting to look like something more of a terrain formation, but you don't really get much use out of it when it's "two-dimensional" like this. What you can do is apply the gradient in a radial mode, which will get you this (I applied it a bunch of times at different sizes to make a better impression):



And this gives you the following appearance when you bumpmap it:



...this can be an useful way to create the surface of a moon or asteroid, or perhaps to create the appearance of a field that has been bombed to there and back again. So, applying gradients like this can be used to create shapes on the ground (in this case, craters).

If you think this is a bit too clean and regular, you can apply Spread type noise on the height map and that will result in this:





...and now they suddenly look a lot more like craters on a dirt field with rocks and clumps of ground thrown every which way.

The question here is, is it a viable option to do manual stuff like this for height map creation? In most cases - no, no it isn't. You tend to get better, more natural results when you use source textures, and it it a huge time saver - with the stipulation that the source texture is suitable for height map generation. But, if you want to add some details (like craters) on some texture, or if you want to just manually correct some feature in a height map that otherwise works great - it can be done.

As Charles Babbage is quoted to have said:

On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

This is precisely the case here. If you want good results, you have to consider these things in the creation of the height maps. If you put garbage in (and by that I mean textures that are unsuitable for height map generation) you get garbage out, it's as simple as that.

I remember when I started working with textures on another game, and then height maps and normal maps were introduced as a feature, and I was very intimidated by how all that was supposed to work. It looked like black magic and occult sacrifices were required to gain an understanding of all this, but if you stick at it, and try to understand what's going on, you will at some point gain enlightenment and become one with the universe... or at least your height maps will be consistent and produce the result you intend them to produce.


As carsmaster said, BumpH maps are pretty damn good way to improve the detail in the terrain, but only if the details produced by the height map pass the automatic "does this make sense" test that our brain puts every image through.

If the height map is "wrong" in some way or produces nonsensical results, our brain will tell us this even if we're not directly aware of it. It becomes this nagging sensation that says "there's something wrong with this picture but I can't really tell what it is". Whereas, if bump mapping is applied in a way that makes sense, in ideal situation we don't even notice it's there until we are shown a comparison without bump mapping, and then the difference becomes quite obvious. Refer to this again...

[Avala]

Herra

I understand what you are talking (except the mathematic part, of course  ) and thank you for the thorough explanation. On the end it all depends on "does this make sense" and "does this looks realistic". You gave me some ideas. Its just that the way you are making bumph texture is a bit complicated for "average" map maker. Would be nice if someone could write some kind of script or action for gimp and/or photoshop, so that we can have bumph textures "on one click".

Agracier

Thats what I do too. I just add another layer for small ground features. Actually it's quite easy, you'll see. I am making small set of hi res textures, so they will have such bumph textures.


Carsmaster

I agree that the maps without BumpH textures are too flat. Your method is more or less classic method, except that at the end of the process you are changing the file to 8bit, and the usual way is to just make them grayscale. And the name of the file is very indicative  BTW, where do you find such good aerial photos for your textures?


Here is a little test that I made. BumpH textures "in my way" and in the "classic way" (mild and harsh version). TGA texture in 2048px 24bit, and TGA texture in 1024px Indexed (because I can't see 2048px yet). TGA 1024px indexed works in "the stock" version. All BumpH files works in every version of the game.

https://www.mediafire.com/?zao2h6n1lal2ezb