Optimized Material and Model Setups

For all new vehicle content there is a standard that things should ideally be at, to make sure everything is nicely optimized and will work properly in the future and make the most of the engine features we have available. VRAM usage is a very important issue we currently struggle with so every bit of effort towards optimizing this helps us in the long run!

Texture Cooker

All new textures should be set up so that they are compatible with the v1.5 materials system (PBR) and texture cooker. This applies to everything and not just something with a full set of PBR maps. The texture cooker makes sure things are optimized for the GPU and also generates mipmaps, which are used for lower texture settings and soon will also be used for texture streaming.

By nature, these textures are also more optimized than the old specular system as they only use what channels are necessary (no alpha channels, and greyscale needs one) which can help offset or even improve on VRAM usage despite specular to PBR conversion requiring more maps in some situations.

All texture cooker files should be PNG format with filenames that are followed by a suffix before the file extension, either .color or .data. This tells the cooker and GPU what sort of texture the file is.

The full filename using this format would be something like vehiclename_gauges_b.color.png

• .color is for 8-bit RGB format textures (such as base color or emissive maps)
• .data is for 8-bit greyscale textures (such as metallic or AO maps)
• .normal is for normal maps specifically - these should also be set to 8-bit RGB

Some programs (such as paint.net) may not automatically save PNGs in the correct format, or allow for control over this. You can ensure they are correct by opening in a program such as GIMP and checking what the image mode is set to.

(example of correctly set up textures for the texture cooker)

(example of how correct format texture should look if checked with GIMP)

Map Color Values

One big feature we have had available since the introduction of PBR is the ability to set color values in place of a texture for materials without needing dummy textures, etc. This means that we don’t need to and should not ever be using purely one color textures in any scenario, and this would serve purely to waste memory.

The color value directly correlates to what the value of that color on the texture would be, with colors using RGB values as an input while metallic maps are on a 0 to 1 scale (0 being black, 1 being white)

(red base color done via values with no texture)

(low roughness value set via value with no texture)

If you are ever making a material and it has a texture that is a pure black square, or any other color for that matter make sure you delete it and instead just set a value inside the material editor instead.

Color values can also be used to optimize textures where some maps are barely visible. For example, a transparent generic grille material would not need a metallic map where the transparent parts are different as these are not visible in the end result, and instead this can just be a color value (this one is a real example fixed a while back). Something like the roughness and metallic on purely chrome badge materials would also be able to take advantage of this.

Useful Notes

• For the fading glowmap system to work properly, the on stage material must be identical to the off stage material but with the Emissive Map section under Advanced Properties set up. The material must also be PBR (materials v1.5)
• In some situations, the second UV layer can be utilized to allow for a tiled texture with a non tiled overlay on top (for example, a repeating base color with a singular normal map on top). This can prevent large repeating textures and instead use only a couple smaller textures for optimized memory usage.
• It is fine to reference another vehicle’s textures from one vehicle (though obviously do this in moderation to prevent bloating memory usage). In the case of common materials, for basic stuff it would be recommended to use them but for something more complex, such as a vehicle main material that may be skinned or have many layers it would be advisable to create a local vehicle specific copy of the material in question that simply refers to the other vehicle’s textures (for example, the solution used for the Miramar UTE’s pickup textures)
• null.dds and null_n.dds files are an old leftover from 10+ years ago when the material system was much more privative and less understood. This doesn’t apply to the null color mask textures as these are one of the few texture types where an image is required instead of a value, so may still be used in places.
• The old “glow = 1” tag from the v0 materials system is deprecated and has been replaced with bloom in PBR emissive maps, and therefore should not be used anymore. We have some old uses of it but these should all be removed once the vehicles in question get new proper baked lights.