Users browsing this thread: 1 Guest(s)
reverse engineering Sm4sh-related formats
#1
I've actually got 2 things I want to talk about regarding NUD and NUT files

for NUD, all I need is a little information about the PolySize in RTB's script or what I've called the FacepointAttributes in my script...
what is the promitive type when the PolySize/FacepointAttributes is 0??
Code:
# dummy-line (stupid l-strip)

                if case( 0x00 ): # Tri-Strips??
                    # not sure what to do here
                    print "You've found a model using the missing format"
                    '''
                    FaceCount = FacepointCount
                    FaceStart = ugeGetFileOffset()
                    VerStart = (FaceCount * 2) + FaceStart

                    StartDirection = 1
                    f1 = u16(big=big) + 1
                    f2 = u16(big=big) + 1  
                    FaceDirection = StartDirection
                    while ugeGetFileOffset() != VerStart:
                        f3 = u16(big=big)
                        if f3==0xFFFF:
                            f1 = u16(big=big) + 1
                            f2 = u16(big=big) + 1
                            FaceDirection = StartDirection
                        else:
                            f3 += 1
                            FaceDirection *= -1
                            if (f1!=f2)and(f2!=f3)and(f3!=f1): Face_array.append( [f3,f2,f1] if FaceDirection > 0 else [f2,f3,f1] )
                            f1 = f2
                            f2 = f3
                    '''

and for the NUT files...
the QuickBMS scripting language is giving me a headache trying to understand it due to poor documentation...
and the NUT script seems to just re-write data rather than actually convert it...

as far as the script itself goes, the variable names are very undescriptive and extremely generalized,
so it's a little hard to make out what does what other than just figuring out what value links to what...

so in the script:
OFFSET1 is by no doubt the pixel data offset
OFFSET2 is still unknown
OFFSET3 is not handled correctly, but the first image's OFFSET3 points to a structure at the end of the last pixel data of size 0x80

how the rest are handled in the script is done by adding 0x80 to the initial OFFSET3.

the problem I'm seeing here is, in the NUT I'm working with, the first 3 images have the same OFFSET3,
while the 4th image has a different OFFSET3 which is 0x20 greater than the first 3

the pattern seems to continue with a few having the same while the next is 0x20 higher.


so what I'd like to know is
does anyone have any info on these structures, and are they hierarchical structured??
(I say hierarchical due to the OFFSET3 being the same for some images)
^this clearly means there's more than what there should be

also, how is the pixel data handled??
from what I'm seeing, the data looks like it could be CMPR (S3TC), but for some images, the format doesn't match the data structure...
for example, the data looks like CMPR, but the format says 2 meaning (I think) I8, which is clearly wrong or the data size would be 8x smaller for the pixel size.

can anyone help me out here?? :/

anything will do
[Image: banner.PNG]
Reply
Thanked by:


Messages In This Thread
reverse engineering Sm4sh-related formats - by Tcll - 07-12-2015, 03:44 PM

Forum Jump: