Development:Graphics Requirements
Introduction
Image Types
For completeness purposes, the following graphics files are being referred to on this page.
Textures
- Unit textures
- Cockpit mesh textures
- Planet textures
Images
- Base/planet background images
- HUD images (cockpit, shield, armor, ships, gauges, ...)
- Main menu images
- Interface images
- Cargo images
- Space backgrounds
- Animation images
Graphic Files Requirements
Overview of Graphics Requirements
Textures ready for submission should fulfill:
- Ratio (horizontal:vertical): depending on specific image type (1:1, 2:1, 4:1)
- Dimensions: following the POT rule (power-of-two), size depending on specific image type
- Codec: dds with compresion type DXT1 (opaque only), DXT1a, DXT3, or DXT5 (with transparency)
- Extension: png (or jpg, bmp)
- Quality: RQ or CQ
- Mipmaps: required for units, not required for 2d images (hud and ui)
- Tilable (seamless): for some image types
Image ratio
The image ratio horizontal:vertical will depend on the image type. The recommendations are always assuming that pixel ratio is 1:1. This means, no matter what image ratio is used, a circle must show as a circle when viewing the image in an image viewer.
For example, it's 2:1 for planet textures, 1:1 for cargo images, planet hud images and space background faces, 4:1 for current shield and armor face images.
Square things make sense to be 1:1, however other things can be pretty arbitrary, usually you need to round to obtain the closest power of two, for example 400x300 -> 512x256.
Image dimensions
The vertical and horizontal size of the image should be a power of two (POT). Really, non-POT (non-power-of-two) textures are troublesome, time and memory consuming, since otherwise they need to be scaled when loaded and it's just best to skip that step. It'd be ideal if they were also power of two in masters, but that's not required, but the exports to data4.x should always be some power of 2.
Just use POT. Love the POT. The POT is the mother, the POT is the father. Trust the POT.
That leaves few options for the horizontal or vertical resolution:
- 64 px
- 128 px
- 256 px
- 512 px
- 1024 px
- 2048 px
1x1 images are allowed, for example if using a texture with a single color, or a transparent image.
The size recommendation will depend on the image type. Please refer to the specific image type requirements in the art-related Development section.
Keeping original high resolution image (e.g. 1024 or 2048) versions in stock (and in svn masters directory) helps maintaining quality and scalability as game development progresses or typical screen resolutions rise in the future with better hardware available to the players. Also, keeping original 3D-models in stock provides for unplanned future changes.
Image Compression Codec
The graphics format for the game is dds format, (though the file extension can be either png (preferred), jpg, or bmp).
The minimum texture that is DDS compressed is something like 64x for it to be beneficial as far as speed and size are concerned. Anything smaller than that may be better off being png, as it won't be compressed anyway.
Allowed compression types are:
- DXT1 for opaque, non alpha layered images only (no transparency).
- DXT1a for 1 bit alpha layered images. (alpha has only black masking, not shades of grey; simply: parts of the image have full transparency or are completely opaque).
- DXT3 for semi-transparent images where the transparent layer values are distinct (if the alpha is the same shade across the image, or only varies in chunks).
- DXT5 for transparent or semi-transparent images (that are translucent and if the translucence varies a lot but not distinctly).
Further clarification: DXT1 is used when the image has no transparent parts at all. DXT1a (DXT1 with alpha channel) is used when the images alpha layer is just 1 value. It's either on or off. If it's off, we should remove the alpha layer from the master and compress with regular dxt1. DXT3 is used if the image has an alpha layer with values other than 0 and 100% but they are not close together. DXT5 takes the same amount of space but it interpolates the alpha layer, for smooth transitions between values.
Mipmaps
It is recommended to create the following images without mipmaps:
- HUD images (cockpit, shield, armor, ships, gauges, ...)
- Main menu images
- Cargo images
- Interface images
- Space backgrounds
While this image types require mipmaps:
- Unit textures
- Cockpit mesh textures
- Animation images
- Planet textures
In case of doubt please ask one of the developers or on the forum.
Compression with nvcompress
You will need nVidia's free texture tool nvcompress to transform your original textures to optimized dds textures. Get the tool here: NVIDIA Texture Tools
The following applies to NVIDIA texture tools version 0.9.4. More recent versions exist.
Due to a bug in handling 1 pixel mipmaps in the original (0.9.4) version, you will be further required to patch the tools with safemode's patch. The patch can be obtained here: save nvidia-texture.patch file
Patch the texture tools, compile, and install them.
Transform your original texture using nvcompress using one of the recommended DXT1, DXT1a, DXT3, or DXT5 formats including or excluding mipmaps (option -nomips).
For DXT1 (opaque) images:
-
nvcompress -bc1 (-nomips) texture_original.png texture_dds.png
For DXT1a images with transparency:
-
nvcompress -bc1 -rgb (-nomips) texture_original.png texture_dds.png
For DXT3 images with transparency:
-
nvcompress -bc2 (-nomips) texture_original.png texture_dds.png
For DXT3 images with smooth transparency gradient:
-
nvcompress -bc3 (-nomips) texture_original.png texture_dds.png
Compression with Gimp dds plugin
Gimp plugin produces dds images with lower quality than that one produced by the nvcompress tool. In addition, the plugin uses hardware compression and may produce different results on different systems. Therefore, compressing images with this plugin is not recommended for submission, but can be used as an alternative method for local testing purposes only.
Validation and Testing
Verify the optimized texture either by opening it with GIMP (with gimp-dds plugin installed) and making sure that all mipmap layers (e.g. 12 layers for 2048x2048 original image resolution) are contained in the file, or by checking it with:
-
nvddsinfo texture_dds.png
It is strongly recommended to actually test the texture or image in game before submitting.
Image Naming (Extension)
The extension for your image file will depend greatly on three things:
- 1) the extension currently used in data for that image type
- 2) the ability to change that without corrupting the data, engine code and python scripts
- 3) future developments
Currently extensions range from png, through jpg, or bmp.
In the future the following generic, codec independent extensions will be used:
- .sprite - for sprite files
- .image - for mipmap-less 2d images (ui, cargo, bases, ...)
- .texture - for textures (units, backgrounds, planets, ...)
Artistic Image Quality
Committed textures are classified as:
- DQ - Development Quality: textures with very low horizontal resolution and low degree of artistic quality
- RQ - Release Quality: textures with at least medium horizontal resolution and medium to high degree of artistic quality
- CQ - Cinematographic Quality: textures with high horizontal resolution and very high degree of artistic quality
Specific resolution requirements can be found on the development pages specific to each image type.
SVN Structure
The subversion (svn) repository has two directories for graphics data:
- data4.x that holds the compressed/optimized dds images
- masters that holds the original (png) hi-resolution image masters plus optionally the source/project files that were used to create the compressed images. no other files will be kept in masters (text, data, sprite files, ...).
Further, the following rules apply to masters:
- only original uncompressed images go here
- they must be placed in the same (relative) directory as in the compressed images in data4.x
- the original images must have the same name as those in data4.x
- Source or project files (.xcf, .blender, ....) are placed in a subdirectory of the original image directory called sources
- The following naming convention applies for source files:
- instructions file naming: imagefile_instructions.txt
- copyright/copyleft information should go into: imagefile_license.txt
- source/project file naming: Source images should be imagefile_source.xcf (or whatever extension)
- if several source files are required to execute the project, place them in a zip file
See Also (References)
External:
Forum: