Texture file - Revision history

Rlemmler: document v5.8 cubemap tags

2026-10-20T15:51:24Z

document v5.8 cubemap tags

← Older revision		Revision as of 15:51, 20 October 2026
Line 98:		Line 98:

	Non-power-of-two (NPOT) textures may not support mipmapping and thus may be noticeably affected by the moire effect in addition to having higher overall GPU bandwidth requirements.		Non-power-of-two (NPOT) textures may not support mipmapping and thus may be noticeably affected by the moire effect in addition to having higher overall GPU bandwidth requirements.


			Cubemap=1
			Left=left.tga
			Right=right.tga
			Top=top.tga
			Bottom=bottom.tga
			Front=front.tga
			Back=back.tga

			A cubemap texture can be created by setting the value '1' for the 'Cubemap' key, and specifying an image file for each of the cubemap's faces.


			Tip: In [["Trainz-build" number\|trainz-build 5.8]] and higher, a cubemap can also be generated directly from an equirectangular (panoramic) image by specifying 'Cubemap=generate'.
			Cubemap=generate
			Primary=sky_panorama.hdr

			When using 'Cubemap=generate', the game uses the texture in the 'Primary' slot as the source instead of individual cubemap face textures.
			This option is useful for quickly importing HDRI sky assets into the game, so you don't have to use an external tool to convert an HDRI to a cubemap.



	=Texture Formats=		=Texture Formats=

Windwalkr at 04:37, 1 October 2024

2024-10-01T04:37:05Z

← Older revision		Revision as of 04:37, 1 October 2024
Line 6:		Line 6:
	When importing a [[trainzmesh file]] from an [[FBX file]], any image files referenced in the FBX which do not already have corresponding texture files will have generic texture files created automatically. These files may be suitable for basic purposes, but may need to be customized for more advanced functionality. Once the file has been created (and optionally customised) the importer will not recreate/overwrite it on subsequent runs.		When importing a [[trainzmesh file]] from an [[FBX file]], any image files referenced in the FBX which do not already have corresponding texture files will have generic texture files created automatically. These files may be suitable for basic purposes, but may need to be customized for more advanced functionality. Once the file has been created (and optionally customised) the importer will not recreate/overwrite it on subsequent runs.

	This page describes [["Trainz-build" number\|content format v4.6]].		This page describes [["Trainz-build" number\|content format v5.6]].


Line 22:		Line 22:
	Alpha=WayCoolTexture.tga		Alpha=WayCoolTexture.tga
	Tile=st		Tile=st
	AlphaHint=~~masked~~		UsageHint=albedo
			AlphaHint=semitransparent
			MipAlgorithm=heavy-alpha
	''(Example only, not recommended settings)''		''(Example only, not recommended settings)''

Line 79:		Line 81:


	~~MipAlgorithm~~=~~no-weight-by-alpha~~		UsageHint=albedo

	~~The default~~ [[mipmap]] generation algorithm ~~generally~~ treats the alpha channel as an opacity and prioritizes opaque texels over transparent ones~~. This can lead to poor results in cases where the alpha channel is used for a different purpose (such as with PBR parameter textures)~~. The "no-weight-by-alpha" hint can be used to ensure that the game will give equal weighting to texels regardless of their alpha channel.		Textures are processed slightly differently depending on their intended use in the rendering pipeline. Valid options are 'albedo', 'normal', and 'parameter'. If no usage hint is supplied, the game will attempt to guess the ideal processing steps based on other clues, which may lead to undesirable outcomes if the guesses are wrong.


			MipAlgorithm=weight-by-alpha

			Specifies the [[mipmap]] generation algorithm to use for the texture. Valid options are 'weight-by-alpha', 'no-weight-by-alpha', and 'heavy-alpha'. If not specified, the 'UsageHint' for the texture is consulted to determine the default behaviour; for albedo textures the 'weight-by-alpha' mechanism is used, while other textures default to 'no-weight-by-alpha'. The 'weight-by-alpha' mechanism treats the alpha channel as an opacity and prioritizes opaque texels over transparent ones. The "no-weight-by-alpha" hint can be used to ensure that the game will give equal weighting to texels regardless of their alpha channel, which is desirable if the alpha channel does not represent opacity. The 'heavy-alpha' mechanism effectively increases the alpha channel on lower mip levels, which is useful on semitransparent foliage (eg. most trees) to avoid the tree appearing overly transparent in the distance.

	The value of this key is only relevant where [[Content Manager]] is responsible for producing mipmap images. It is not relevant on any mipmap images provided in the source images.		The value of this key is only relevant where [[Content Manager]] is responsible for producing mipmap images. It is not relevant on any mipmap images provided in the source images.

