[PS2] Gundam G-Saviour model file help

[ScornMandark]

Well now.

 

Apparently when Noesis converted the njcm, it also captured the UV mapping somehow.  I do not question this magic, I just accept that I don't know how it happened 😛 

[The_oldman]

6 hours ago, ScornMandark said:

Well now.

 

Apparently when Noesis converted the njcm, it also captured the UV mapping somehow.  I do not question this magic, I just accept that I don't know how it happened 😛 

Could you tell me how you achieve this in detail?

[ScornMandark]

Sure thing - 

1) Extract ISO of disk with 7-Zip or Winrar

2) in the Data folder, find the suit you're after.

• GSS_HI is the high res G-Saviour Space Mode
• Others are generally straightforward to figure out - GS for G Saviour, GSG for G Saviour Ground, JS for J Saviour, BG for Bugu, etc.

3) identify the biggest matched set of file names - GSS_HI.MD is the model, GSS_HI.GSP is the multiple-texture file.

4) For the model, open it in a hex editor and check the length of the file in bytes by finding the address of the byte after the last one

• for GSS_HI.MD, it was 0x0FA49C

5) inject 8 bytes into the header, keeping in mind the little endian-ness

• first 4 bytes are 4E 4A 43 4D (NJCM)
• second 4 bytes are the little endian version of the length.  For GSS_HI.MD, those would be 9C A4 0F 00

6) Save as <Filename>.nj

7) Open Noesis, open .nj, save as .fbx.  Model is done!

8 ) Either use ninjaripper to extract the scene textures, or go into the GSS_HI.GSP file with something like PixelDbg.

9) with PixelDbg, search for the GS text preceded by FF FF FF FF - that's the beginning of each new texture.

10) if the next 2 bytes are 13 00, then it's an 8.8.8.8 BGRA pixel setup.  the next 2 shorts are the length and width.  Should be square, but 03 00 03 00 means 48x48, etc.

11) the next full line (assuming 16 byte lines) starts the pallette.

12) 1024 bytes later starts the image.

13) export, and move to the next.  (this method has the advantage of keeping track of where in the file the image was, and noesis outputs the UV textures as njtex00, njtex01, etc, and they are in the same order as the textures).

14) open the fbx in blender, apply images as diffuse maps, reduce metallic and specular by half.

15) apply eye texture as emission map, put in a camera and a few lights, and render away!

16) the 14 00 texture indicator I think is a 2.2.2.2 BRGA, but it might also be a 8.0.0.0 grayscale, I'm not sure yet.

17) the other model files have dozens of textures, and it takes a long time to apply them all 😛 

 

 

Note: as I develop and improve the methods of ripping, I'll update this post!

Edited Thursday at 11:40 PM by ScornMandark

[ScornMandark]

Ok, so I'm probably just exhausted, but I'm having trouble wrapping my head around writing a noesis plugin.  I just want it to output a series of PNG files named njtex0xx, based on order in the <FileName>.GSP file, or just njtex000 if it's a standalone <FileName>.GS file.  Each .GS file, whether embedded in the GSP file or standalone, has the same format:

2 byte header: 0x 47 53 ( G S )

2 byte type int: 0x 13 00 (imgType=b8g8r8a8, textByteSize=4, palletSize=0x10 - 0x400 bytes of pallette, 4 bytes per pixel, 0x100 pixels in pallette.  0x10 x 0x10 size)

                           0x 14 00 (imgType=8.0.0.0 grayscale?, texByteSize=1, palletSize=8 - 0x40 bytes of pallette, 1 byte per pixel, 0x40 pixels in pallette. 0x08 x 0x08 size)

(Might be others, but these are the primary two.)

1 byte int pixel width

1 byte int pixel height

(not always square, but typically. Not always power of 2 either - 8, 16, 24, 32, 48, 64, 128, 256, 480, 512 all seen for both values)

