General notes on vegetation and geography .db's
The vegetation.db is found at data/vegetation/vegetation.db
it has similar content to data/descr_vegetation.txt, which is a useful guide to the original contents of the .db, unfortunately changing the .txt file does not update the .db - the later versions of wilddog's IWTE tool allow reading and re-writing to the .db so changes can be made.
Vanilla unpacked games contain descr_geography_new.db and descr_geography_new.txt. If you add ;
[misc]
rebuild_geography_db = true
to the .cfg file then the text file will be re-used to re-build the geography.db on each launch, this method is however not recommended. Instead delete or rename the descr_geography_new.txt file and use IWTE to amend descr_geography_new.db file.
Add a new model to the vegetation.db
To add a new vegetation model to the .db list, download IWTE_v14_07_A.exe or later, place the .exe somewhere convenient near copies of your vegetation files. Launch IWTE and use 'veg' tab and 'Read VegDB binary' to load the .db, use 'Edit Vegmodel List' to add model. Press 'Add New Vegetation model' type in name of model and sprite, i.e.
new_tree.vege_model &
new_tree.vege_sprite
paths are not used, the game assumes .vege_models are in vegetation/models and .vege_sprites in vegetation/sprites, once done press 'OK'
to assign the new model to a climate select
'Edit VegGroup List' and select the climate, season and vegetation type you want to change, select 'confirm group' and then either replace an existing model or add in an unused slot (unused slots should be at the bottom of list - no more than four models are possible per group), when done press 'OK'
then select 'Write VegDB binary' and choose file name for the new file. To get the new veg.db in game re-name it and use in place of the existing file.
Components needed to add new vegetation model
new parts needed shown in bold, example file names in italics;
vegetation/models/new_tree.vege_model
.vege_model contains reference to textures/new_texture_name
so the corresponding file is needed;
vegetation/models/textures/new_texture_name.texture
vegetation/sprites/new_tree.vege_sprite
.vege_sprite contains reference to diffuse and normal map, i.e.
diffuse_maps/new_tree_diff.texture &
normal_maps/new_tree_norm.texture
those paths are relative to the sprite positions so the following files are required;
vegetation/sprites/diffuse_maps/new_tree_diff.texture
vegetation/sprites/normal_maps/new_tree_norm.texture
NB: IWTE sprite files use different .texture names than vanilla M2TW sprites, we've added the _diff and _norm parts to make the files easier to identify and let them exist in same output folder, do not change the name of the IWTE sprite textures (unless you also edit the .vege_sprite)
Creating new .vege_model
IWTE converts from .ms3d only. The conversion is on 'Veg' tab 'Convert ms3d to Vegmodel'. The ms3d file needs to have the required texture name in the format
textures/texture_name.texture
in the 'Model' 'Comment' section, see pic;.
If you want to adapt an existing model you can use 'Convert Vegmodel to ms3d' - if you want to use a RTW model you can use that process to convert the first listed model of the climate (re-name the RTW .vege file to .vege_model). If you have access to RTW .cas files you can convert most .cas's by using IWTE's "Strat Map" tab "Read Strat Cas" > "Write Strat Cas to MS3D". (You can also run the RTW veg process to make separate .vege files for each .cas if you adapt the RTW descr_vegetation.txt file - or use 3ds max to export the .cas in obj format for import to milkshape)
Tips on creating new models;
In game the vegetation models display both sides of a plane, i.e. backfaces are shown, but the lighting is always displayed as whatever the lighting would be on the front face... So the best method of creating a plane that needs to be viewed from both sides is to create a double sided structure by duplicating the plane, reversing the vertex order for one part, then welding the common vertexes together and getting IWTE to create new normals, see post 2 for details. Cylindrical things like trunks, should just be constructed normally and not be double sided.
Old advice spoilered;
Spoiler Alert, click show to read:
Do not overlap the uv co-ordinates beyond the extent of the texture - in milkshape this shows up as looking OK with the texture just tiled around, but in game the overlap actually tiles onto the next model (hence the silly hollow looking bits in some of the vanilla 'unused' climate rocks)
The .dds / minimap / texture conversion bit of the texture process tends to mean that what you think is background colour under the alpha'd out bit of a texture actually appears as a halo around your model as you zoom out. For best results set the background colour of the texture to match the visible bits.
Creating new .vege_sprite
To get IWTE to do this you need to use 'Veg' tab and 'Create VegSprite',
select the .vege_model you want a sprite for, to get this to work you need to have a .tga version of the .texture that is listed within the vege_model in the appropriate place, i.e. the /textures/ folder.
The tool will then create a binary file called
vege_model_name_new.vege_sprite - (this contains the file path to the sprite .textures assuming they have the same name as the model with _diff and _norm added, and that they will be placed in the diffuse_maps and normal_maps folders, it also contains other information about the bits of the .textures to be displayed for various angles, the scaling and the origin points, hopefully that should all work from the default generated from the tool)
the tool will also produce .tga's called
vege_model_name_diff.tga
&
vege_model_name_norm.tga
in the same folder as the model - you need to rename the .vege_sprite file to whatever you called the sprite in the db and place it in the vegetation/sprites/folder
the .texture file names are contained within the sprite in binary format and shouldn't be changed. The sprite .tga's need to be converted to .dds and then to .texture and placed in the appropriate folders. The _diff version needs to have the alpha saved, the _norm version doesn't.
With wilddog's latest version of the sprite generator the .tga's generated are pretty good, even possibly a bit better than vanilla . I wouldn't recommend trying to fiddle with the normal unless you know a lot more about it than wilddog managed to discover (it's nothing like the nvidia filter used for unit/building texture normals, but based on the model vertex tangents) - you could if you wished fiddle with the _diff part which represents the projection based on texture colour and alpha, rather than the model shape. However, the sprite tga size should stay at 256 pixels high, attempting to mix in other heights of tga may result in the sprites overlapping onto the next sprites in the climate.