PDA

View Full Version : *.texture format



andi06
September 24th, 2015, 05:30 AM
A query from PEV:


To enable us to display TANE textures in AssetX and Images2TGA, in the file header format:-

There’s a number in it called “MipSkip”. Its usual value appears to be zero. I assume that if the value were 1 then the smallest mipmap would not be included in the texture. And if the value were 2 the two smallest mipmaps would not be included, and so on. If my assumption is wrong please define MipSkip usage.

I am limiting the viewer to display planar textures only. Cube textures are of no interest to us at this stage, so the decoding of slices is not needed.

Also is there any possibility of the “rgba”, “dxt2” or “dxt4” pixel formats being used. And if rgba is used, is its format the same as the old 32 bit Trainz textures where I had to re-arrange the data to get it into true rgba format to display (and save as TGAs)? I have dxt1, dxt3 and dxt5 decoding working already from the previous texture version.

My initial versions of the new texture decoder have TANE textures displaying for dxt1 and dxt5.. I’ve not found any other pixel encoding as yet.

Also I note that there is no 24 bit rgb format identifier in the texture pixel encoding. Inferring that dxt1 without transparency is the only encoding that behaves like 24bit.

We will not be writing any code to MAKE trainz textures.. the game does that. We stick to the policy of any files that are interacting directly with the game engine are produced by N3V software. eg TrainzMeshImporter or TrainzUtil.

WindWalkr
September 24th, 2015, 08:40 AM
The value is currently always zero. It was used to perform texture size reduction prior to us having in-game settings for texture quality and streaming.

Basically, there are cases where the reader needs to know the original size of the image, but we only want the file to contain a reduced level of detail. A mipSkip of '1' would mean that the texture in the file was half scale compared to the original, etc.

chris

WindWalkr
September 24th, 2015, 08:45 AM
Also is there any possibility of the “rgba”, “dxt2” or “dxt4” pixel formats being used. And if rgba is used, is its format the same as the old 32 bit Trainz textures where I had to re-arrange the data to get it into true rgba format to display (and save as TGAs)? I have dxt1, dxt3 and dxt5 decoding working already from the previous texture version.

We currently use 'rgba', 'dxt1', 'dxt3', and 'dxt5' encodings. The actual texture data is always raw with no additional headers or encoding. We obviously reserve the right to include new encodings, and there is no requirement to change the file format versions when this happens (since the encoding is specified separately.)

chris

andi06
September 24th, 2015, 10:11 AM
Thanks Chris, that's all we need for now, you can close the thread.