Print

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

[Stainless]

Satellite images also have the problem of shadows/clouds/etc. being part of the texture - AFAIK there is no publicly available imagery that has been corrected for those issues.

  yes there is.

Though you do get problems with transients








However if that's what you want, I will see what I can do.

[slibenli]

On the normal downloads i get a folder called #SAS which i rename to #WAW to use in my CUP install - does the new autoinstaller do away with this requirement slibenli? Nice to see u back 😊

That one would only be necessary for a feature which I never activated 

[slibenli]

Satellite images also have the problem of shadows/clouds/etc. being part of the texture - AFAIK there is no publicly available imagery that has been corrected for those issues.

  yes there is.

Though you do get problems with transients

However if that's what you want, I will see what I can do.

But there are building and tree shadows 

Anyway, just a height map would be a good starting point. Until there is a better solution I can use the type map generation code that I already have.
And a coast line and river map would be handy - although not necessary (using terrain elevation <= 0 as an approximation instead).

[Stainless]

So my code at the moment has a couple of bugs in it.

• Height encoding
• Map size

The height mapping from meters to byte is wrong, I need guidance from you guys for that.

The tool was designed for huge maps, it is too easy to generate an IL2 map that is too big and the app just runs out of memory.

The type map is a bit of an issue as well. the best I can get is 0.1 arc degrees



My code works very differently. I takes one degree SRTM data and generates 1 minute textures.

Three textures for each minute. Height, Normal, and Diffuse.  Encoded into the diffuse is the distance from the nearest sea for wave generation.

So I end up with something like this, the rendering needs work but you get the idea.






So if you can decide what you want for height encoding (or just tell me exactly how IL2 maps height), tell me what limits you want for sizing the maps,  and show me your type encoding code, we might be able to create something.

[slibenli]

I'm thinking of a height map / etc. that is read exclusively by il2ge, in addition to the proper IL-2 map.
It would then blend those together.
So the the restrictions for IL2 maps in terms of size and height encoding don't apply.
I'd favor the height being encoded in meters (e.g. 16-bit TIFF could do that).
As for the map size - the bigger the better I'd say - 3000x3000 km would be nice.

Edit:
So with a resolution of 200 meter per pixel that would be a 16384*16384 image.
Hmm, maybe a bit too big.
Tiles instead of a single file would also work.

Edit 2:
I'd leave the type map problem for later.
The code dealing with that is a bit scattered across the source tree
As for generating a type map from height data:
https://gitlab.com/vrresto/il2ge/blob/master/common/map_loader/map_generator.cpp#L66
But that's just a pretty random quick hack 

[Stainless]

So we need to talk about a couple of issues.

1) Coordinate system.

     I use latitude and longitude. Each 1 degree square is a directory which contains the textures for each 1 minute square of terrain. So 60 * 60 terrain patches for each degree of latitude and longitude.
     This doesn't fit with IL2 at all. So for me to generate something you can use I need to know the projection used by IL2.

     The reason this is so important is 1 degree of longitude is not a constant distance, it varies depending on latitude.

     So if you say to me you want a map from latitude, longitude 4096 pixels by 4096 pixels with a fixed size of 200m per pixel I can do it, but adding anything to the map based on latitude, longitude is going to be a nightmare..   I can give you functions to take latitude and longitude deltas and convert to another coordinate set as long as you define the coordinate set for me.


2) Type textures

    We have 16 terrain textures to play with if I recall the map system correctly.
    So If we agree an arrangement of these textures I can merge the land type date and terrain data to generate a type map.
    water - > sand -> grass -> rock -> city      gives us something like 3 textures per terrain type.


Let me know what you want


     

[slibenli]

1) That's indeed a problem.
IL2 itself doesn't use any projection - one pixel on the height map = 200x200 m in the game. AFAIK latitude/longitude isn't used anywhere in the game.
So it comes down to what projection was used to create the height map - which probably varies between maps. I have to look into this.

2) It's 32 textures (https://gitlab.com/vrresto/il2ge/blob/master/common/map_loader/map_loader.cpp#L81).
But a type map with less types would be still be useful - I would take care of mapping these types to IL2 specific textures.

[WxTech]

IL2 maps are essentially of the Mercator projection, or a variation thereof. That's why everywhere on a map north is oriented exactly up, even for a large map located at a high latitude. In other words, all IL2 maps treat lines of latitude and longitude as always straight and orthogonal. The SRTM data we build our terrain upon is built is typically presented as something like a Mercator projection.

If one desires a map covering considerable area, especially at a high latitude, and have minimal distortion at the same time, there would then have to be a way to handle the unavoidable non-parallelism of lines of longitude. And of course the curving parallels, or lines of latitude.

[Stainless]

Yes, what i do at the moment is treat the height data as a virtual texture.

For example, say the height data is 1000 elements wide and represents 1 degree of longitude. I calculate the width in meters of one degree of longitude at the current latitude.

Then when I am building the IL2 map, I index in with the distance in meters instead of the pixel index.

This way if the sample point is in between two data points , I can interpolate the height value and get something more sensible. I can also handle high latitudes easily as i can just go off the end of the data into a different height data file.

The key thing is this would be a pain in the proverbial if you needed to use latitude and longitude to place something like a map marker or an airport

[slibenli]

If existing IL2 maps use a Mercator like projection (I checked the Banff-Narvik map and it looks like Mercator, but others might use an Equirectangular projection) then distortion is an issue already anyway.
In any case - to extend an existing map, the same projection has to be used.
So I would be nice to be able to select a projection for the generated map.

As for the map size - 3000x3000 km might be excessive. It should simply be enough that you can fly near the proper IL2 map border and not see the border of the extended map.
How big are the biggest IL2 maps currently?

Edit: New Guinea seems to be one of the bigger ones (900x500 km).
So let's assume a 1000x1000km map. Let's also assume that a pilot might want to fly 100 or so km beyond that area, at an altitude of 20 km, without seeing the landscape border.
At 20 km altitude, the maximum visibility (including mountain ranges that are partially below the horizon) is ca. 800 km.
Then the extended map would need to be 2800x2800 km. Actually pretty close to my initial guess 

[slibenli]

I forgot to mention: the latest builds have a new feature which can be enabled with

Code: [Select]

EnableTransparentShader=1 in il2ge.ini.

Expect a FPS drop.

Before:


After:


Before:


After:

[Stainless]

Edit: New Guinea seems to be one of the bigger ones (900x500 km).
So let's assume a 1000x1000km map. Let's also assume that a pilot might want to fly 100 or so km beyond that area, at an altitude of 20 km, without seeing the landscape border.
At 20 km altitude, the maximum visibility (including mountain ranges that are partially below the horizon) is ca. 800 km.
Then the extended map would need to be 2800x2800 km. Actually pretty close to my initial guess 

Yes that's why you need some form of patching and level of detail.

So if I write something that has....

1) Start coordinate (Latitude, Longitude)
2) Width in pixels
3) Height in pixels
4) Scale in meters ( e.g. 200 m per pixel)
5) Projection

And outputs a raw texture with 16 bits per pixel as height in meters, is that good enough?

Or do you want something a little more sophisticated?

Have a header that contains ....

short MinHeight;
short MaxHeight;
fixed Scale;

To allow you to have better than 1 meter accuracy.