Hello there people!

You can call me an idiot, as I'm sure I am. After a week now, I've been trying something out this night and was shocked... the idea worked, and was so simple I didn't even think of it!

Take a look at this pic... I bet Bastila looks a bit weird now. :D



This thing has helped me a step torward understanding the format BW has been using for their compression. But the texture used on Bastila is nothing else than a standard compressed 24 Bit TGA.

Necessary steps for something like doing this :

1. Find out what file in the TexturePacks you wanna change. (in my case "P_BastilaBA01")

2. Open the file with a Hex-Editor and look at bytes 8 - 12. There you'll find the texture X & Y sizes, just calculate them to decimal system and you can fire up the graphic program of your choice.

The right sizes are very important, otherwise the TGA won't show up!

3. Make your Texture and save it as 24 bit TGA. Name it exactly as the texture you want to exchange, with the ".tga"-ending.

4. Put that file into your OVERRIDE-folder

5. Fire up KotOR and look at what you've done. :D

Current downside is that I'm still unable to extract the needed image data for any true skinning, so you'll either have to play around a lot or wait until I figure that out as well. But I'm at it people. This discovery makes some things somewhat easier and more transparent.

Just wanted to let you know.

PS. : I told ya, Lil' Jawa! :D

Phelon, I have been working on extracting textures directly from the erf files with limited sucess. Now, when you say to look at bytes 8-12, you mean that P_BastilaBA01 has already been extracted, but is not in a tga file, right? I haven't been keeping up with you skinners on things so I don't know where that file came from. Did you extract it from the erf files, or the bif file? Sorry if I'm uninformed, but I'm a programmer and have been spending most of my time modding the save files.

oh yeah. very good news.

as soon as we get this out of the realm of programming, and more into the realm of art, i'll be a little happier though.:) i am however very happy that someone who would not normally be doing any skinning is taking the time to figure it out for those of us who are, for lack of a better word, programming impaired. :)

I knew you could do it! :)
Though to say the truth, I think Bastilas new outfit looks kinda.... creepy :P

Good Morning everybody! (saying this around 18:00 makes me feel a bit weird though...)

Devanstator :

Textures always come from the ERF-Files, they are in the TexturePack directories. For extraction purposes you can use the ERF-Tool for NWN, reinserting does not work right with it though.

The original Textures are not, I repeat, are not TGAs! Do not try to insert a TGA instead of another original texture into an ERF, it will not work! (in case of the "swpc_tex_gui.erf" KotOR will crash on you!)

I'm a (bad ?) programmer as well, I don't really have hand for art. :D

eidospsogos :

Maybe I'll throw out a quick utility for getting the sizes from the ERFs directly, so you can work with it a little easier. That wouldn't be a bad idea. Okay, I'll see what I can do.

Lil' Jawa :

I bet you wanna see the texture I used on her. Might be good for a grin.

http://members.chello.at/vhd/TextureUsed.png)

Good greif, and all this time I was trying to make an erf extractor. I knew there were some tools you could use from NWN, but I thought they were for something else. How do I get ahold of this NWN erf extractor?

Ok, I got it. These files that have been extracted are directly from the erf files. The greatest sucess I have had before this was to do this same thing. I was able to guestimate where a file started and ended and I took it from the erf file. You're right, these aren't tga's. They have a 128-byte header and don't match any filetype I can find specification for. I almost thought they were .pcx but that doesn't work either. There must be a way to change these files from their present state to a tga that can be worked with. Then the skinners will be unleashed. ... must figure it out.

Devanstator :

Actually the ERF-File is so plain simple, I've never used the ERF-Tool from NWN. I simply wrote myself a utility to extract and rebuild it. :D

About the textures : I could give you a description of what I found out about the texture format, and you could give me a hand at figuring it out. How about teamin' up on that, Devanstator?

That's great, Phelon, here's what I've learned. Once I had a clear look at these files, it took very little time to derive the following:

==============================================
-Files extracted from an erf have a 128-byte header.

-At offset 8 is an unsigned short for width

-At offset 10 is an unsigned short for height

-Immediately following the header is the image data

