The goal of creation is dual.
First of all, is to have different skins on the objects of the same type.
The second one is linked with the question I mentioned in a side - number of textures per scene and its influence on performance.

The converter gathers all textures of the scene (it's allowed to gather) into a single one called "skin", modifies the objects to refer to that texture, and modifies the scene to refer to those objects.
That's why by default the resulted skin is enormously huge.

The goal of the converter is to assemble all of the textures into the single skin. That's why it must copy all of them into one place.
Moreover, some textures are used in tiles mode. It means upon copying the converter must manually tile them several time to respect the original usage. When a tile itself is big (and most of them are) the result is huge.
Also, converter is dumb. It does not know which textures are important and which are not. And the result is that terrific.

(I) Those are "default" game objects - stored in cohokum\3ddata in .bin files.

(II) The ones ee_exp creates exporting those bins into LWOs and LWSes.

(III) Influenced by modders, retextured, renewed, created from a scratch. They are still in LWO/LWS format.

(IV) Data from (III) converted into EEO and EES. They usually reside in cohokum\3ddata\objects (ABCD.EEO, objects shared by different scenes) and cohokum\3ddata\objects\somedirectory (EES and scene specific EEOs). As long as (III) can be modified several times, different (IV) may exist at different time point.

(V) Skin Converter takes (IV) and creates LWOs and LWS referring the skin texture. According to the achieved result the process may require reediting (III) and reconverting them into (IV), and (V). Of course, different (IV) produces different (V) and skins may differ greatly.

(VI) Probably (V) should be tuned a little (LWO and LWS again).

(VII) (VI) converted into EES and EEOs, and used with skins in the game. Note, that (VII) objects are not applicable for skin conversion process. Once the scene is converted, the result cannot be converted again. That's why it may be crucial to preserve (III). And maybe not - I don't know.
Also, (VI) files may be required later - for conversion into formats differing from EES and EEO.

1. Create a directory, place ee_skin.exe, config.txt and ee_skin.cmd there.
2. Edit config.txt - change the directories names to reflect your EECH installation directory. No quotes are required there.
3. Edit ee_skin.cmd - again, change the directory. If the resulted path contains spaces, it must be wrapped in quotes.
4. Run ee_skin.cmd. Wait a couple of minutes.

A new directory with the name of the scene mentioned in ee_skin.cmd will be created and filled with modified files.

5. After the converter finishes go to that directory and open skin TGA file.
6. Be terrified by the result.
7. Go to the "usage (hard version)".

1. LOG file. Converter writes about all the deeds there. We will need it when we begin to cope with problems of terrific result.
2. Up to three skin TGA files (for different seasons, if source textures had variations for them).
3. Animation TXT file mentioning the textures above. All skin files will be referenced in that file.
4. LWS and LWO files for tuning (if required) and further conversion.
5. Helper CMD file converting LWS and all of LWOs into EES and EEO.

First of all it loads the scene and object files. Object files are "default" from bin, "common" from "common_objects" and "scene-specific" from the directory EES file resides.

Then scene's objects are traversed to find the used textures - LOG file has a lot of entries about them.
Some of those textures are ignored. Those are (1) mentioned in animation files (loaded from "animations" directory) and (2) mentioned in "[IGNORE_TEXTURES]" section of CONFIG.TXT. Textures used for luminosity are ignored too.

Then the textures are tried to be loaded. Look at "[textures]" section and LOG file. In the config the most important are the first and the last
directories.
The first one is the one created by EE_EXP - containing default EECH textures. When (VI) LWO files are loaded into Lightwave they may be required, and the converter automatically refers them.
The last one is where all of "override" textures are placed.
If some tile texture is a little too big, a smaller version of it is placed there. It will be used instead of others.
Please note that at this stage desert -D and winter -W textures are being tried to be loaded too. All of them (if present) must be of the same size. If a smaller version of one of those is made - the same for others should be done too.

Then textures having alpha are discarded too.

Then the resulted texture info is generalized. For each texture it's Actual (existing file) size is written, and also that UV usage information leading to Required size calculation. At this moment how large each texture will be in the resulted skin is clearly seen.

Then those (tiled) textures are aggregated into a single skin. One
pixel gap is used between them (it's clearly seen if blue_fill=1).

Then the objects are traversed again, modified and converted into LWO.
Please note that those object still refer "ignored" textures. And as long as Lightwave doesn't support DDS, probably TGA version of them are required to be placed in "override" directory beforehand.
Please note that our DDS files are (due to some bug) flipped vertically. When converting DDS into TGA you should flip them again.

1. The easiest. Place the texture in the ignore list. But it contradicts with the goal of the converter - to decrease the number of textures used. But I had to do that with SCRATCHED_GLASS, for example.
2. Use the smaller version of texture. Resize one (or three if -D and -W present) and place them in the "last in the list" textures
directory. As long as they will be used only for conversion process, not for the game, there is no need to make them of "power of two" size. For example, you can make the biggest texture 1024x1024 to be 1024x768 and force others to fit 1024x256 place.
3. Modify the object using that texture (or scene using that object).
The object name is seen in the beginning of the LOG.
That might be trickier and requires (III) files (or (IV) converted with EEO2LWO and EES2LWS).

I don't know. Will _you_ tell me and others about it?