Surface _mco textures aren't actually used by ARMA 2, only the middle ground _mco is.

[ianbanks 30]

The surface type _mco files are referenced in the layers.cfg file that Visitor takes when importing the map and mask:

class Layers
{
 class t_grass
 {
   [b]texture = "test\testmap\t_grass_mco.png";[/b]
   material= "test\testmap\t_grass.rvmat";
 };
};

However (as far as I can tell) they are ignored by both arma2.exe and arma2oa.exe. The only _mco file that is rendered is the middle ground .mco, which is specified in the Island config.

Chernarus has some surfaces that have proper _mco textures, but they aren't actually ever rendered. Utes doesn't even have dummy _mco files, which makes me think that perhaps the shader was changed during the development of ARMA 2. The new maps in OA don't have proper _mco's either; they use a grassy _mco for all of the desert surfaces. :)

If you don't want the dummy files in your own maps (I think most of the sample maps have them) you can delete them and change your layers.cfg to this:

  class Sand
 {
   texture = "#(argb,8,8,3)color(0.5,0.5,0.5,1)";
   material="layertest\data\sand.rvmat";
 };

This is what is done in Utes and is also used in the BI Wiki.

You can confirm all this yourself by looking at one of the tile rvmats in the layers directory. Each rvmat has the following textures, in order:

1. The sat map,
   
2. The sat mask,
   
3. The first _mco from your layers.cfg,
   
4. Surface 1 _nopx,
   
5. Surface 1 _co,
   
6. Surface 2 _nopx,
   
7. Surface 2 _co,
   
8. ... down to Surface 6.
   

The DirectX shader for terrain only takes 15 input textures (ignoring the stencil) so there simply isn't a way to have an _mco for each surface type. (Also, this is another reason 6 surface types per tile is a hard limit).

Also, regardless of what you put in the 3rd slot (_mco one) ARMA simply overrides it and passes in the middle_mco from the island config. I've confirmed this by using the Direct 3D debugging tool. I also checked all of the drawing calls from a whole frame and haven't found any that reference the surface _mco files.

[gammadust 12]

Again, very interesting. I do think that an additional detail texture at the surface level, would become redundant.

The detail (mid range) texture, the one which is actually used, does help since it's scale (6x times the in-game surface size meters - on stratis) helps mixing and breaking the similarities at small distances between surface tiles (1,33m repeating). Having additional detail at this scale via a secondary texture is the same as pre-baking this detail on the texture itself, and unburden the engine with that calculation. If we gain the ability of more textures in the process... all the better.

But, i have to hand it to you, great work, this info should help a lot of mappers around. I do know how fun it is to "hack" the inner workings of the engine ;)

Edit:

BTW, do you know of any way to modding the surface textures without having the need to compile the whole map in visitor?

Currently i only know how to change the default surface textures via overwriting the files themselves. We should be able to do this via config, but apparently these textures paths can only be specified via the CfGLayers, which afaik are inaccessible after compile.

Edited November 15, 2013 by gammadust

[ianbanks 30]

Edit:

BTW, do you know of any way to modding the surface textures without having the need to compile the whole map in visitor?

Currently i only know how to change the default surface textures via overwriting the files themselves. We should be able to do this via config, but apparently these textures paths can only be specified via the CfGLayers, which afaik are inaccessible after compile.

From what I know of the process CfgLayers isn't retained. The two texture paths that you specify in each surface rvmat are merged into the per-cell rvmats in the layers directory (e.g. data\layers\P_008-010_L00.rvmat). You could change them in those rvmats, but most of the time a single texture path is duplicated into hundreds of per-cell rvmats.

[gammadust 12]

I had looked at those rvmats indeed. But since they were binary i did not hold much hope for them, having found the strings for each filename i suspect merely renaming them might break the file... having said that i haven't tried. If possible, even if those are many rvmats the process can be automated.

But if i am not mistaken those rvmats are also hardcoded after compile. I searched for reference to them in configs and found none.

The thing is, if only want to change one file or two of the whole, the naif approach does not cut it: since i must maintain the vanilla addon path (there is no config access to change to another custom path) only by replacing the whole bunch of files in the corresponding vanilla addon folder may one achieve the effect, and to do that one must repack both the changed textures, rvmats and those unchanged. Either way i would be replacing original distribution files which is always ill advised.

I'll shall take a new look at it, it may have escaped me something then. Thanks again.

Edited November 15, 2013 by gammadust

[ianbanks 30]

I had looked at those rvmats indeed. But since they were binary i did not hold much hope for them, having found the strings for each filename i suspect merely renaming them might break the file... having said that i haven't tried. If possible, even if those are many rvmats the process can be automated.

Mikero's tool can convert them back to text (plus I'm fairly sure the engine can use text ones, so you could tell Visitor to keep them as text rvmats and tell binmake to just copy them in).

But if i am not mistaken those rvmats are also hardcoded after compile. I searched for reference to them in configs and found none.

The path to them is in the .wrp file (and you can see the paths by hex editing it). The rvmats stay in their own files, but they are usually rapified.

The thing is, if only want to change one file or two of the whole, the naif approach does not cut it: since i must maintain the vanilla addon path (there is no config access to change to another custom path) only by replacing the whole bunch of files in the corresponding vanilla addon folder may one achieve the effect, and to do that one must repack both the changed textures, rvmats and those unchanged. Either way i would be replacing original distribution files which is always ill advised.

I can't think of any way to alter them with another addon, either. You should be able to do it with file patching though. If you want to change (for example) \ca\desert_e\data\de_polopoust_co.paa from desert_e.pbo you can create one in:

C:\Program Files (x86)\Steam\steamapps\common\arma 2 operation arrowhead\ca\desert_e\data\de_polopoust_co.paa

Which is of course fine until you need to use multiplayer/BattlEye. ;)

[gammadust 12]

You should be able to do it with file patching though.

Which is how i am doing it now.. Case in point: i successfuly modified the file "a3\map_data\gdt_dry_grass_co.paa" of "map_data.pbo"

Which is of course fine until you need to use multiplayer/BattlEye. ;)

But i hadn't thought of this mp limitation either. I was mostly considering the waste of resources in that by modding 2.5Mb we need to repack it back into the whole 240Mb... to be able to load the sole texture. If i pack it alone to the same addon path (a3\map_data) the other textures, as expected, won't get loaded.

---

I now notice that i slightly deviated the topic, appologies.