-Byte order is left to right, bottom to top

-32 bits for a pixel (Red,Green,Blue,Intensity)

-Image data ends at offset = (x*y*4)+128

-The file footer is some number of strings like "mipmap 0", which must be discarded

==============================================
-The Targa files have an 18-byte header.

-At offset 12 is a short for x-dimension

-At offset 14 is the short for y-dimension

-Immediately following the header is the image data

-Byte order is left to right, bottom to top

-32 bits for a pixel (Blue,Green,Red,Intensity)

-Image data ends at offset = (x*y*4)+18

-The file footer is unimportant info followed by "TRUEVISION-XFILE"

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
HOW TO CONVERT FROM ERF-EXTRACTED FILES TO TARGA

-Create new targa file and place first bytes as "000002000000000000000000"

-Get 4 bytes from other file at offsets 12-16 and put in tga file

-Place "2008" to complete the header

-Read each set of 4 bytes from file and switch byte 1 with byte 3 then place it in the tga

-Keep doing this until your read point is at offset = (x*y*4)+128

-Add "000000000000000054525545564953494F4E2D5846494C452E 00" for the footer

-Save file and you are done. :D

------------------------------------------------------------------------------------

I have just started writing a program to do this and since I still have all my low-level c functions handy I can borrow them from Kotor Mod Utility. Within 48 (I hope) hours skinning in Kotor will be no harder than any other game.

wow! you have no idea how happy it makes me to hear you say that. and maybe that is a bit sad. :)

Something about your files extracted from the ERFs, does not totally match up with my finding. But I've been studying the GUI-ERF more closly, they are somewhat diffrent. As I found this would be the easiest, I have started of with "800x600back", the smallest Background GFX I could find. Here are my observations :

----------------------------------------------------------------------

The first 128 bytes of an image always consist of the image header, of which only the first 16 bytes are actually used.

---------------------------------------------------------------------
Part 1 : Possible Header (Hexadecimal Listing)
---------------------------------------------------------------------
00 00 04 00 | 00 00 80 3F | 00 02 00 02 | 04 01 00 00
---------------------------------------------------------------------
1. (4 bytes) These bytes seem either to have something to say about the exact filesize, or are used as an image identifier, I don't know for sure. But they often (not always) match up with the exact data size used by the Image.

2. (4 bytes) Unknown, haven't found out anyhting about these 4 bytes, except that the example values are used in most GUI-Images and also in a few TP-Images.

3. (4 bytes) Looks like X & Y Dimensions.

4. (4 bytes) I don't really know, but it is important.

IMPORTANT NOTE : An incorrect header within a GUI-Image results in a crash to the desktop, and might have a complete hangup following up.

----------------------------------------------------------------------
Part 2 : Possible Image Data (Hexadecimal Listing)
----------------------------------------------------------------------
00 FF FF FF | FF FF FF FF | FF FF 00 00 | FF FF FF FF
----------------------------------------------------------------------

1. (1 byte) This is a Color Saturation or Alpha Value for the Background Color ranging from 0 to 255.

2. (7 bytes) These 7 bytes are a mystery I haven't figured out yet. But some of them have an influence on Colors as well. I can't say for sure though.

3. (2 bytes) Those 2 Bytes are the Value of the Background Color, encoded in 565-format, the latter is the HIGH BYTE.

4. (2 bytes) Same as 4, only Value of Foreground Color.

5. (4 bytes) This model might vary, but that's some info that might be read from the header. With this header it looks as follows :

------------
|xxxx| 4. Byte
|xxxx| 3. Byte
|xxxx| 2. Byte
|xxxx| 1. Byte
------------

The x's are pixels set in those bytes. Every pixel consists of 2 bits, that seem to change the color adjustment.

bitwise 00 = Don't draw Foreground Color
bitwise 01 = Draw FGC Method 1
bitwise 10 = Draw FGC Method 2
bitwise 11 = Draw FGC Method 3

I'm not sure how exactly these methods final values are calculated.

NOTE : The entire image is built up in rectangle-shaped parts, starting from the bottom left to the top right. Reminds me of the good old BMP-format...

