The A2A Simulations Community

OK, I'm rather baffled as to how you can add an extra row of pixels without mtt2's brain exploding. I was having trouble compiling a block of tiles last year, and asked keith to troubleshoot it for me. His explanation was



I had inadvertently ended up with an extra pixel in each dimension which was resulting in mtt2 barfing on the file. The difference compared to yours is that the extra pixel was in the magenta, but I just assumed that it would have had even worse fits if it was in the actual content region.

Right, the magenta can't have the extra row and column but the overlapping pixel on the right column and bottom of the land use image are key to doing this all in one go. Otherwise you would have to insert the pcx, move over slightly, pull it back out and insert again using the magenta to AA the seam. I've not found a way to get around having the magenta border so I have a pre-made action for photoshop to expand the canvas, add the color and crop the image to the proper size. The same is necessary for the height map too. To make the seams match I use a 3rd party tool which cuts up an image, duplicates the borders and exports it with the extra row and column. Actually the images prior to this are still small. They are only 512px and then exported as 513px. While I could resample in the 3rd party tool, I just have more actions setup for photoshop and run the entire batch of images through at once. Important to resample using nearest neighbor for the pcx though.

Here are two shots. The first show two 8193 px blocks. They share that one row of pixels and since they are duplicates (the rows) there is no fuss. For the second, I turned photoshop's grid on (set at 256px spacing) so that you can see that you can have an overlap. Keep in mind what is trimmed is the right most column and lower row of the magenta portion.....if I recall. It won't except the image if this is not removed. Perhaps that was where you had issues. Again Photoshop adds and does that for me so it is trivial. Final width for the image is 8704px. To clarify, the 256px magenta border is added to the 8193px. The addition of 512 px (256px per side) makes the image size 8705px. Then the right column and lower row are removed making it 8704px and tilable with surrounding blocks. Also note the 32px spaced grid made with the fake blue. As we discussed in the FT board, the landuse map is just resampled up so that 1 px now equals 32px. Again, I just have photoshop add the fake grid and save as index. Nothing pretty I know but you get to make use of that nice SRTM and generate a quick base map. Later you can go in and clean up areas where you'd need detail. Laying roads and rives requires deleting some things since you'd have to cross all those lines!! Would be great if they were added on top without adding the control points (vertex).

One clarification on something I said earlier so I don't confuse new folks. When inserting land the images themselves do not have the y axis reversed. It's just the reference map that is inverted. I shouldn't have showed the land use .pcx inverted. And, it is important to start in the upper left corner when doing it all together. You can either do it column by column or row by row (how I did it).

Cool! This makes me think that as long as the outside dimensions of the pcx are a multiple of 256, and top and left side have
256 pixels of magenta, and rest of the perimeter has an outer border of at least one pixel of magenta, one could perhaps mask
off any amount of the rest of the interior (with more magenta) and mtt2 would accept whatever wasn't masked for the compile.
Well, perhaps it would require a white dot in the upper leftmost corner of each tile in the interior...

I just found recently that I've had an error that didn't seem to be fatal, but announced "triangler failed at...". Everything compiled
alright, but when I pulled a new pcx out of the compiled terrain, the region to the lower right of the error location, extending only
in the index colour containing the error point, and only on that tile, had been replaced by magenta. I got three instances of this,
and the typical symptom is the colour region in question has an irregular outer border, and contains an island (legally connected
with a single line in fake) that also has an irregular border, and is a large fraction of the size of the outer region (for instance when
planting a wood within a slightly larger region of rough). I'm guessing it is a heightmapping error. Apparently mtt2 can't figure out
how to create polyhedron facets for the outer region which properly contain the inner region. The cure is to add more fake
lines anchoring the inner to the outer, so the outer region can be forced explicitly to be divided into several polygons. The exact
coordinates of the point attached to the error message don't seem to hold any significance, other than being within the outer
boundary, presumably being simply where mtt2 found itself when it first noticed the problem.

Anyway, I was surprised to see these irregular areas of magenta within the content section of the pcx, and it made me wonder
what would happen if I started playing with adding random blotches of magenta onto a pcx and compiling it. I haven't tried it yet.

