Natsuki Okusawa Posted May 1 Share Posted May 1 (edited) Now that it is at least possible to get models from this game now (Thanks again Murugo), the next thing to get would be the textures. However, it appears like just getting them from Ninja Ripper or anything similar isn't good enough, as the some textures extracted in this kind of method would appear to be abruptly cut, particularly some portions that are behind or off the screen when the capture was taken. In this model for example, the upper portion of the hair's back texture appears to be abruptly cut. So I guess the best way would be to get the textures from the data itself (the 'Untitled' file for example, which I pulled out from eeMemory manually with a hex editor). Opening 'Untitled' with a hex editor reveals some very recognizable patterns, which I think are obviously textures. These patterns can be found starting at offset 0x734d0 - onwards. Opening the 'Untitled' with TextureFinder does appear to reveal some recognizable patterns too. Here is the 'Untitled' file, but I added an extension (.mdl) if it is necessary. Untitled.rar Some more samples pulled manually from eeMemory just in case if they are necessary too. more_samples.rar Edited May 1 by Natsuki Okusawa Link to comment Share on other sites More sharing options...
Natsuki Okusawa Posted May 5 Author Share Posted May 5 (edited) I just found out that textures probably starts at 0x63def in the 'Untitled' file. The following just contains the data in the file that I suspect to be textures. Untitled_tex.rar Update: Opening the possible texture data I pulled in TiledGGD shows the patterns in a more recognizable way. Edited May 5 by Natsuki Okusawa Link to comment Share on other sites More sharing options...
piken Posted May 5 Share Posted May 5 It appears you already found the textures? Are you looking for a diagnosis of the .mdl file structure to extract them more easily? (and also to find where the palettes are?) Link to comment Share on other sites More sharing options...
Natsuki Okusawa Posted May 5 Author Share Posted May 5 (edited) I would just like to be able to extract or view the textures from the data I provided with their proper colors or palettes, resolutions and transparency. (The eyelid textures has transparency) Edited May 5 by Natsuki Okusawa 1 Link to comment Share on other sites More sharing options...
Natsuki Okusawa Posted May 9 Author Share Posted May 9 On 5/5/2024 at 10:12 PM, piken said: It appears you already found the textures? Are you looking for a diagnosis of the .mdl file structure to extract them more easily? (and also to find where the palettes are?) Sorry about this but any updates or anything? I have no idea how to find the palettes myself. Link to comment Share on other sites More sharing options...
Solution piken Posted May 12 Solution Share Posted May 12 (edited) On 5/9/2024 at 7:59 AM, Natsuki Okusawa said: I have no idea how to find the palettes myself. Some tips: Typically the palettes are stored in the same file as the image (not always, but almost always) and near the pixel data. Palettes are typically stored directly without compression because they're so small. For PS2, you will find 16-bit or 32-bit palette entries. For 16-bit entries, the bits in increasing order are arranged {redUfract5 greenUfract5 blueUfract5 alphaPremulUnorm1} where the MSB being 1 means fully opaque, and each 5-bit channel has 32 shades. For 32-bit entries, the bits are arranged {redUnorm8 greenUnorm8 blueUnorm8 alphaPremulUnorm8}, and the maximum alpha value is 80h (rather curiously not FFh). Searching for uint32's with the top byte 80 can help you find palettes (e.g. look with a hex editor like HxD in 1480000.mdl at 0x87F40 for a curious run of int32's with high bytes of 80h 🤔). PS/2 Palettes may be stored with spans of 16 entries in tiles of 8x2 blocks (so called "palette swizzling") in a larger 16x16 layout, but I'd try just displaying it with the linear palette first (the first 8 entries will be the same either way). If using Noesis, this tiling corresponds to the DECODEFLAG_PS2SHIFT option. Compare against the in-memory values of the palette at the point in the game where that texture is loaded, using that shade to search for a byte sequence in the files (like the orange shade above). Try deliberately corrupting parts of the data file that you suspect are palettes, and then play the game to see what changes, if anything. Edited May 12 by piken 1 Link to comment Share on other sites More sharing options...
Natsuki Okusawa Posted May 12 Author Share Posted May 12 (edited) I see, I could seem to find palettes now and they all seem to begin with a '99' byte. Now, how do I apply it properly to the image displayed? The palette data at offset 0x76bb0 in 15c0000.mdl for example appears to be for one of the hair textures. Update: Looks like some palettes starts with an '80' byte but with a '99 00 00 00' string before the '80', such as the one at 0xa25d4. Edited May 12 by Natsuki Okusawa 1 Link to comment Share on other sites More sharing options...
Natsuki Okusawa Posted May 12 Author Share Posted May 12 (edited) So... looks like I managed to figure it out, just check the graphics and palette data in the window for details. (The file opened is the 'Untitled.mdl' file, but I renamed it to '1700000.mdl', not that it matters but still...) It still would be great to have some tool/script to open/extract these textures but sadly I have no idea how to do that myself. 😢 Anyway, thank you very much for the help, I highly appreciate it. Edited May 12 by Natsuki Okusawa Link to comment Share on other sites More sharing options...
piken Posted May 12 Share Posted May 12 1 hour ago, Natsuki Okusawa said: I managed to figure it out Nice! That indeed looks like right. 1 hour ago, Natsuki Okusawa said: It still would be great to have some tool/script That would take much more time (staring in the hex editor wondering what the various fields of the header are, writing a script in Python/C/C#/010/imhex..., using libraries like Noesis or BMS...), but it could also save time, depending on how many textures you're missing... 1 hour ago, Natsuki Okusawa said: thank you very much for the help You did the work - I just gave some hints. Cheers. Link to comment Share on other sites More sharing options...
Natsuki Okusawa Posted May 12 Author Share Posted May 12 (edited) 1 hour ago, piken said: That would take much more time (staring in the hex editor wondering what the various fields of the header are, writing a script in Python/C/C#/010/imhex..., using libraries like Noesis or BMS...), but it could also save time, depending on how many textures you're missing... I can just get most of the textures through Ninja Ripper, though as I mentioned in the first post, some portions of certain textures would be missing. The textures extracted through Ninja Ripper would also have some opacity/transparency on them for some reason, though I can deal with it by just doing some editing in Photoshop, particularly duplicating their layers until the image is solid. Still, a tool/script would be very useful as it would save time as you said and make the whole process of extracting them easier. If I'm not mistaken, the character models in this game has around 15 or so textures. (There would be much more when including the other textures for blinking, mouths, eyebrows, etc...) 1 hour ago, piken said: You did the work - I just gave some hints. Cheers. But still, your hints were very helpful to me, I highly appreciate them and I gotta say I had some learning from them. Again, thank you very much. Edited May 12 by Natsuki Okusawa 1 Link to comment Share on other sites More sharing options...
Engineer roocker666 Posted May 16 Engineer Share Posted May 16 (edited) There are a lot of textures, I was analyzing untitled file and it seems like the first part has several images and their palettes are after those images, something like this: Image1 Image2 Image3 Image4 etc. Palette1 Palette2 Palette3 Palette4 etc. But after that there are more images and palettes but the order changes, like this: Image1 Palette1 Image2 Palette2 Image3 Palette3 Image4 Palette4 etc. Images have a header, I tried to find width and height there but I found just one. Those headers are weird, some images have 2 headers and 2nd header has image data size(first 4 bytes), for example size of 1st image is 6000 Hex; 80 x C0 = 6000(or 24,576 Dec; 128 x 192 = 24,576). Palettes have a header too(32 bytes) but it is easy to understand, first 4 bytes tell you Palette size, it seems like size of all palettes is 400(Hex) so first 4 bytes of palette header are always 00 04 00 00 Palette data use RGBA for each pixel, so you will see something like this: "45 15 45 80 /11 23 54 80/21 54 47 80/32 52 47 80...", that means Red is first byte, Green 2nd byte, Blue 3rd byte and Alpha 4th byte. The problem with alpha byte is the transparency, if you extract any image of PS2 it will be semi transparent because that alpha byte(80). In both image and palette headers appear these bytes at the end: 00 00 00 99, so you can search for those bytes to find images and palettes. My conclusion: There is no way to write a script to extract textures, you need to extract each one manually because I don't know how to find width and height(I only found one) in image header, This is a mess, lol. Here are some images to understand better(I cut textures code and pasted that in a new file): Edited May 16 by roocker666 2 Link to comment Share on other sites More sharing options...
Natsuki Okusawa Posted May 16 Author Share Posted May 16 For the transparency in the textures, I can seem to get the proper transparency of the texture/image at 0x734d0 (an eyelid) with the following alpha settings in TiledGGD: 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now