---------------------------------------------------------------------
Part 3 : Possible Optional Data
---------------------------------------------------------------------

This varies in size, most of time you find a "mipmap 0 " followed by Hex Values 0D & 0A, but also some even weird constellations.

Some of the other GUIs GFXs are simply RGBA encoded, nothing to worry about, as this is more than easy. "Redfill" or "Blackfill" for example.

Good point, I guess I should have tried my method on other files too. I was playing around with blackfill, redfill and greenfill because they are only 155 bytes. I think the tricky part is going to be that there must be several different file types represented here. I think some of them were bitmaps before being archived, but there's not much to tell which is which. The program was coming along great, but I think I got carried away before figuring out how to convert all of the files. hmm... Perhaps I should continue and see what it does to the files that don't work. That would give a clue as to what to do with those ones.

is there a better process than that of elimination through trial and error based upon educated quessing? :) there may well be, but i wouldn't know.

eidospsogos

Yah, beating the info out of someone who created the format. :D

Sorry to eidospsogos, but even the possibilities of the best programmers are limited to this, if he has a type of file that is not similar to any other graphic format available. He would as much have to figure out by trial an error as we do.

Devanstator :

BTW Devanstator, about your guess about how the file is encoded. The info must be in the header, speaking logically, but can only be at positions 5-8 or 13-16. These got nothing to do with the filesize, so it's the only logical explanation. You got a chat or something where we can meet up, and discuss all the details without having create bandwith overflow on this board? :)

I have msn messenger, but not ICQ or AIM. I am devanengland@hotmail.com (I like to keep it simple).


I am researching RLE compression now.

uhhh....it was just a joke. i wasn't making a crack at anyone. trust me i'm much more in the dark than either of you. i managed to get in there, but as the only skinning i have ever done has been for quake type games, i was a bit confused by what i found.

so both of you are better off than i am. i was attempting levity.

eidospsogos:

I knew, but I was bored... and only the first comment would've looked so alone. :D

well trust me for my sake i wish you guys the best of luck. skinning is really the only thing i've ever done as far as game modding is concerned.

it took a little bit of figuring things out to skin for single player in JA, what with the exta model components and all. and heck i was proud of myself for figuring out how to use those multi-model .skin files and the alpha transparency levels in their .pngs(which actually turned out to be more of a problem with photoshop handling the .png format incorrectly....took forever to find a plugin that would work) but this is way out of my league. :)

so good luck on your progress. i am with you in spirit. :)

Devanstator:

That damn MSN doesn't really work at my end... oh well.

But that's not why I'm here. I finally found out where we can determine the encoding, and an estimate of how the encoding variants look like.

---------------------------------------------------------------------
Possible Header (Hexadecimal Listing)
---------------------------------------------------------------------
00 00 04 00 | 00 00 80 3F | 00 02 00 02 | 04 01 00 00
---------------------------------------------------------------------

1. (4 Bytes) These bytes are the exact Image-Size in bytes (scrap the rest of the file). If zeroed out, it might be that the encoding variant is RGBA. I have found this true for Redfill, etc.

2. (4 Bytes) Still Unknown, but defenitley not so important

3. (4 Bytes) X & Y Sizes, as we both know

4. (1 Byte ) 16-Bit Encoding Method

I have found 2 types of encoding methods by now. All create a 4x4 rectangle that is blitted on screen.

Variant 1 [04] = 16 Bytes - That's the variant I explained in my post above

Variant 2 [02] = 8 Bytes

Built up like this :

2 Bytes .... 16-Bit Background Color (565-Encoding)
2 Bytes .... 16-Bit Foreground Color (565-Encoding)
4 Bytes .... Pixel settings in the 4x4 rectangle using exactly the same method as mentioned in Variant 1.

5. (1 Byte) Unknown, a resource number perhaps

6. (2 Bytes) Always 00 00, therefore unknown
--------------------------------------------------------------------------------
Summary :

Once we can figure out how the color set is calculated by the Drawing Methods I outlined, we KNOW how to deal with all of KotORs textures.

