OBD talk:TXMP

Complete and accurate knowledge on the TXMP format is badly needed.

For one thing, incomplete/inaccurate knowledge may be a reason why repacking (with OUP) fails.

Also, import and export lack a few features (alpha, env maps) and may get colors slightly wrong.

Basically, the incomplete/inaccurate information is related to the three bytes below, and to the associated raw/separate file formats.

One not-too-comfortable aspect is that apparently contradictory settings for the 3 bytes are somehow interpreted by Oni.

geyser 21:09, 3 February 2007 (CET)

MIP mapping (MIP stands for "multum in parvo")

A texture mapping technique that uses multiple texture maps, or MIP maps. Each MIP map is half the size of the first one, providing several texture maps for various levels of depth.

Alpha blending

In computer graphics, the combining of the alpha channel with other layers in an image in order to show translucency.

The alpha channel is an additional eight bits used with each pixel in a 32-bit graphics system that can represent 256 levels of translucency.

(here, the base color depth is 16 bits; and there are only 4 bits for the alpha channel, so only 16 levels of transparency. geyser)

Bitsets or indices

Store type (0x90)

probably an index

MIP mapping (0x88)

not sure

maybe they are not only MIP mapping options

(in that case almost certainly a set of flags)

Color depth (0x89)

It's not just the color depth

(actually, quite little to do with color depth)

so almost certainly a bitset.

MIP mapping (0x88)

Bitset

0x01

This one "just" turns mip mapping on and off.

For uncompressed pictures, resampling is trivial. ==> They are "pre-resampled". It's not done at runtime.

what about compressed ones.

0x02

unknown

0x04

Disable wrapping for the U coordinate of the texture.

Enabled for skyboxes, animations and pretty much anything else that does not need texture wrapping.

0x08

Disable wrapping for the V coordinate of the texture. See above.

0x10

This one is enabled for env-mapped textures and env maps themselves.

Also enabled for skyboxes?

0x20

used a runtime (marks if a texture name has been allocate for this TXMP or not)

0x40

unknown - animation related

0x80

unknown - animation related, only used by an "electric arc" texture, could mean to play frames of the animation in random order

Anything else?

There aren't so many values: 0, 1, 17, 28. It's hard to decide against an ID.

A bitset does make some sense because both 1 and 17 use MIP mapping...

Well, IMO they're bitsets. I fixed that a long time ago. Ssg 10:59, 13 February 2007 (CET)

You "fixed that" where? I can't see it detailed on OS... geyser 04:05, 6 March 2007 (CET)

Here? Ssg 12:19, 6 March 2007 (CET)

Not that it matters now, but IIRC you had not uploaded that update as of 2007/02/13... geyser 13:41, 6 March 2007 (CET)

Color depth

Actually, the colors are parsed according to the store type.

This one only sets the depth for miscellaneous extras (alpha, env map, etc)

0x01

Used when again?

0x02

Reads the high byte as env map (0x00 is "little", 0xFF is "much")

Sometimes used in conjunction with 5x5x5 textures, i.e. if it really

reads the whole byte, the 3 lower bits will be garbage. Not sure...

0x04

Reads the high byte as alpha (0x00 is transparent, 0xFF is opaque)

0x08

Used when again?

0x10

On if there are 16 bits per uncompressed pixel (color depth etc may vary) ==> no changes ==> Oni reads it directly from the raw file

It appears to me that this bit means that the byte order of texture raw data must be swaped, it does not have anything to do with the number of bits which is encoded in the texture format anyway. Neo

0x20

On if there are 32 bits per uncompressed pixel (color depth etc may vary) (or may they?)

IIRC, that bit is never used in Oni. If you use it, Oni chrashes.