Another question: how did you get the white dots to appear at all the intersections of your upscaled grid? If I understood
correctly, you generated the fake line grid by capturing a "drafting assistant" sort of grid generated by photoshop, and
merging it onto the pcx in fake colour. But that doesn't get you the dots - did you create a tile array of dots and do a batch mode
merge onto your pcx? ...Hmm, I guess if you could do that, you could as easily create one tile with both the fake lines and
the dots, and use that for the merge. Draw one 32 pixel box, copy, paste paste paste, copy result and repeat, expanding by
4x each step. 16 steps to 8192.

Naturally, I'm thinking these days about ways to automate the appearance of white dots on random curves (and how to turn
fuzzy lines into crisp 1-pixel wide ones). gimp has a scripting language, called script-fu or somesuch, and if I were a
programming wizard I might be able to conjure up such magic. I haven't actually looked at it, though.

I once tried to add areas of magenta to see if it would perhaps mask an area in the original pcx. I didn't get too far with it. I think I ran into problems but never kept at it. There is specific code devoted to magenta and it makes me think, like you, its use beyond borders is possible. Mtt2 code makes some suggestion about building list for them and so on.

Sorry, you are correct the fake grid had the white dots prior. You may recall me racking my head over why I couldn't use patters, well it was related to this. I do just as you suggest. I have a devoted 256 pattern that I can have repeat over an image. My thinking has always been that I could make all kinds of other patterns (field networks, etc) to cover large expanses of ground in an instant. Would be a much more capable landuse system it we went back to the area specific textures. Imagine that you also maintained the exact same control points where the tiles would overlap and you could alternate patterns creating seamless landscapes with no noticeable patterns.

The issue is and will always be the roads and rivers, shorelines etc. I've also looked for ways we could make a line remain one pixel when re sampled, but no success. I kind of get the impression from the code that when we compile and compress the we can use differnt images as long as we tell it when and where to shft reference images. Has any one ever tried to load a landuse pcx and a road pcx into memory then compile? Hmm I wonder. I can tell by looking at frace that there was a way to lay these lines quickly. However that assumes they (roads and rivers) are in the correct locations and not just made up.

Sorry thinking out loud. I'd rather have coding solutions for these things but since there is likely to be none anytime soon we will just have to get more creative with our paint programs.

Here is what I mean by using patterns to fill large areas. I quickly mocked up 2 256px grids depicting fields. They can be arranged together to quickly fill regular blocks of land. Here the two images joined could cover 512px of land. If you added a more, inverting x and y axis, I think you could quickly work together a large tract in a matter of minutes and it would be a much better presentation since you'd have real physical hedgelines or what ever type field border you'd want. A set of realistic looking tilable textures (actual field types like wheat, plowed etc ) add the proper corresponding detail maps and it's look good. That's just my opinion though What happens with the heightfield is another story. I don't know how it'd match up against SRTM, not too good I would imagine? The reason mountains look right in Burma is due to the regular (fake 32px) grid.

Just brainstorming here ,as I think we are really at a crossroads with the terrain engine. While the new high rez textures are leaps forward from what we had, they are at the same time too limited. Expanding the pallet would help that, but imagine the possibilities of all those land specific textures!

Replying to a lot of posts in this thread:

@Rummy
I agree initial height editing, say flattenung of airfields, fixing SRTM bugs


@PV
Pete, very nice screenies.
One looks at the Bo screenie first and thinks - looks nice but a real cliff has a different shape - then you have the RL pictre and the cliff at that point has that shape.

@Rummy
Re batch files:
Yes, I used them as well in my aborted attempt at Malta.
Basically you can proces as many tiles in one go as you want, but processing them gets very slow when you main memory flows over.
IIRC for me the "limit" was the memory GIMP needed. IIRC I used 40x40 tile, which is almost exactly what Rummy uses. Much mire and my then memory
(IIRC 512 MB) overflowed and it started swalping to disc like mad.

Rummy, GREAT picture!

BTW does someone have a "water world"? I think often the easiest way to create a new terrain is start with a terrain made up completely by water.
I did create it for Malta, but am too busy to search for it unless really needed

Re number of landuses: Like I said before, OToneH the limit of "128" is quite strict, OTotherH we could save some rotations and get new landuses that way.
But that is more for a new terrain trhan the existing one.

Rummy, I was looking at the expanded landuse pixels for burma and trying to think of a simple way to make the borders
not be straight lines. I have no clever ideas - it's easy to substitute meandering lines in the grid pattern, but then how do
you alter the landuse block to follow the new border?