Originally posted by The Devanstator
Then the skinners will be unleashed. Oh yes...the skinners will be unleashed <evil grin>

Excellent work guys. As a software designer I know how things like this can be a pain in the ass :)

Perfect, and I have a program shell ready for when we do. I've been trying to get a screen capture that is identical to a texture (which might be pretty hard) but by comparing them, I'd be able to figure out which colour a pixel is supposed to be and maybe how they encoded it.
A neat little thing that I found was that textures are "hot swappable" or they can be changed or switched around while kotor is still running. Also if you have a texture that is in the override folder and you remove it while it's running, then kotor will not load the original to replace it. It will just be white.

Also, a while back I tried modifying the erf file directly and it didn't seem to make any difference. Have you tried that and did it work for you? If we can start changing some values to see what difference they make to the textures, then we'd have a better idea what each byte does.

Alright, here's another hurdle. I took a screenshot of my feats menu ingame and brought it directly into photoshop. Then I took i_empathy03 (the feat graphic for master empathy) in the gui erf and replaced it with one that was solid red. The texture's header said it was 32X32 pixels so I made mine that size. It worked fine and when I looked at my feats there was a small red box where the picture used to be so I screen captured that too. Then I selected the box texture which was clearly defined and then dragged it into the first screen so I would have a selection of the same size and shape. I positioned it over the empathy graphic and copied that into a new texture. The only problem was that this selected area was only 27x27 pixels. I played around with it more, making sure there were no resizing errors and found that i_empathy03 actually is 27 pixels but was then blown up.
The texture had to be resized to 32 (the nearest higher power of 2?) for Kotor to display it properly.
This means that probably many of the textures, once we sucessfully convert them, will be blown up by an untold number of pixels. I tried to find header data that could represent a 27 or 5, but I don't think it's stored in the file.
Just another thing to keep in mind.

Devanstator:

The hurdle is KotOR itself, as almost no graphic is displayed in the designed size. Images are all a multiple of 2 in size, and stretched or shrinked acccordingly. Images must in all cases be a multiple of 2 in size. I've examined the i_empathy3 Image you named, and I find it sustains my guesses up to now.

Size of it is 4235 Bytes.

In the Header :
Data Size = 0, encoding therefore is RGBA.
Image size is 32x32 according to the header.

Calculation:
Header + RGBA +Optional = Final Size
128 + (32 * 32 * 4) + 11 = 4235

Summary :

The Image is 32x32, regardless of what it is displayed in the engine. "800x600back" is also 512x512 in size, and then stretched to 800x600. Go make a 32x32 Tga, name it "800x600back.tga" and put it in the override folder, fire up KotOR and you'll see I speak true. It alway must be a multiple of 2, how it is stretched is somewhere else to find, but not in the Textures. :)

-----------------------------------------------------------------------------

Color Calculation :

I did change the colors directly in the files, and reinserted them in the ERF so I could find out what they are doing. How did you think I came up with all the info I extracted? :D

BTW Color Calculation Mehtods seem to be something like this:

00 = BGC
01 = ( BGC / 4 ) + ((FGC / 4) * 3)
11 = ( BGC / 2 ) + (FGC / 2)
10 = (( BGC / 4 ) * 3) + (FGC / 4)

Assumption taken on fully maximum color values, make up something like (255, 255, 255 | 62, 62, 62 | 126, 126, 126 | 190, 190, 190). I haven't tried this out with other colors as of yet, but it's a guess.

Update - 8 Byte Method verified

I've written a quick tool to the job for me... unuseable by anyone else, but it has helped me figure out that my methods for the exact color calculation are wrong. I still do not know how the color is calculated right.

But I've made a cross-examination. The colors do not match at any rate, however the shapes of both images (original and converted) match up with each other, so the decoding process seems to be correct.

It seem I was right, when I said all we had left was to find out the color calculation process. Oh, I love it when I'm right. :D

Excellent. So this app you made, it was able to convert into a readable targa, but the colours were wrong? Even so, the colour might be hard to absolutely verify. I'm afraid that most of what we're doing is new territory for me, but I'm learning as I go and the whole technology is fascinating, but sensical.
Also, all that I meant above was that final converted textures will appear pixelated because of their size. Skinners may have to scale a texture down before working on it and then blow it up again before placing it in the Override folder.