This one appears to be used only at runtime to mark if the texture has been loaded or not (loading basically means to convert the offset to texture data in the raw file to a memory address, that's why Oni crashes if you set this bit, it thinks that the texture is already loaded and it uses the file offset as a memory pointer which is not valid) Neo

0x40

Looks like TXAN looping ON/OFF. Somebody please check somehow ^^

0x80

16 bit blue (?) - only SHIELD use it

---

The first two bits of the next bitset are used too:

0x01

16 bit alpha (?) - only INVIS use it

0x02

16 bit red (?) - only DAODAN_SHIELD use it Ssg 11:06, 13 February 2007 (CET)

Store type

Data per pixel, uncompressed unless mentioned otherwise

0

(4,4,4) RGB, 4 bits extra (interpreted as alpha or env map blending), equivalent to GL_RGBA4 OpenGL image format

1

(5,5,5) RGB and 1 bit extra, the extra bit is simply ignored, equivalent to GL_RGB5 OpenGL image format

2

(5,5,5) RGB, 1 bit extra (interpreted as alpha or env map blending), equivalent to GL_RGB5_A1 OpenGL image format

8

(8,8,8) RGB, 8 bits extra that are ignored, equivalent to GL_RGB OpenGL image format

9

compressed (four times) (algorithm detailed elsewhere), equivalent to GL_COMPRESSED_RGB_S3TC_DXT1_EXT OpenGL compressed image format

Anything else?

No. Uups... I mean, yes.

The "mac exe" contains the following stuff in the image section (image.c or somthing like that):

rgb555, rgb565, rgba5551, argb1555, argb4444, rgba4444, rgba8888, s3, compressed, i8, i1, i4a4

(r=red, g=green, b=blue, a=alpha, i=intensity; see http://www.cg.tuwien.ac.at/~wimmer/view3dx/TEXUS.html too)

---

---

Reloaded

Woohoo, nice clean list for accurate knowledge! Over here!!!

0x88

Bitset (rather large: 18 bits at least) bytes are listed in Little Endian

0x 01 00 00 00

MIP mapping enabled (generations stored in raw/separate file, used at runtime)

Q: Anything special about MIP mapping of DXT1-compressed pixels?

A: Not really, only the fact that a DXT1-compressed texture must be at least 4x4 pixels in size unlike an uncompressed image that goes down to 1x1 for mipmaps. Neo

0x 02 00 00 00

Q: (sorry) ever used? effect? ^^ geyser

A: There is no texture in any level that uses it. If it is of any use that's only at runtime. Neo

0x 04 00 00 00

U wrapping disabled

0x 08 00 00 00

V wrapping disabled

0x 10 00 00 00

Enabled for env-mapped textures and env maps themselves.

Q: Also enabled for skyboxes? Exact effect? geyser

A: Reseting this bit does not appear to have any effect on env maps or skyboxes and I can't find any trace of its use. Besides it's strange that it is enabled for completly unrelated textures (envmaps and skybox). It seems to be of no use to the game engine. Neo

0x 20 00 00 00

used a runtime (marks if a texture name has been allocated for this TXMP or not) Neo

Q: same question as below for 0x00200000: does the whole bitset get copied "elsewhere" at runtime? geyser

A: See below Neo

0x 40 00 00 00

unknown - animation related Neo

Q: (sorry) exact effect? ^^ geyser

A: Play animation back to back - frames 0 to n then n-1 to 0 Neo

0x 80 00 00 00

Play animation in random order, only used by an "electric arc" texture Neo

With random frame time Alloc

0x 00 01 00 00

Q: Ever used? Effect? ^^ geyser

A: Animation related again, seems to change the time reference for animation. I've seen it used by w1_case texture in level0 which makes sense because you don't want to see 10 falling bullet cases playing the same animation frame. Neo

0x 00 02 00 00

Reads the high byte as env map (0x00 is "little", 0xFF is "much")

Q: Sometimes used in conjunction with store type 1 or 2. 5x5x5 color, 1 bit extra, i.e., if it really reads the whole high byte, the 3 lower bits are garbage then?

A: Not sure about what "lower 3 bits" are you talking about. Probably you are asking if for a GL_RGBA4 texture all the 4 bits of the alpha channel are used. Yes, they are used. For env maps the alpha channel is sort of a "how much reflective is the surface" so it can be more or less reflective. Neo

0x 00 04 00 00

Reads the high byte as alpha (0x00 is transparent, 0xFF is opaque)

Q: Same as above: what if the store type is 1 or 2?

A: The above explanation sounds strange. Most of the textures that use it are GL_RGB5 so there is no alpha channel. However, all the textures (most of them are animations) that use it have a black bakground which becomes transparent at runtime. Neo

0x 00 08 00 00

Q: Ever used? Effect? ^^ geyser

A: There is no texture in any level that uses it. If it is of any use that's only at runtime. Neo

More exactly this changes the alpha blending mode for the texture that uses it. Normally transparency is calculates using the formula

TextureColor * TextureAlpha + ExistingScreenColor * (1 - TextureAlpha)

but when this bit is set blending is done using another formula

TexureColor * TextureAlpha + ExistingScreenColor

The obvious effect of this is that black becomes transparent because adding 0 results in the same color (but note that black is not a special "transparency" color). Most of the textures where this is used don't even have an alpha channel and TextureAlpha is considered to be 1 in those cases so it just adds the TextureColor to the ExistingScreenColor. If you don't realised it already, this is used to make "light sources" like explosions and glares.

0x 00 10 00 00

On if there are 16 bits per uncompressed pixel (color depth etc may vary) ==> no changes ==> Oni reads it directly from the raw file Ssg 11:06, 13 February 2007 (CET)

It appears to me that this bit means that the byte order of texture raw data must be swapped, it does not have anything to do with the number of bits which is encoded in the texture format anyway. Neo

Q: Whom is the swapped data relevant to, then? "Texture format" = "store type"? "Number of bits" = RGB color depth = "store type"? geyser

A: The data from raw file is byte swapped. This is independent of texture format (= store type) which also includes the number of bits used. Neo

0x 00 20 00 00

IIRC, that bit is never used in Oni. If you use it, Oni chrashes. Ssg 11:06, 13 February 2007 (CET)

This one appears to be used only at runtime to mark if the texture has been loaded or not (loading basically means to convert the offset to texture data in the raw file to a memory address, that's why Oni crashes if you set this bit, it thinks that the texture is already loaded and it uses the file offset as a memory pointer which is not valid) Neo

Q: Neo, are you saying Oni writes to the memory-mapped DAT-part of every loaded TXMP? Or is that particular bitset copied "elsewhere"? geyser

A: Yes, it writes to this bitset and in many other places of the DAT file. Links to files are replaced with pointers, offset in the raw data file are replaced with pointers, bitsets are written, "dead" fields or fields that are always 0 and appear to be unused are written to. Neo

0x 00 40 00 00

Looks like TXAN looping ON/OFF. Somebody please check somehow ^^ geyser

Q: (sorry) did anybody "please check somehow"? ^^ geyser

0x 00 80 00 00

16 bit blue (?) - only SHIELD uses it Ssg 11:06, 13 February 2007 (CET)

Q: ??? geyser

0x 00 00 01 00

16 bit alpha (?) - only INVIS uses it Ssg 11:06, 13 February 2007 (CET)

Q: ??? geyser

0x 00 00 02 00

16 bit red (?) - only DAODAN_SHIELD uses it Ssg 11:06, 13 February 2007 (CET)

Q: ??? geyser

To the last 3 entries: F.e. the SHIELD in ONI is blue. If you disable the "blue bit" and enable the "red bit" you'll get a red shield. If you disable the "blue bit" and enable no other "colour bit", you'll get a white shield, because IIRC, the hex data of the texture is fully FFFF. Ssg 12:35, 6 March 2007 (CET)

Neo, what say you? Ssg: thanks a lot, but... no "green" bit? geyser 13:44, 6 March 2007 (CET)

A: I haven't looked at this but from your story it seems correct. I can add that Open GL has 4 texture formats GL_RED, GL_GREEN, GL_BLUE and GL_ALPHA which can be used to implement the above behavior. Neo

Update. I've tried those last three for Konoko's asspelvis (GL_RGB5). The effect is interesting.

The RGB colors of the basic texture are retained, but they are blended with a randomly moving pattern.

Pattern varies smoothly in both space and time, and is apparently multiplied by the RGB data, with different weights for the 3 channels.

• "blue bit" favors the blue channel (but the others are still there)
• "red bit" favors the red channel (but the others are still there)
• "alpha bit" just makes the whole color much darker (i.e., the phase cloak is actually "black")

In other words, the "INVIS" bit has nothing to do with alpha; rather it's a "black bit"

(transparence of various cloaks/shields is dynamic/hardcoded anyway)

Those 3 work the same for GL_RGB5 (pelvis), GL_RGBA4 (chest, head) and GL_RGB5_A1 (shoulders).

The alpha/envmap channel (if any) seems irrelevant (note that SHIELD, INVIS and DAODAN_SHIELD have no alpha)

I assume those bits don't affect the way the RGBA data is read from the raw/separate file.

All 3 "effects" seem to be ignored for environment/skybox/object texturing: tried with several available store types.

They correspond to hard-coded eye candy, specially designed for shields, phase cloaks and boss shields.

Overlaid with regular textures, they create funky/spooky blue, black or red colorization, respectively.

We could thus call them AO-bit, KURO-bit and AKA-bit, respectively. ^^

geyser 02:33, 7 March 2007 (CET)

These bits have no effect on the texture itself but the colors of the 3D model to which the texture is applied. Each point gets a color based on current time and some coefficients for each color component. For example for invisibility green has 0.15, blue has 0.3 and red 0. Neo

0x90

Integer ID. Defines the RGB color depth of texels (is that correct? geyser)

0

(4,4,4) RGB, 4 bits extra (interpreted as alpha or env map blending)

equivalent to GL_RGBA4 OpenGL image format Neo

Q: Does the interpretation of the high bits depend on the 0x88 settings? geyser

A: Yes, for env maps it really means how much reflective is the surface instead of transparency. Neo

1

(5,5,5) RGB and 1 bit extra

the extra bit is simply ignored, equivalent to GL_RGB5 OpenGL image format Neo

Q: Is the extra bit always ignored, regardless of the 0x88 settings? geyser

A: Yes, if it's RGB5 then it's RGB5, no alpha. Neo

2

(5,5,5) RGB, 1 bit extra (interpreted as alpha or env map blending)

equivalent to GL_RGB5_A1 OpenGL image format Neo

Q: Does the interpretation of the high bits depend on the 0x88 settings? geyser

A: Same as for 0 store type. Neo

8

(8,8,8) RGB, 8 bits extra

extra bits are ignored, equivalent to GL_RGB OpenGL image format Neo

Q: (sorry) are the extra bit always ignored, regardless of the 0x88 settings? geyser

A: Again, if it's RGB then it's RGB and not RGBA. If I remember correctly only skyboxes have this format and they don't have/need alpha anyway. If you need an RGBA format try store type 7, with some luck it will work. Neo

9

compressed (four times) (algorithm detailed elsewhere)

equivalent to GL_COMPRESSED_RGB_S3TC_DXT1_EXT OpenGL compressed image format Neo

(note: ARB stands for Architecture Review Board, not Alpha Red Blue ^^ geyser)

Q: Aha, "dxt1". Any more ideas looking at BSL:PC vs. Mac Comparison (list)#Only_on_Mac_beta_4? geyser

A: gl_disable_dxt1 probably decompresses the texture before passing it to Open GL. On the current videocards DXT1 is always supported and hopefully correctly implemented but when Oni was created things weren't necesarily as today. The 3 options are similar probably, either needed because of videocard/driver issues or maybe simply for debugging and testing. Neo

Anything else?

Q: (sorry) nothing else, ever ever? ^^ geyser

flag values are powers of 2

When you open OUP, dat editor and choose for example "contrail4444" then you will see "05" at offset 0x88. But that flag isn't explained here. Same "50" and so on. All the listed files have one or more unknown flag at offset 0x88. The question is what does they stand for. -- Or do I have overlooked their meaning??

Paradox-01 19:40, 17 July 2008 (CEST)

05 = 04 + 01 50 = 40 + 10

All flag values are powers of 2 and they can be combined by addition. For example if you want to disable both U and V wrapping you need to use 0x04 + 0x08 = 0x0C.

Neo

Ah that's cool^^ Big thanks.

Paradox-01 20:05, 17 July 2008 (CEST)

issues with combined TXMPs

(TXAN in PSpc doesn't seem to work. --Dox) (TXAN is not an image, but a list of images: do you mean an animated TXMP, which uses a TXAN and a set of TXMP? --geyser)

do you mean an animated TXMP, which uses a TXAN and a set of TXMP? Yes. I created a "TXMPh_19_B" which is actually 7 TXMPs and 1 TXAN, and wrote that name (TXMPh_19_B) into "PSpclevel_19_part". -- I guess to say "TXAN in PSpc" isn't correct then, hm? Would be "animated TXMP in PSpc" better? --Paradox-01 22:17, 12 October 2008 (CEST)

Yes, "animated TXMP" is better because if you say TXAN, people like me will get the impression that you're doing something wrong, and will ask you stupid questions. Also, when you say it "doesn't seem to work" you should give some details. What does it mean that animated TXMP don't work in PSpc, or that reflectivity doesn't seem to work for animated TXMP? try to make the result of your experiment clear to others. --geyser 00:13, 13 October 2008 (CEST)

• Ok, first case: I modified a Fury head texture (giving it alpha channel and a reflectivity map which was an animated TXMP). One images of the set was taken but no other more. (screen shot)

• Second case: a striker got an animated TXMP for some body textures, every TXMP of a set should use a reflectivity map but these parts became transparent. (screen shot - Halloween Striker ^_^)

• Third case: Part specification uses simple TXMP but I tried an animated on and it didn't work. It can take images out of the set but only one. --Paradox-01 16:33, 13 October 2008 (CEST)

So you haven't kept the modded instances you used? Bad boy ^_^ I'm pretty sure the second case, at least, should work. Oh well, I guess I'll have to try all three by myself some other time. --geyser 16:59, 13 October 2008 (CEST)

Irony of life: case 2 is already deleted. But you can have a look onto the others: case 1 and case 3.

PS: Reflection means to me a mirrored image. I call our reflection a fake since it doesn't reflect (mirror) the environment but shows another image. Look at the fury's head closely: there's just the bomb_fire texture inside. --Paradox-01 17:59, 13 October 2008 (CEST)

If you consider non-convex objects (like two mirrors "seeing" each other), you can see that "real" reflections of the environment would be very heavy to compute (the multiple reflections can require a virtual infinity of rendering passes), so naturally games use more or less elaborate "fakes". Oni's fake is actually quite primitive and a reflective ball, for example, won't look realistic at all as you move around it (I hate that ^_^). But I digress; I was just confused by the word "inside" as you used it. Now... back to cases 1-3: cases 1 and 3 indeed "don't seem to work"; for 3, the engine ignores animations when setting up the envmap; for 1, it's a shame, but the engine ignores animations when setting up the windows, too; 2 does work, but since OniSplit doesn't allow you to create the right thing directly right now, both of us had to use a workaround and I have no idea where you messed up. Try again ^_^ --geyser 02:33, 14 October 2008 (CEST)