4 bytes padding: 0x 00 00 00 00 (I've seen an occasional 0x 01 00 00 00, but I dunno what it means)

palletSize*texByteSize x palletSize*texByteSize pallet

width*texByteSize x height*texByteSize image, imgType pixel data

That's it. GS standalone files end after the pixel data.

GSP files have no magic number header, just a 2 byte int for number of textures.  Followed by 4 byte ints for each texture length in bytes.  Then pad with 0x FF FF FF FF until the next 0xXXX0 address.  If the GSP header ends on a 0xXXX0 address, pad a full 16 bytes until the next 0xXXX0 address.

Right after the padding, always on a 0xXXX0 address, a standard GS file begins.  At the end of the GS file, pad until the next 0xXXX0 address.  Again, if the file ends on an aligned address, pad out until the next one.

Ideally they'd all get put into a folder called <FileName> in the same folder as the <FileName>.GS or .GSP file - that way it could batch process without overwriting other files.

Edited Saturday at 03:48 PM by ScornMandark
Adding in organizational requirements; corrected palette size math

[ScornMandark]

Maybe a two step process - batch convert all <FileName>.GSP into njtex0xx.gs files in a <FileName> subfolder.  Then, batch convert each .GS file into a .PNG file in place.  I think that makes it a much more manageable process.

[The_oldman]

sorry guys, I'd been too busy in real life and didn't come back here.

for GS texture, 0x14 is 8bits indices + 256 color palette, 0x13 is 4bits indices + 16 color palette and 0x02 is 16bits pixel without palette.

also after W and H, there is a short value for no. mipmaps.

I made two quickbms script to convert md to nj and gs/gsp to tm2  directly. hope it help! :)

G_Scripts.rar

Edited Sunday at 08:18 PM by The_oldman

[ScornMandark]

8 hours ago, The_oldman said:

sorry guys, I'd been too busy in real life and didn't come back here.

for GS texture, 0x14 is 8bits indices + 256 color palette, 0x13 is 4bits indices + 16 color palette and 0x02 is 16bits pixel without palette.

also after W and H, there is a short value for no. mipmaps.

I made two quickbms script to convert md to nj and gs/gsp to tm2  directly. hope it help! 🙂

G_Scripts.rar 1011 B · 2 downloads

Oh snap!! That's awesome, man! Thanks so much!  Tomorrow I'm gonna blast this at the archive and see what survives hahahahaha

[ScornMandark]

19 hours ago, The_oldman said:

sorry guys, I'd been too busy in real life and didn't come back here.

for GS texture, 0x14 is 8bits indices + 256 color palette, 0x13 is 4bits indices + 16 color palette and 0x02 is 16bits pixel without palette.

also after W and H, there is a short value for no. mipmaps.

I made two quickbms script to convert md to nj and gs/gsp to tm2  directly. hope it help! 🙂

G_Scripts.rar 1011 B · 3 downloads

OK, .md to .nj worked a treat!  so far so good, that is frikkin awesome.  Having an odd issue with the GSP2TM2 - when I'm using pixelDbg's native bmp export, the output is a lot smoother than with the tm2 output:

Is that just the TM2 format compressing it?  If we could output to .png or .tga natively, that would be a great step.  Or maybe it's just the BMP ignoring the alpha channel?

I also didn't break it too badly updating the output naming convention, which I was quite pleased with lol:

set NINJA "njtex"
string RNAME p "%s/%s%03d.tm2" NAMEBASE NINJA i

This will output the textures into a named subfolder with the naming convention that Noesis generates for the textures, making texture assigning much faster for both noesis and blender.

This is texture 2 (njtex001) from the attached JS01M01.GSP

  

 

GSP2TIM_mod.zip

JS01M01.zip

Edited Monday at 03:40 PM by ScornMandark

[ScornMandark]

The BMS script matches well to Console Texture Explorer, but PixelDbg still has a smoother output.  The output from the pixelDbg is a 24-bit RGB (no alpha) bitmap, using the BITMAPINFOHEADER (40 bits), no compression, 24-bit rgb, no palette.  

 

 BT01M01.GSP_64x64_4816.bmp.zip

 

Iiiiinterestingly, if I select the PSP console in the console texture explorer, it comes up with a properly smoothed out version:

 

so how does psp look at it different than ps2?

Edited Monday at 09:09 PM by ScornMandark

[ScornMandark]

It looks like it basically all comes down to the palette - I don't really know what the difference is, but both the .bmp and .tm2 outputs for the psp and ps2 versions have identical indexing, just different palette sections.  (bmp palette starts up at 0x56 for both files, and the tm2 palette starts at 0x1040 for both.)  (The output tm2 files for both CTE and the scriptare nearly identical).  Many of the palette entries are the same, but they're not all in the same order.

Being an engineer, you know a spreadsheet had to enter the chat.  I grouped the hex values by 4 byte chunks, imported them into excel, then used a formula to match PSP palette index locations to PS2 palette index locations.  Every 8 palette entries looks like a block, and for the PSP (and the GSP files), the first block is regular, then the 2 sets of palette index blocks are swapped relative to the PS2, then the next 2 are regular, then swapped, etc.  Does this make any sense?  it doesn't really to me, as in why they would run it like that, but the results are real.

The GSP file texture block matches the PS2 texture block, but for whatever reason the PSP interpretation (and the PixelDbg interpretation) swap the second and third out of 4 blocks in the palette.

 

 

CTE.zip

Edited 4 hours ago by ScornMandark
missed the first block of the palette, updated