Devanstator:

It is able to convert the original into a RAW-RGB-Image, as this was easier for me. Colors were so far off, I was getting a headache. The colors should've been brown tones, but I got only violet tones.

Anyhow, I'll be studying how the color changes apply exactly, and maybe figure out the color alteration.

BTW, we can use a 32x32 Pixel Image to find out. I've noticed that 32x32 is the exact size the XP gained-Sign, DS-Points gained-Sign (lbl_idside) and the LS-Points gained-Sign (lbl_ilside) are stretched to. And for example the Gizka Skin (C_Gizka01) is exactly 32x32 in size, therefore we can get an image that is not altered in size in the game.

Hmm... another guess as well. In all my studies I have never changed the graphic mode, I'm trying to figure it out on 800x600. Maybe when screen size goes up, the image might be stretched more, I haven't tried out yet. So I don't know if the above idea is only applicable under 800x600 or under the other screen modes as well.

Hmm. The 8-byte encoding definitely sounds like S3TC or something very similar. As for the other, I'm not sure, good luck =)

(Edit: I was going to mention this but forgot: in case you were unaware, the extension for these textures is '.tpc' if you want to generate them for your override directory - there might be problems with running out of texture memory if you try using a bunch of TGA textures. Also, at least part of the data after the pixel data (the text part) appears to be the same format as the .txi (texture information) resource type, so you might want to keep that around somewhere as well)

eiz:

Thx for the info. It looks like you've done your homework well. :)

You might be right about the S3TC-format... it is very similiar, if not the same. I have not tested yet, but it may very well be that it is handled exactly like that. I'm goin' to try it's color calculation method out. If it works, we've got one of the biggest problems off our hands, thanks to you.

That hint on txi-format does make sense. However some of the files do not simply have text at it's end, but an additional number of bytes beforehand, I don't know how to deal with, since the Image ends sooner. Something to research after the color calc. mehtod has been proven right. From looking at the S3TC-format info, it defenitley looks good.

BTW, there's also a 16 Byte - Model described in the ST3C-info I found, and it looks like it also matches up.

I was thinking about the extra data as well. It's possible that it is pre-generated mip-map data - I'm doing some testing now.

So far, so bad...

