Aces High Bulletin Board
General Forums => Open Beta Test => Topic started by: artik on May 05, 2016, 04:17:58 PM
-
Hello,
I released makeahmap version for AH3 - it is very basic version - work in progress
http://cppcms.com/files/makeahmap/makeahmap-1.1alpha.zip
it does:
- Elevation with higher accuracy using SRTM3 - for newer model (vastly improves visual appearance)
- Sea and lakes set to altitude -100 so it isn't best right now
What is missing:
- Globcover support for automatic terrain type mapping
- Rivers in new model
- Proper non-0 altitude lakes
Known - Issues
- Some issues when two land objects are close sometimes water removed (like Suez)
- GTOPO30 does not work (source is gone and I can't find a new one)
For instructions please refer to older version: http://www.hitechcreations.com/wiki/index.php/Terrain_Generation_From_Geographical_Data
Also currently you only case use clipboard map and elevations are imported using signed RAW image file
-
Will this eventually be able to reproduce road and train track systems if they are included in the source material?
-
- GTOPO30 does not work (source is gone and I can't find a new one)
You mean the utility to read and convert 30 arc terrain? or is it because the data set is so large?
-
Yes, even the mirror site in Japan has removed them. The package has been replaced by several versions of better data.
I'll try your newest one shortly.
-
Artik:
I've implemented GlobCover in my program. I've noticed that it creates distracting banding in mountainous areas as AH3 apparently ramps through all the intermediate terrain types between two chosen for adjacent "pixels" (see attached image). I don't have a solution. Do you have any ideas?
I've also toyed with the idea of trying to morph the entire altitude file to make all water (say from GSHHG) at -40 alt by subtracting some 2D polynomial fit, or perhaps multiple Gaussians. That would be a lot of work and the negative alt = water feature doesn't like to make narrow watercourses; they get pinched off (happens to a lot of my coastline estuaries). I think I'll just wait for Hitech to implement rivers and polygon lakes.
The increased resolution of the terrain alt file, from SRTM3, really improves terrains doesn't it? It especially improves tanking as there is finer scale topography to give gullies etc. to limit sight range.
-
On my end, the program choked in two areas, so far.
At scale values of 2.5 (not a good idea in srtm3 but sometimes necessary) it failed somewhere in the download/conversion process and
At gshhg-bin2.3.5.zip it Failed to rename file ./temp/tmp.zip.part to ./temp/tmp.zip
-
Will this eventually be able to reproduce road and train track systems if they are included in the source material?
No I don't have historical datasets of roads
Yes, even the mirror site in Japan has removed them. The package has been replaced by several versions of better data.
I'll try your newest one shortly.
To be honest it isn't that critical as srtm30 integrates some of the gtopo30 in the areas where srtm coverage does not exist (like Murmansk area)
I've noticed that it creates distracting banding in mountainous areas as AH3 apparently
ramps through all the intermediate terrain types between two chosen for adjacent "pixels"
Probably you scale the image instead of resampling one
It worked for me fine with ah2 I'll see how it goes with AH3
regarding rivers I want to use existing track system also not got to it yet
At scale values of 2.5 (not a good idea in srtm3 but sometimes necessary) it failed somewhere in the download/conversion process and
At gshhg-bin2.3.5.zip it Failed to rename file ./temp/tmp.zip.part to ./temp/tmp.zip
Probably I need to clean the temp directory on startup so if previous download failed it wouldn't mess with new one.
Regarding choking, what do you mean, stuck? Probably some internet related issues
Maybe I'll change the model in future so I'll keep the original zip files and use them directly so it would be possible to download all manually as well
-
By that I meant I was forced to hit Enter after "Failed to rename file ./temp/tmp.zip.part to ./temp/tmp.zip"
It seemed to continue without error if I manually downloaded and unzipped the missing srtm files to the data folder, at least until it hit the ghhs files. My gshhg files are custom so I couldn't just copy them over. I appreciate that the program downloads all the srtm files necessary without user attention and faster then I can do the downloads manually.
btw, I'm using an SSD drive so it might work better if I moved your prgm to regular hard drive?
-
Probably I need to clean the temp directory on startup so if previous download failed it wouldn't mess with new one.
Removing that file allowed it to run again until the next time it reappeared.
The community is going to owe you a huge debt when you're done.
-
Aplha 1.2 released
http://cppcms.com/files/makeahmap/makeahmap-1.2alpha.zip
- Fixed water slope handling
- Fixed water channels between land areas
- Now temp directory is cleaned on startup so in case of download fails program can just run again
- Added options:
lake_alt_limit - maximal allowed lake altitude - so it would be removed rather then brought to sea level
lake_or_island_min_size - minimal size of lake or island if it is smaller than this it is not rendered
water_to_land_slope - the slope the altitude rises from water
--------------------
I want to get to GlobCover
Now I have questions regarding splat files... quoting hitech
The texture type file (now called splat) is export into a 32 bit bmp
The R channel defines the small texture type. (0 = type 0, 16 = type 1, 32 = type 2 ...)
The G channel defines the Large texture type (0 = 0,64 = 2, 128 = 3 192 = type 3)
The B channel is a blend factore between the 2 types, this is normally always 0 or 255.
1. What is the difference between small and large texture type and why do we need them/how do we use them?
2. The types are the same as in AH2 or we have more/different (see below)
3. Why for small it is multiple of 16 and large of 64 or for no reason?
4. When we do blending?
/ ntt0000 Deep water ntt0000 will always be deep water (This is a greyscale BMP designed to vary the water over distances)
// ntt0001 Grass
// ntt0002 Forest 1 (evergreen)
// ntt0003 Forest 2 (deciduous)
// ntt0004 Farm 1
// ntt0005 Farm 2
// ntt0006 Rock
// ntt0007 Swamp
// ntt0008 Rocky Grass
// ntt0009 Sandy Grass
// ntt0010 A Beach
// ntt0011 B River bed /
// ntt0012 C Snow / Coral
-
I think all of this is covered in the new Terrain Manual (http://bbs.hitechcreations.com/smf/index.php/topic,376440.msg5034382.html#msg5034382) except #3 which is so you can visually detect the different colors in the splat map. I don't know why one is 16 and the other is 64 other then it allows sharper differences for Atlas 1 which is the most important set in my opinion because it can fix problems between tiles in Atlas 0 tiles.
Look for "The Terrain Tab" in the index.
-
Artik: There are 20 texture types now (for each texture set). 16 small ones, i.e. 0 through 15, which get multiplied by 16 to create the Red channel, and 4 larger textures, 0 - 3, (mostly farmland for Europe texture set) which get multiplied by 64 to make the Green channel, and then the blue channel is 0 to select the small texture or 255 to select the large one. In my program I label these 0 - 19* and map them to the GlobCover indexes as shown in the attached file. For some I used secondary criteria: for example I map GC "bare" to sand if the alt is below 1500 m or to rock if it is above. This prevents sandy areas in the Alps. (In no way do I claim my mapping is in anyway good, but I attached it just as an example of one mapping for the default European summer texture set.) Obviously, if one is making their own texture set then they would design it to match GlobCover better. My program then exports to a 32bit bitmap and that seems to work fine with AH3.
The default texture sets are designed so that increasing texture index is used for increasing altitude (i.e. sand is 0 while snow is 15). When two textures are next to each other and are not consecutive, say texture 4 next to texture 9, then AH3 rendering engine ramps through all the intermediate textures in the area between them, ie 4, 5, 6, 7, 8, 9. So when you use GlobCover to make texture choices it's possible, in fact likely, that adjacent textures will differ by more than one in the texture index order and that leads to some visible banding (like the example image I posted earlier). I've started doing some analysis of the GlobCover texture connectivity stats to see if I can reduce the banding by just rearranging the order of AH3 default textures (which would require making a custom texture set).
*i.e. 0-15 are the small textures and 16-19 the four large ones (only useful for understanding the attached file).
-
I used this data for mapping in AH2
https://github.com/artyom-beilis/makeahmap/blob/ah3/groundmapping.csv
Now there are more tile types and what is most missing is general description of the types what is that
The automatic banding is really unfortunate it may hurt the conversation
If it is OK for you I'll start from your table as reference
Also what is really missing is urban area
-
Now there are more tile types and what is most missing is general description of the types what is that
The automatic banding is really unfortunate it may hurt the conversation
If it is OK for you I'll start from your table as reference
Also what is really missing is urban area
Your welcome to use my table if you want. I've attached a transcript of my scribbled notes describing each texture that I used to decide on my table in case you want to make your own. One depressing thing I noticed in the data is practically every square inch of Europe is either urban or farmland. Lots of tile types end up at like 0.3% usage while the majority are some form of farmland.
Regarding the urban areas (of which there are a lot) I was planning on dropping AH3 City objects liberally on top of the areas marked urban (Easyscor: can each country on a map have more than one City?)
-
Regarding the urban areas (of which there are a lot) I was planning on dropping AH3 City objects liberally on top of the areas marked urban (Easyscor: can each country on a map have more than one City?)
Sure. One of the SEA terrain has so many it's exceeded the 50k object limit, but don't do that because those excess objects above 50k probably don't work right. Unlike MA terrains, the real world terrains have a need for more city place holders and 'targets' as opposed to a working strat. With so many cities and factories, the field objects are bound to rebuild at their fastest rate even without strat disabled in the Arena Settings.
-
btw, it's almost trivial to mix and match the existing ground types so long as you keep them in the same Atlas by size. If you like ETO's Rock better then MED's it takes only a few minutes work to build a frankinstine set.
It's creating artik's 3D(?) urban ground tile that would be a problem imo because we don't have enough variation in speedtree buildings and I'm unsure whether it might kill frame rates. USRanger or Greebo could probably create a semi realistic urban tile using textures and bump mapping but they are tile and skinning gods.
-
btw, it's almost trivial to mix and match the existing ground types so long as you keep them in the same Atlas by size. If you like ETO's Rock better then MED's it takes only a few minutes work to build a frankinstine set.
So you're saying it would be easy to just reorder the existing European set into a different order to try to reduce banding when using GlobCover data? I'll have to ask you how to do that if my analysis shows that a reordering would reduce banding enough to be worthwhile.
-
I fear I have forgotten to check on the speedtree objects. Although the textures can be reassigned easily, it might be necessary to build your own object files until htc releases the final versions. I haven't checked to see if the object files are available in the latest release.
-
Simply edit the atlas zero and Atlas one. Text files
-
Will the trees and building carry over in that scenario? I've been a bit busy the last two months and I don't remember checking.
-
Turns out reordering the tiles doesn't really help much; reducing banding in one area increases it in another. Best I could do is reduce it from 2.7% to about 2%. (That number is the percentage of neighbors of texture pixels that differ from the center one by more than 1 in the index, and would therefore cause some amount of banding.) I might still try it to try reduce banding in the Alps.
Of course I didn't use a very sophisticated optimization routine; I just looked for the pair with the most likelihood and swapped it with the index-1 and then just kept iterating. Someone with more clever mathematics might be able to get a larger decrease.
-
715: I assume you also know how to deband by going small tile ,big tile x2, then back to small tile?
HiTech
-
715: I assume you also know how to deband by going small tile ,big tile x2, then back to small tile?
HiTech
.
Yes, but that isn't a good solution for mountains. All the big tiles are farmland with roads which won't look good on mountainsides. I suppose I could make one custom generic mountain like big tile for that use. Or perhaps reorder the top tiles to better match Globcover in the mountains and use the big tile trick at lower elevations. However, the big tile trick will significantly reduce resolution as a one pixel transition gets turned into three.
-
From the manual:
The Keep Current Merge Type Check Box:
This tool can force a blend that eliminates the texture banding clash between two textures that are placed "out of the type sequence."
Study the image on the left to see the tool's resulting application.
The Red Type is Atlas 0 Type 0 and the other is Atlas 0 Type 15. Without adjustment, there are normally 14 intervening bands of texture between these two types.
By using the Merge tool and selecting Atlas 1 Type 16, you'll achieve the best blend by painting over the two banding rows. However, if you choose Atlas 1 Type 19, the three Atlas 1 bands, 15 to 18 will show.
(The RGB values are provided for Splat Maps.)
...
Yes, I agree Atlas 1 Type 16 might be more useful if it were a neutral tile rather then the Farm Mosaic.
-
Does it have to be two big tiles between two small ones or will one do the trick?
-
Does it have to be two big tiles between two small ones or will one do the trick?
Two, because the remissive small type needs to change under the domination big type.
B is big S is small
so you will have S1 BS1 BS2 S2
-
OK, I didn't understand that, so there's a good chance I don't know what I'm doing. When I export the SplatType.bmp if the pixel uses a big tile (Green channel) then I just set the Red channel to zero and Blue channel to 255. Is the Red channel supposed to have something there in that case, say the last used small tile value?
-
OK, I didn't understand that, so there's a good chance I don't know what I'm doing. When I export the SplatType.bmp if the pixel uses a big tile (Green channel) then I just set the Red channel to zero and Blue channel to 255. Is the Red channel supposed to have something there in that case, say the last used small tile value?
as the shaders sample the splat texture the system does a linear interplate between the samples based on the pixel position it is drawing.
Consider the following 2 pixels and all the pixels in between.
Left side is on vertex 0 right side is on vertex 1
R is small type
G is big type
B is the blend factor
0 0.25 0.5 0.75 1.0
R 255 255 255 255 255
G 0 64 128 192 255
B 255 192 128 64 0
With these 2 pixels at 0.25 it would be mixing 75% of small type 15 with big type 25% big type 2 (small 0 - 15 & big 0 - 3)
so if you want a clean transition you need it set up with both big an small the same on both pixels and only the G channel changing
R 255 255 255 255 255
G 0 64 128 192 255
B 255 255 255 255 255
Now it will always be mixing small type 15 and big type 3 and the transition will be smooth.
This is not something I specifically do , it is how shaders work when sampling between pixels.
HiTech
-
OK, thanks. I don't have a clue how I'm going to program that, especially in 2D, but I'll think of something (that'll probably be wrong ;) )
-
OK, of discovered a major issue with elevation map building and shoreline integration
I need to redesign this part otherwise all shores will look badly
Back to keyboard, the globcober will wait (also initial globcober model is working)