Gdennish: /* Notes on Image Editors */

2020-07-02T21:45:16Z

Notes on Image Editors

← Older revision		Revision as of 21:45, 2 July 2020
Line 124:		Line 124:
	* The Targa Exporter plugin shipped with some older versions of Adobe Photoshop is broken and silently corrupts or discards alpha channels; a free update is available which resolves this issue.		* The Targa Exporter plugin shipped with some older versions of Adobe Photoshop is broken and silently corrupts or discards alpha channels; a free update is available which resolves this issue.
	* Some image editors do not support alpha channels on BMP files.		* Some image editors do not support alpha channels on BMP files.
			* By default, Photoshop does not allow for explicit editing of the alpha channel in PNG images. There is a free plugin called [https://www.fnordware.com/superpng/ SuperPNG] which integrates better PNG support to enable saving and editing of PNG alpha masks.
			* [http://www.amnoid.de/ddsview/ ddsview ] is an open source image editor that can properly open all of the texture formats used by Trainz. This is an easy tool to quickly convert between PNG parameters and TGA parameters.

	=*.txt File Extension=		=*.txt File Extension=

Gdennish: /* Source Image Formats */

2020-07-02T21:39:16Z

Source Image Formats

← Older revision		Revision as of 21:39, 2 July 2020
Line 113:		Line 113:
	* JPEG (.jpg) files. JPEG is a lossy image compression format with no alpha channel support. This format should generally be avoided since it will typically lead to the image being compressed in a lossy format (JPG), decompressed, recompressed again into another lossy format (DXT1), losing detail at each stage. Worse, if JPEG files are used during the creation of the image, each edit-save-test cycle may result in a loss of image quality.		* JPEG (.jpg) files. JPEG is a lossy image compression format with no alpha channel support. This format should generally be avoided since it will typically lead to the image being compressed in a lossy format (JPG), decompressed, recompressed again into another lossy format (DXT1), losing detail at each stage. Worse, if JPEG files are used during the creation of the image, each edit-save-test cycle may result in a loss of image quality.
	* Windows Bitmap (.bmp) files. BMP is a lossless image format with no compression and optional alpha channel. This format should generally be avoided since it does not offer compression and has no redeeming benefits.		* Windows Bitmap (.bmp) files. BMP is a lossless image format with no compression and optional alpha channel. This format should generally be avoided since it does not offer compression and has no redeeming benefits.
	* HDR (.hdr) files. HDR is a lossless image format with 32 bits of precision per channel. The R32F G32F B32F A32F internal texture format is used, and texture compression is not supported. This is a very expensive format (in terms of memory and performance) and should only be used where absolutely essential. Textures created in this format should be kept as small as possible (eg. 256-512 pixels wide and high).		* HDR (.hdr) files. HDR is a lossless image format with 32 bits of precision per channel. The R32F G32F B32F A32F internal texture format is used, and texture compression is not supported. This is a very expensive format (in terms of memory and performance) and should only be used where absolutely essential. Textures created in this format should be kept as small as possible (eg. 256-512 pixels wide and high) but at least 8x8 pixels wide and high.
	* PNG (.png) files. PNG is a lossless compressed image format with alpha channel support. This is the best choice where compatibility with older versions of Trainz is not required.		* PNG (.png) files. PNG is a lossless compressed image format with alpha channel support. This is the best choice where compatibility with older versions of Trainz is not required.
	* DDS (.dds) files. This has very limited support intended for specific internal purposes; it is not recommended that end-users utilize this format at the current time.		* DDS (.dds) files. This has very limited support intended for specific internal purposes; it is not recommended that end-users utilize this format at the current time.

Gdennish: /* Texture Size */

2020-07-02T21:38:35Z

Texture Size

← Older revision		Revision as of 21:38, 2 July 2020
Line 104:		Line 104:
	=Texture Size=		=Texture Size=
	Textures must be no more than 4096 pixels in either dimension, although it is strongly recommended that textures are kept below this maximum to avoid performance problems. Small objects should typically use approximately 512x512. Large, highly detailed objects such as train vehicles or ground textures will typically use 2048x2048.		Textures must be no more than 4096 pixels in either dimension, although it is strongly recommended that textures are kept below this maximum to avoid performance problems. Small objects should typically use approximately 512x512. Large, highly detailed objects such as train vehicles or ground textures will typically use 2048x2048.
	Uniform-color textures (ie. textures in which all [[texel]]s have the same color) should be 8x8.		Uniform-color textures (ie. textures in which all [[texel]]s have the same color) should be 8x8, 2x2, or 1x1.
	Textures must be a power-of-two size in each dimension (unless the 'nonpoweroftwo' key is activated), but need not be square. Some materials may give unexpected results for non-square textures; consult the material-specific documentation for details.		Textures must be a power-of-two size in each dimension (unless the 'nonpoweroftwo' key is activated), but need not be square. Some materials may give unexpected results for non-square textures; consult the material-specific documentation for details.

Windwalkr at 03:58, 4 November 2019

2019-11-04T03:58:10Z

← Older revision		Revision as of 03:58, 4 November 2019
Line 79:		Line 79:


	MipAlgorithm=~~tend~~-~~towards~~-~~opaque~~		MipAlgorithm=no-weight-by-alpha

	The default [[mipmap]] generation algorithm ~~tends to make semi-transparent dithers (such~~ as ~~chain-link fences or tree leaves) appear more~~ transparent ~~in the distance~~. This ~~occurs because~~ the ~~multiple texels of~~ alpha ~~in the high-detail source image (100%, 0%, 100%, 0%) are blended to~~ a ~~single pixel in the lower mips~~ (~~50%.) The net result is that the average opacity level remains the same, but that the maximum value is reduced. Coupled~~ with ~~the fact that overlapping layers of semi-opaque~~ textures ~~do not necessarily increase the output opacity (a rendering limitation relating to performance~~) ~~the net result is that something which might be quite opaque close-up may become ghostly in the distance~~. ~~An alternate~~ "~~tend~~-~~towards~~-~~opaque" algorithm may be selected for mipmap generation, which defeats this issue~~ by ~~biasing opacity toward the maximum. This increases average opacity for distant objects, and has the side effect of making soft edges become hard and potentially~~ "~~blocky". It should only~~ be used ~~where~~ the ~~default algorithm gives decidedly sub-optimal results~~.		The default [[mipmap]] generation algorithm generally treats the alpha channel as an opacity and prioritizes opaque texels over transparent ones. This can lead to poor results in cases where the alpha channel is used for a different purpose (such as with PBR parameter textures). The "no-weight-by-alpha" hint can be used to ensure that the game will give equal weighting to texels regardless of their alpha channel.

	The value of this key is only relevant where [[Content Manager]] is responsible for producing mipmap images. It is not relevant on any mipmap images provided in the source images.		The value of this key is only relevant where [[Content Manager]] is responsible for producing mipmap images. It is not relevant on any mipmap images provided in the source images.

Builderbob: Clarify Primary/Alpha

2018-07-24T23:45:58Z

Clarify Primary/Alpha

← Older revision		Revision as of 23:45, 24 July 2018
Line 36:		Line 36:
	Alpha=diffusemap.bmp		Alpha=diffusemap.bmp

	This tag combination specifies the filenames of the image file representing the color (R, G, B) channels of the texture and the image file representing the ~~alpha (A) channel~~ of the texture. The ~~alpha channel~~ image should be grayscale. Neither file should contain an alpha channel. The two image files must be of identical size.		This tag combination specifies the filenames of the image file representing the color (R, G, B) channels of the texture (Primary) and the image file representing the transparency of the texture (Alpha). The Alpha image should be grayscale. Neither file should contain an alpha (A) channel (ie, both images should be 24-bit). The two image files must be of identical size.


Line 42:		Line 42:
	Alpha=diffusemap.tga		Alpha=diffusemap.tga

	This tag combination specifies the filename of a single image file representing the color and ~~alpha~~ (R, G, B, A) channels of the texture. In this case both tags must reference the same filename. The image file must contain an alpha channel.		This tag combination specifies the filename of a single image file representing the color and transparency (R, G, B, A) channels of the texture. In this case both tags must reference the same filename. The image file must contain an alpha channel.


Line 91:		Line 91:

	Non-power-of-two (NPOT) textures may not support mipmapping and thus may be noticeably affected by the moire effect in addition to having higher overall GPU bandwidth requirements.		Non-power-of-two (NPOT) textures may not support mipmapping and thus may be noticeably affected by the moire effect in addition to having higher overall GPU bandwidth requirements.


	=Texture Formats=		=Texture Formats=

Tonyhilliam at 03:25, 17 January 2018

2018-01-17T03:25:39Z

← Older revision		Revision as of 03:25, 17 January 2018
Line 135:		Line 135:

	[[Category:File formats]]		[[Category:File formats]]
			[[Category:Modeling]]
			[[Category:Content creation]]
	{{ORP-bot}}		{{ORP-bot}}

Windwalkr at 07:27, 11 September 2017

2017-09-11T07:27:47Z

← Older revision		Revision as of 07:27, 11 September 2017
Line 6:		Line 6:
	When importing a [[trainzmesh file]] from an [[FBX file]], any image files referenced in the FBX which do not already have corresponding texture files will have generic texture files created automatically. These files may be suitable for basic purposes, but may need to be customized for more advanced functionality. Once the file has been created (and optionally customised) the importer will not recreate/overwrite it on subsequent runs.		When importing a [[trainzmesh file]] from an [[FBX file]], any image files referenced in the FBX which do not already have corresponding texture files will have generic texture files created automatically. These files may be suitable for basic purposes, but may need to be customized for more advanced functionality. Once the file has been created (and optionally customised) the importer will not recreate/overwrite it on subsequent runs.

	This page describes content format v4.6.		This page describes [["Trainz-build" number\|content format v4.6]].

Windwalkr at 07:18, 11 September 2017

2017-09-11T07:18:17Z

← Older revision		Revision as of 07:18, 11 September 2017
Line 1:		Line 1:
	{{ORP-top}}		{{ORP-top}}
	Trainz '''Texture files''' are ASCII text format specification files describing a single texture. Texture files have a ".texture.txt" name extension, however when a texture file is specified within a [[~~Config~~.txt file]] or similar, the ".txt" must be omitted (as you are specifying a resource name, not a file path), leaving only the ".texture" extension.		Trainz '''Texture files''' are ASCII text format specification files describing a single texture. Texture files have a ".texture.txt" name extension, however when a texture file is specified within a [[config.txt file]] or similar, the ".txt" must be omitted (as you are specifying a resource name, not a file path), leaving only the ".texture" extension.

	Texture files (.texture.txt) should be distinguished from [[image file]]s (.tga, etc.) and [[material]]s. A material may utilize zero or more texture files, and a texture file may utilize one or more image files. While we often refer to the image data as "a texture", this usage isn't strictly correct as any given texture also has a number of metadata attributes which are not present in the source image. Additionally, a texture may be compressed (at installation time) which may actually lose some of the data originally present in the source image.		Texture files (.texture.txt) should be distinguished from [[image file]]s (.tga, etc.) and [[material]]s. A material may utilize zero or more texture files, and a texture file may utilize one or more image files. While we often refer to the image data as "a texture", this usage isn't strictly correct as any given texture also has a number of metadata attributes which are not present in the source image. Additionally, a texture may be compressed (at installation time) which may actually lose some of the data originally present in the source image.
Line 128:		Line 128:

	=*.txt File Extension=		=*.txt File Extension=
	Texture files have a ".texture.txt" name extension, however when a texture file is specified within a [[~~Config~~.txt file]] or similar, the ".txt" must be omitted, leaving the ".texture" extension.		Texture files have a ".texture.txt" name extension, however when a texture file is specified within a [[config.txt file]] or similar, the ".txt" must be omitted, leaving the ".texture" extension.
	For example, a texture file named ''grass.texture.txt'' is specified in a [[KIND Groundtexture]] config file using the syntax ''texture "grass.texture"''.		For example, a texture file named ''grass.texture.txt'' is specified in a [[KIND Groundtexture]] config file using the syntax ''texture "grass.texture"''.