The color calculations of the S3TC-format do not match up with the original colors, though the output is much better than my first bad formula. :(

But it seems like they used the S3TC-format for a base on which to build. I'll be playing around with some color variations now, and hope I'll get to the bottom of this.

I don't believe it's likely that they would use a texture compression format that wasn't supported in hardware directly - it would defeat the purpose of using compression at all.

I have written a test program, it only handles the 8byte version but it seems to fairly accurately render those textures. Binary is here (http://blitz.phpwebhosting.com/eiz/tpc32_view.exe), source is here (http://blitz.phpwebhosting.com/eiz/tpc32_view.cpp). Give it a .tpc file on the command line.

(Edit: err... uh... that will only show the top left 128x128 pixels, BTW. This was mainly for my own use and I didn't really clean up before posting it. If you want to see more, change the BitBlt call)

Works fine with some Textures, but not with all. I've tried it on "C_Gizka01" and it looked pretty good, but had 2 vertical lines at the right side that were simply not matching up with anything. But not so bad.

On the other hand, I've tried to view "lbl_idside", which is the same size, same byte compression, and all I got was blackness, with a few colored dots. That means, something still is going wrong. But you've done well so far... even better than what I am able show.

Yeah, I don't know what's happening with the lbl_* textures. They were originally 'sort of' rendering, but now I'm just getting junk. I'm sure it's a problem with my implementation of S3TC, however... time for more bug hunting. ;)

Edit: Actually, are you sure lbl_* is in the same format? I'm looking at the header and seeing some pretty large differences...

Further Edit: Just checked, lbl_* are 16-byte. The Gizka texture shows fine for me, albeit with a black bar on the far right side (although that may be there on purpose). Also, the 1-bit alpha implementation in the version I uploaded is not there, but I have since added it.

Oops, sorry that was my playing around with the files actually. Exchanged the "lbl_idside" with "C_Gizka01" and played around with it a while. I only had a GFX with BLACK and few colored dots. That's why it ended up displaying garbage. :D

About the Gizka Texture... if it really has that black bar, I have not seen it up to now, and I'm positive that it should not be there, unless you've gone outside the image range. Even my litte tool wrongdoing the colors does not show this black bar on the right side.

Edit :

Is it just my imagination, or do almost all, if not all, 16 byte encoded textures use "00 FF FF FF FF FF FF FF" as pregcognition, before the 8 byte-encoding comes along?

Yeah, the black bar is definitely a bug, and in addition either I'm getting stairstepping or my interpolation is wrong (likely, I can never remember how to do it) because it's very very blocky and it shouldn't be.

Edit: Oops! The black bar was just a trivial arithmetic bug in my call to DrawTileI. I've uploaded a new version. It's still a bit blocky, I think it's because I'm too stupid to figure out the right order to draw the pixels in. =)

Edit 2: I believe I have it functioning fairly close to correctly now. At least, it doesn't look as blocky as it did... My eyes aren't too great and I can't tell if it's still got problems.

i worked at s3 and did some of the original work on that at one point, so just figure i mention a few things:

1. although 565 is the most common format, there is also 1555 and 4444 with alpha

2. although the most common compression is two endpoints and two mid points (at 1/3 and 2/3), there is also a format with two endpoints and one mid point (at 1/2).

3. it might be the simplest way to experiment with this is to use d3d calls to test out the compressions once you have the file loaded. (see msdn dx texture section).

4. I did a quick search and manage to find a much modified doc of what i had wrote originally at microsoft at:
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/graphics/programmingguide/FixedFunction/Textures/compressed/texturewithalphachannels.asp)

also there is a text version of the attempt to get this into OGL at
http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt)

hope that helps

eiz:

Sorry for my late response... I've had a lot of work today, and I'm still not through with it. Will take a few hours... god, I hate a day with more than 12 hours of work. :(

If my eyes don't deceive me, you've managed it. From what I can tell, and I don't believe my eyes are far better than yours, it looks very good now. The colors seem to match up exactly, I can't see a diffrence when putting the original and the texture next to each other.

aveeare:

Thanks for letting us know. Hopefully eiz does find the info more useful than me, since this is pretty much out of my leauge. As anything that has something to do with WIN-Programming, like DX.

Currently I'm working on a TPC to TGA converter, and I'm having a bit of a problem - the 'encoding type' field in the header seems to have very little to do with the actual encoding type in the file. It handles the DXT1 textures I had been throwing at it fine, and I've written DXT3 support (DXT5 to come - I don't think I will need support for the premultiplied formats DXT2 and DXT4), but, I don't know... look at ip_lightning and lbl_levelup for example. I will continue to look into it.

aveeare: Thanks for the information. I've been referring to the MSDN DXTC docs, but I didn't notice any references to a 4444 or 1555 color format.

As for testing with D3D, well, I'm more comfortable with GL since I've been a Windows user for a grand total of 2 weeks in this century, but I've definitely been considering it (provided I can get the DX SDK to actually work with MinGW).

Edit: Oh yeah, and it also doesn't help that I goofed my pitch calculation... at least I can read those big mainmenu textures now (2048x1024) =)

eiz:

Hmmm... ip-lightning does seem to be in RGBA from a quick look, and givin' the data-length-descriptor (which is zero) would point the same direction like redfill, and the others have done so far. So from the quick glance, I do not see anything wrong, as there's mostly the Alpha Value changed in the beginning.

About "lbl_levelup" .... about the center of the file it starts to look somewhat like the Background-Images. What we know is that the second 8 Bytes hold the colors and the pixel bits, I believe it hold true for this one as well. Maybe, I've never said what I've wondered about this format, but I guess it's time.

FF 00 00 00 | 00 00 00 00 | FF FF 00 00 | 00 00 00 00

did do exactly the same for me as

