18,970
edits
OBD talk:TXMP: Difference between revisions
m
link fix
m (→0x 80 00 00 00) |
m (link fix) |
||
| (37 intermediate revisions by 6 users not shown) | |||
| Line 2: | Line 2: | ||
:For one thing, incomplete/inaccurate knowledge may be a reason why repacking (with OUP) fails. | :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. | :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 | :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. | :One not-too-comfortable aspect is that apparently contradictory settings for the 3 bytes are ''somehow'' interpreted by Oni. | ||
::[[User:Geyser|geyser]] 21:09, 3 February 2007 (CET) | ::[[User:Geyser|geyser]] 21:09, 3 February 2007 (CET) | ||
;[[wp:Mipmap|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. | |||
;[[wp:Alpha compositing|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. [[User:Geyser|geyser]]) | |||
| | |||
| | |||
==Bitsets or indices== | ==Bitsets or indices== | ||
;Store type (0x90) | ;Store type (0x90) | ||
| Line 101: | Line 54: | ||
:Well, IMO they're bitsets. I fixed that a long time ago. [[User:Ssg|Ssg]] 10:59, 13 February 2007 (CET) | :Well, IMO they're bitsets. I fixed that a long time ago. [[User:Ssg|Ssg]] 10:59, 13 February 2007 (CET) | ||
:You "fixed that" ''where''? I can't see it detailed on OS... [[User:Geyser|geyser]] 04:05, 6 March 2007 (CET) | :You "fixed that" ''where''? I can't see it detailed on OS... [[User:Geyser|geyser]] 04:05, 6 March 2007 (CET) | ||
:[http:// | :[http://ssg.oni2.net/oni_txmp.htm Here?] [[User:Ssg|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... [[User:Geyser|geyser]] 13:41, 6 March 2007 (CET) | :Not that it matters now, but IIRC you had ''not'' uploaded that update as of 2007/02/13... [[User:Geyser|geyser]] 13:41, 6 March 2007 (CET) | ||
| Line 153: | Line 106: | ||
: | : | ||
:rgb555, rgb565, rgba5551, argb1555, argb4444, rgba4444, rgba8888, s3, compressed, i8, i1, i4a4 | :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) | :(r=red, g=green, b=blue, a=alpha, i=intensity; see [https://web.archive.org/web/20130909194954/http://www.cg.tuwien.ac.at/~wimmer/view3dx/TEXUS.html HERE] too) | ||
| Line 163: | Line 116: | ||
Bitset (rather large: 18 bits at least) bytes are listed in Little Endian | Bitset (rather large: 18 bits at least) bytes are listed in Little Endian | ||
====0x 01 00 00 00==== | ====0x 01 00 00 00==== | ||
:MIP mapping enabled (generations stored in | :MIP mapping enabled (generations stored in raw/separate file, used at runtime) | ||
:Q: Anything special about MIP mapping of DXT1-compressed pixels? | :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. [[User:Neo|Neo]] | :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. [[User:Neo|Neo]] | ||
| Line 176: | Line 129: | ||
:Enabled for env-mapped textures and env maps themselves. | :Enabled for env-mapped textures and env maps themselves. | ||
:Q: Also enabled for skyboxes? Exact effect? [[User:Geyser|geyser]] | :Q: Also enabled for skyboxes? Exact effect? [[User:Geyser|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. [[User:Neo|Neo]] | |||
====0x 20 00 00 00==== | ====0x 20 00 00 00==== | ||
:used a runtime (marks if a texture name has been allocated for this TXMP or not) [[User:Neo|Neo]] | :used a runtime (marks if a texture name has been allocated for this TXMP or not) [[User:Neo|Neo]] | ||
| Line 202: | Line 157: | ||
:Q: Ever used? Effect? ^^ [[User:Geyser|geyser]] | :Q: Ever used? Effect? ^^ [[User:Geyser|geyser]] | ||
:A: There is no texture in any level that uses it. If it is of any use that's only at runtime. [[User:Neo|Neo]] | :A: There is no texture in any level that uses it. If it is of any use that's only at runtime. [[User:Neo|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==== | ====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 [[User:Ssg|Ssg]] 11:06, 13 February 2007 (CET) | :On if there are 16 bits per uncompressed pixel (color depth etc may vary) ==> no changes ==> Oni reads it directly from the raw file [[User:Ssg|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. [[User:Neo|Neo]] | :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. [[User:Neo|Neo]] | ||
:Q: Whom is the swapped data relevant to, then? "Texture format" = "store type"? "Number of bits" = RGB color depth = "store type"? [[User:Geyser|geyser]] | :Q: Whom is the swapped data relevant to, then? "Texture format" = "store type"? "Number of bits" = RGB color depth = "store type"? [[User:Geyser|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. | :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. [[User:Neo|Neo]] | ||
====0x 00 20 00 00==== | ====0x 00 20 00 00==== | ||
:IIRC, that bit is never used in Oni. If you use it, Oni chrashes. [[User:Ssg|Ssg]] 11:06, 13 February 2007 (CET) | :IIRC, that bit is never used in Oni. If you use it, Oni chrashes. [[User:Ssg|Ssg]] 11:06, 13 February 2007 (CET) | ||
| Line 239: | Line 201: | ||
:Those 3 work the same for GL_RGB5 (pelvis), GL_RGBA4 (chest, head) and GL_RGB5_A1 (shoulders). | :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) | ::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 | :::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. | :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. | ::They correspond to hard-coded eye candy, specially designed for shields, phase cloaks and boss shields. | ||
| Line 246: | Line 208: | ||
::[[User:Geyser|geyser]] 02:33, 7 March 2007 (CET) | ::[[User:Geyser|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. [[User:Neo|Neo]] | |||
===0x90=== | ===0x90=== | ||
| Line 273: | Line 234: | ||
;9 | ;9 | ||
:compressed (four times) (algorithm detailed elsewhere) | :compressed (four times) (algorithm detailed elsewhere) | ||
::equivalent to [[ | ::equivalent to [[wikipedia:S3_Texture_Compression#DXT1|GL_COMPRESSED_RGB_S3TC_DXT1_EXT]] OpenGL compressed image format [[User:Neo|Neo]] | ||
:::(note: ARB stands for Architecture Review Board, not Alpha Red Blue ^^ [[User:Geyser|geyser]]) | :::(note: ARB stands for Architecture Review Board, not Alpha Red Blue ^^ [[User:Geyser|geyser]]) | ||
:Q: Aha, "dxt1". Any more ideas looking at | :Q: Aha, "dxt1". Any more ideas looking at '''BSL:PC vs. Mac Comparison (list)#Only_on_Mac_beta_4'''? [[User:Geyser|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. [[User:Neo|Neo]] | :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. [[User:Neo|Neo]] | ||
;Anything else? | ;Anything else? | ||
:Q: (sorry) nothing else, ever ever? ^^ [[User:Geyser|geyser]] | :Q: (sorry) nothing else, ever ever? ^^ [[User:Geyser|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?? | |||
[[User:Paradox-01|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. | |||
[[User:Neo|Neo]] | |||
Ah that's cool^^ Big thanks. | |||
[[User:Paradox-01|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? --[[User:Geyser|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? --[[User:Paradox-01|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. --[[User:Geyser|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. | |||
::* 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. | |||
[[file:messed_up_Striker.jpg|thumb|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. --[[User:Paradox-01|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. --[[User:Geyser|geyser]] 16:59, 13 October 2008 (CEST) | |||
::::Irony of life: case 2 is already deleted. But you can have a look onto the others: <nowiki>http://www.paradox.oni2.net/temp/case1.zip</nowiki> (dead link) and <nowiki>http://www.paradox.oni2.net/temp/case3.zip</nowiki> (dead link). | |||
::::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. --[[User:Paradox-01|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 ^_^ --[[User:Geyser|geyser]] 02:33, 14 October 2008 (CEST) | |||
{{OBD}} | |||