[6S.Maraz]

Hi, I am getting this problem where the edges of the big square blocks of map_c.tga join:



I have tried to sharpen map_c, to soften (blur) the edges, but got no positive result.
Any idea of how to overcome this problem?

Thanks
Maraz

[Vpmedia]

If you want you can send me the original source before compilation and I can make an attempt to compile. Iirc there are only horizontal slice so I dont really understand what I see now.

[asheshouse]

This is similar to what I am getting on the Northeast France Map.
I think it is due to map_h not map_c.
I have been successful in smoothing out some areas but still have a lot to do.

Problems occur because of the difference in pixels between map_h and map_c
Some areas you can see an obvious shift in the pixel position on map_c and can correct it by editing map_c.

In other areas it has been necessary to lower map_h by a small amount to get it to look right.

However I still have a lot of this sort of flaw to correct so I will be watching this thread with interest for other comments.

[6S.Maraz]

If you want you can send me the original source before compilation and I can make an attempt to compile. Iirc there are only horizontal slice so I dont really understand what I see now.

Thanks. You have a PM!

I think map_c is made of square blocks, only blocks containing land are shown in the map. This may be not evident when your map is all land, but if you have islands that is clear.

Maraz

[asheshouse]

Have been looking at examples of this again today but some I cannot solve.
There are no obvious flaws in the original MWmap_c at the locations, but the "tears" seems to coincide with the 200m pixel spacing, not the 50m map_c pixel spacing.

The tears seam to be orientated both north south and east west and to be at 32pixel spacing (6.4km)

I think the map_c.tga is compiled in 32 pixel blocks, which if correct is a bit of a coincidence.

Is the compiler offsetting the map_c by 1 pixel (50m) in error?

[MiWa]

How about the original maps, like Crimea for example? Are such features present if you use the tool on original map_c (create full map_c then chop it)?

I mentioned this earlier, but it wasn't noticed. There is another set of maps, which resemble map_c. They are almost identical, but seem to be using more shades of grey. I believe those maps are used by the engine because even the new maps from the latest patch come with those 'extra map_c'.
Maybe, those are responsible for this effect you are observing?

I'll post more details on these mysterious maps later when I get the data I have on another computer.

[Skunkmeister]

Apparently this texture tearing phenomenon is also causing problems with treed regions too:

[Thirdeye]

That pic looks familiar... :lol:


I have been seeing them when in the lowest FOV mode. They are less noticeable when in Full FOV, so its something with the draw distance possibly. Also the "boxs" of tree texture can seem to be a different color from the rest of the trees at times. Its like the box is darker than the other trees around it.

[6S.Maraz]

How about the original maps, like Crimea for example? Are such features present if you use the tool on original map_c (create full map_c then chop it)?

OK I made a test with the Crimea Map: compose, disect and again compose. And SURPRISE! this is the result (4x enlarged portion of composed map, for better visual evidence ):



There are some artifacts also on this map: pixels are repeating each 32 pixels. So I thought
that there could be a bug in the Map C tool who repeated the pixels and caused the artefact.

But loading this map in the FMB, it's perfect, no artefact can be seen!

Also my Malta map that shows the texture tearing doesn't have this problem of repeated pixels. So it's not the map C tool that causes the repeated pixel.

I checked another map of the game, Kurland, and even this map has the repeating pixel every 32 map_c pixels.

So, EUREKA!, the repeating pixel is not the problem, it's the solution !!!

Surely there is a limitation in the game engine, that cannot interpolate between adjacent 32 pixel-cells, so that the pixel between the two cells must be the same.

So the request is if it's possible to modify the map-c tool in order to repeat the same pixel at the border of each 32-pixels cell.

Maraz

[Skunkmeister]

A repeating pixel every 32 pixels would make sense, since map_C's size has to be in multiples of 32 in order for the game to recognize it.

[FA_Cheech]

~S~6S.Maraz,
Nice piece of detective work.

[6S.Maraz]

I copied manually the pixels every 32 rows and every 32 columns to the adjacent row/column, and I got rid of all artifacts.
A tool to make that automatically would be welcome, manually it's only feasible for small maps

Maraz

[FA_Cheech]

I copied manually the pixels every 32 rows and every 32 columns to the adjacent row/column, and I got rid of all artifacts.
A tool to make that automatically would be welcome, manually it's only feasible for small maps Maraz

Is anyone working on a tool to solve this particular issue? We will definitely need it for a map the size of "The_Slot".

[6S.Maraz]

I copied manually the pixels every 32 rows and every 32 columns to the adjacent row/column, and I got rid of all artifacts.
A tool to make that automatically would be welcome, manually it's only feasible for small maps Maraz

Is anyone working on a tool to solve this particular issue?

In a word: yes.

Maraz

[FA_Cheech]

I copied manually the pixels every 32 rows and every 32 columns to the adjacent row/column, and I got rid of all artifacts. A tool to make that automatically would be welcome, manually it's only feasible for small maps
Maraz

Maraz, is there any news on this? The_Slot is way too big to use the manual method. If no current solution, is anybody out there working on a tool to do this automatically? If not, can one of you graphic-smart guys look into it? IMHO this is one of the few issues that absolutely needs to be resolved. The_Slot is just too nice to be marred by this issue, and we could really use some help on this one.