00 00 00 00 | 00 FF FF 00 | FF FF 00 00 | 00 00 00 00

and gave me a totally white box. I was trying this one with "800x600back". Any other combination of the first 8 bytes, without the first byte set to FF, has given me black box. It might tell you something it didn't tell me, so I figured I might simply let it off.

That's it for me today folks... I'm just done with work and my bed calls out to me. Maybe I can be a little more active again once I've got enough sleep.

Ahh yes, I had forgotten about the 0 data length = RGBA encoding thing, although I'm still trying to get DXT3 and especially DXT5 which is a creation of the purest evil to function properly. Hopefully I will be able to get it working tonight.

As for your experiment, the former 8 bytes of a 16-byte block control the alpha, which should explain your results. Everything else (except the 1-bit alpha mode) is the same as DXT1.

Last week I started working on a TPC to TGA converter. I've got an initial version for testing here (http://blitz.phpwebhosting.com/eiz/tpc2tga.exe) ( source (http://blitz.phpwebhosting.com/eiz/tpc/) ). There's at least one texture type that is not properly handled, but the DXT1, RGBA and DXT5 textures work alright, I think.

First off, Hi there. :)

Been lurking a little while, and slowly learning how to do some tinkering with scripting and whatnot as I follow along with various threads and whatnot.. This topic holds considerable interest for me, as I've always enjoyed messing with skins and models for various games, though my knowledge of format conversions and extraction and decompiling and filtering etc of various files is very low.

Sooo.. First, the noobish question...
Is there a way to actually extract the models as of yet? (and get them into a format which can be edited by any of the various programs for the purpose?)

And now my (probably noobish) attempt at helping with this texture thing.. I see a lot of conversation about formats and headers and the like, and while messing around with various files, I came across this little bit of a 2da. (File is texpacks.2da)


2DA V2.0

desc texture gui strrefname dynmemratio mem
0 32MB_32BIT swpc_tex_tpc swpc_tex_gui 48003 0.750 31457280
1 64MB_32BIT swpc_tex_tpb swpc_tex_gui 48004 0.750 62900000
2 128MB_32BIT swpc_tex_tpa swpc_tex_gui 48005 0.750 134217728


Anyways... wondered if any of that is remotely helpful for you gurus who are/were trying to get these things into TGA format and the like.

Keep up the good work in any case. ;)

-Kitty

Yes, the game's textures are stored at 3 resolutions for video cards with different amounts of VRAM. You can choose which one you want in the advanced graphics settings, IIRC.

As for models, not as far as I know but I'm getting started on that today, since tpc2tga is largely working =)

thanks guys for the tool.by the way does anyone know which are the player skins,i tried a bunch of them but i cant find a player skins.help!:(

nevermind that i found it but does anyone know how to get to the bumpmaps?

okay, not to sound stupid, though i do quite often and probably will again, but this looks like a dos based program, as everytime i try to run it, a little dos window pops up and goes away almost immediately. so, someone refresh my memory on how to use converter programs like this. because i sure as hell seem to have forgotten. :)

Put the exe in the same folder as the files you've extracted that you're going to want to convert.

Then either write a batch file to do them all one after another, or just open a command prompt (start menu, run, "command") and change to that folder with the CD command (remember that for a folder name longer than 8 characters you have to type the first 6 letters and ~1)

So like for me it's like this (enter at the end of each line obviously)
D:
CD Games\LucasA~1\SWKotOR\Override

Anyways, then the command line is simply tpc2tga.exe <infile_name> <outfile_name>

Wise to name the TGA the exact same name, just with the new extention so you can keep them straight unless you're also going to be doing some custom work in the data to point it to new file names for some reason.

Hope it helps.
-Kitty

How do you write a batch file to do them all at once? That would be like heaven...

And does anyone know where the textures for all the different armours are?

See my most recent post in this topic. Explains how I did the batch, as well as where the files are located. ;)

Clicky clicky (http://www.lucasforums.com/showthread.php?s=&threadid=121624)

-Kitty

Yeah, I just noticed that. I figured out how to make a batch file, but i don't have a word processor with macros. :mad: :(