+- The VG Resource (https://www.vg-resource.com)
+-- Forum: Discussion Boards (https://www.vg-resource.com/forum-133.html)
+--- Forum: Help me! (https://www.vg-resource.com/forum-137.html)
+--- Thread: reverse engineering Sm4sh-related formats (/thread-27439.html)
reverse engineering Sm4sh-related formats - Tcll - 07-12-2015
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
RE: reverse engineering Sm4sh-related formats - Tcll - 07-13-2015
ok so the image data is in raw GX2-GTX format, with the formats being listed and worked on here:
https://copy.com/6SWdTBySUuGP8qjR
^credit to NWPlayer123 for sending me an unfinished WiiU SDK
still not quite sure what those 0x80-sized structures are yet
and RTB sent me the game-data files (all except the media), which I'm still downloading due to horrid internet, so I should have that missing primitive type figured out soon.