On the general subject of creating random-looking tilings for large regions, I looked briefly at penrose tilings to see what sort of
potential they have - I think if a renderer was built from scratch to use them, it might work fairly well, but no way I could see
to use them with our system. I was also surprised to see that Penrose has copyrighted the tiles. And in truth, to me the examples
of the tilings look only barely aperiodic.


By strict, how much code rebuilding are we talking about to knock it open? 5000 lines? A manyear? If we crowbarred a 2-byte
landuse designator into the system, how widespread would the knock-on damage be that would have to be fixed to make it work
properly?

Meant to comment on this last night, but I ran out of time.

Have a look at the map tiles for the different 2D maps in the six map folders (map16, map32, etc). I am almost certain the higher
res ones were generated using mtt2 somehow. I have a simple idea to sort of do the same thing to update the maps for France to
reflect the new terrain, basically by extracting a pcx but with a custom made colour palette with colours lifted from the high res 2D
map. However, Rowan's 2D map regions aren't just made in solid colour, each landuse type has a little decoration, like a bush
or a clump of grass, dotted across it. I have not the faintest idea how they managed to get mtt2 to do that.

Never thought I'd be doing software archaeology....There are some small programs in the mtt2 source I think might do what you describe. Same with the GRD files. If you convert them to an image you can see almost twice the amount of land shown in game. I think this is from the real world landuse data they used at the time which appears to have covered much larger expanses of land. The radar sites must also be generated this way? When I convert them to an image you can see the range rings....Oh to have a manual for this. I know the program can do more than we know but trying to reengineer it is too frustrating. I'd rather be making maps!!! That said prior to compression what does the landscape format look like? Is it just an ascii grid and file? If so, producing that outside of mtt2 would be easy.

It's funny as I sit and type this a script is running in the background to convert simple X,Y, Z LIDAR collected data into an ascii grid so that I can convert it to a raster to use in Arcmap. It is also producing topo lines for me at the same time.

Wow. Topo maps with no other content would be fantastic to have. If the lines are continuous, and distinct from each other,
you could select them individually in your image editor, and colour them each with the corresponding BoB tga heightmap colour.
Then a separate copy with them (if they are one pixel wide) coloured in fake colour, could be merged onto a landuse pcx. Then
all you need is a grid, which you merge additively on another copy of the topo map, so the points where the grid crosses the topo
lines all have a unique colour from the addition. Select and recolour those to white and lay them back on the pcx as white dots, and
you've got a fully anchored topo heightmap and pcx pair.

...I was I think the first person to discover, at least to announce, anyway, that altering the numbers in the recipe for generating
the BoBWorld.pcx would yield a version with a larger world. This is what led me to think that playing with the commands should
generate the 2D maps. I guess you must have to have a set of img textures to get the patterns on each landuse type, but
I find it unlikely that they didn't somehow use mtt2 for it - after all, they seem to have crammed every other terrain function
they needed to use into that one tool. However, I tried all sorts of likely combinations of parameters to get new stuff to plot out,
(for instance analogs of the BoBWorld recipe applied to the highcol.grd file), and all I ever got was error messages of the form
"no handler for" or similar.

What command do you use to get the radar ranges to plot out?

Sorry was offline for a while and missed this. Generating topo lines from SRTM or any other height source is not that hard but there is likely to be some "islands" in the mix. You can attempt to filter them out though. Also keeping that 1px width requires doing areas where you wont be scaling up.

I like the idea a lot and think you are on to something with the overlay. I was just about to do a quick process for the new project, afterwards I might try topo lines again.

Doh, my old ISP finally caught on that I was using their space 2 years after I left . Anyway, back to the contours, I have managed to find a free application that can convert dem to topo lines. While I can do the same with Arcmap that doesn't help others. Auto dem can manage a few type of formats for dem and after converting the dem to contours and the back to dem as a raster you can successfully export 1 px topo lines or points. These still won't work without cleanup, but it's a start. In pic below I have converted a block of land to contours and loaded into photoshop. You can also in Auto dem edit the color pallete, not messed with that much. I can say from the Wake Is. test that coloring these areas is easier since you can use a paint bucket set to contiguous and in all honesty most major land types are a product of elevation, annual rainfall and distance to stream. Cultural Landuse is a whole other ball of wax.

http://www.autodem.com/

Wow. Very hot stuff. This can allow very fast and fairly well behaved heightmaps using the procedure I outlined above. Will play with it for my next height work (in a while - I'm forcing myself to work on the tutorial update at the moment).