.nut issues

[Brian151]

After giving-up trying to figure-out the .nut format, or finding someone who can, found your little tool. Seems to work for the most part.

However, it fails to export every texture if even one have a dimension set to 0.

in star fox assault, tex_pack_24.nut - tex_pack_29.nut cannot be properly exported. I'll probably have to do it manually using the preview, and hope i don't mess something up.

I'm not sure if this next two are bugs or not, but might want to check it out: Sometimes, the textures are fully translucent. One of two things: the data isn't being read right, or these are overlays/bump-maps or something. I'm pretty sure they're probably correct, but doesn't hurt to test that out.

Sometimes, large sections of the textures look like something is missing, or a color or two just didn't get read right. Generally speaking, this occurs on Aparoid-related textures, so I'm guessing it's probably correct. (as there are plenty of cracks and holes in the textures, but some do look...odd)

If need be, I can provide some samples...

[marco-calautti]

Hi Brian,

Thanks for pointing out these issues, I'm not on my workstation right now. I'll check them out tomorrow as soon as possible.

Marco

[Brian151]

ok, thanks

and eh...I'm in no rush. The model archives remain uncracked, too. Assuming I knew what I was doing, there...the .pac format is cracked, but not the individual meshes...XD (and I can't, either...beyond my skill level)

anyways, thanks for the swift reply. (file/data converters are fun, huh?)

[marco-calautti]

Hi Brian. The crash on exporting zero-sized images from nut files should be fixed now. Could you please download the latest build on the repository home page and test it out?

Regarding the other two "bugs", it would be very helpful to know the file names of such nut files.

(yes, I really like reverse engineering this stuff! I learnt a lot on image formats/encoding :P).

[Brian151]

I'm a bit busy atm, so I can't really test stuff right now.

the Aparoids run from 51 - 58, it looks like [attached] are the exports of tex_pack_51 + ref. images of the first aparoid encountered

[removed to avoid copyright, also no longer needed]

The textures pertaining to the aparoid (not Oikanny's ship...) appear to possibly be colored improperly partially, and almost like parts of the data just wasn't read at all. Without the models, I have no way of knowing what's going on, exactly. I wouldn't be surprised if some kind of shading or colorization is applied during run-time or by the model. Anyways, if you could do what you can to verify there's not something odd happening there. I'd show that other issue, but I don't have time to show an example just yet... sorry. I can't do it right now, I could ATTEMPT using a 3d ripper to grab the model, but they have a rep for not working right and just breaking stuff, hence why i'd rather see the actual mesh assets cracked at some point.

anyways, I've already taken more time than I should've...

I'll check out the new version and show you the other areas of concern when I'm back.

edit 0.5: i'll also strip oikanny's ship textures from this post when returned...

edit 1: removed unrelated stuff

[marco-calautti]

Although I agree that colors seem to be different from the original in-game texture, I cannot see where data are missing from the extracted pngs. It seems to me that the textures you posted are completely extracted.

[Brian151]

yeah, and it is odd just a few wouldn't export correctly... which means there's colorization and other exciting stuff applied either in-game (i sure hope not), or by the actual model files. 3d games aren't exactly known for using full-color textures all the time, and often also use fancy shaders or other effects to product animations that'd be far too large or complex to store in the texture files, themselves.

IDK if you have paint dot net, but... http://crystalien-redux.com/unrelated/ETX/VG-Resource-Stuff/misc_files/PuzzleBlock.pdn

the texture was ripped via the built-in texture dumping feature for project 64. (that worked, apparently...or i installed a video plugin properly without knowing)

the other issue is basically transparent textures like that. going from memory, they run 31-40 or something. i'm guessing they are overlays or similar. easy to miss, but it'll be what looks like an otherwise normal texture, but fully translucent, and void of any noticeable color.

I forgot to check the updated download cuz i got sidetracked, so i'll do that, now. edit: did that, it works, thx.

[marco-calautti]

All the images you see have strange colors, are encoded in CMPR format,which is a Nintendo custom version of DXT1, where blocks of pixels are arranged in 8x8 tiles. I have mainly found two distinct ways of decoding such images, when I researched this stuff.

One is the implementation found in Dolphn emulator's source code: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/TextureDecoder_Generic.cpp#L155

The other one, found almost anywhere else, is the one implemented in wiim image tools: http://opensvn.wiimm.de/viewvc/wii/trunk/wiimms-szs-tools/src/lib-image1.c?view=markup#l2179

The last implementation is the most frequently found in DXT1 decoders on PCs, and actually is the most accurate implementation I could find that is able to decompress nut images using CMPR. So, I am pretty sure that the difference in colors you are noticing is not due to my implementation, but just a mix of semi-transparent pixels and run-time processing by the game.

Regarding the other issue, I tried exporting nuts from 31 to 40, but I don't see the problem occurring, maybe we are talking about different nuts?

Marco

[marco-calautti]

P.S. What's probably wrong, is the color conversion from 5 bits to 8. I can try using the lookup table used in wiimm image tools and see if results get better.

[Brian151]

a few of them are translucent, like this guessing either overlays or something of the nature, but...just checking as i said, that .pdn file, it has three layers. one is the semi-transparent texture ripped from project64.one is...iirc, a solid black fill set to reflect blending mode. the final is a solid fill of some brown color set to multiply. (i guesstimated the color by looking at a screenshot)

i thought .nut was a specific format namco had created, though? i wouldn't think they'd have been such a pain to crack if they contained one of the relatively well-known formats, already. Far as I know, you have the only tool that actually opens them. And even so, it doesn't exactly have any sites stating this. (the only fileinfo site that even recognizes .nut as a format in starfox assault simply lists said game as the program that opens it... SO not helpful)

so what is left to figure-out on the .nut files? i noticed the XMLs exported contained some other data, which a friend of mine actually took the effort to decode for whatever reason.

//end that bit

and ok... interesting, these comments refresh live

ok, you may try that i'm gonna take a shower, and then maybe head to bed

another couple of suggestions: a simple 'export .png' option instead of that 'gamecube nut archive + edtiable meta-data' thing export .png for whatever the currently selected texture is seeing as it's a batch-export kinda deal, FOLDERS, please. (i was quite annoyed at how the starfox adventures ripper worked, in those regards...but it also generated many more files)

and one last thingy:

is it at all possible an alpha channel or something is getting missed? or do they apply some MAGIC at run-time, there? (already safe to assume colorization goes on at run-time) I'm guessing those are particle effects or something, right?

anyways, i'm gonna go take that shower. I may just end-up staying-up again, cuz i'm at a critical point of having skipped bed that crashing now may cause me to be late for things... /:

[marco-calautti]

Actually, the format seems to be developed by namco. Moreover, .nut containers are exactly yhe same ad TIM2 container, but with different encodings for textures. That's way was easy to cracked the container format. Whereas textures encodings are well documented because somehow standard for the GameCube/Wii.

Regarding reversing, nothing is left to do, but I need to implement the last texture codec: c14x2. Apart from that, I remember the whole format is reversed.

Anyway I will check the missing transparency for that images.

Marco

[Brian151]

any luck with that? not to be impatient, but it has been a while since you last replied

[marco-calautti]

Sorry for the delay, but I am on vacation now and will come back mid september. I hope I can give it a shot during that time.

Marco

[Brian151]

It has been a while Still plan to return to this sometime? Seems this whole project has been completely inactive

[marco-calautti]

I started working a bit on Rainbow recently. I will try to fix the issue we discussed.

[marco-calautti]

@Brian151 Hi Brian, I tried changing the color conversion approach, using the conversion tables from wiim-szs-tools, and the results are pretty much the same. I now don't remember what was left to check and what where the problems you where facing. Could you please recall me?

[Brian151]

my last problem, which IDK if was confirmed was this: https://github.com/marco-calautti/Rainbow/issues/4#issuecomment-236129446

One thing I will say is your code doesn't give the greatest idea HOW the formats work, and those docus you linked honestly, aren't easily understood, either...

But, that's totally not related to this in any way. Just something you might consider.

[marco-calautti]

The translucent images you are talking about, are indeed translucent. There is nothing wrong with them. Regarding the missing transparency images, these are images with format (in .NUT encoding) 0xA, which from my research semees to correspond to greyscale without alpha. Whereas format 0xB is greyscale with transparency. However I am not 100% sure this is correct. I need more samples to double check this.

I agree the code does not explictly describes the format. Since Rainbow is meant as a general framework for decoding many different formats, a more abstract code base was needed.

[marco-calautti]

-EDIT- I double checked, and I am pretty sure also che the greyscale images are correct. Because the way the two greyscale encoding work, if rainbow was using the wrong one, the decoded image would just look broken.

Finally, since Rainbow went through a significant architectural change, I would be grateful if you could test the new dev build on as much NUT files you could. The new build should also fix a bug in decoding some images with odd width/height.

[Brian151]

whenever i can next do that... not much disk space, atm, and i barely can use firefox... only game i personally know of is starfox assault right now, i can't possibly grab those files... but sure, when i can get to that

yeah, generic frameworks can have that issue Check out the beast I'm messing with! However, knowing both that code doesn't always explain the format, and needing specs to write that code for, my project has an entire section just for documentation. Written in a C-Like format, and stripped of as much, well ...BS... as possible https://github.com/Brian151/OpenShockwave

[marco-calautti]

Yeah, I know I should have documented the formats, but I barely have time to work on Rainbow's code, and I usually update it when I really need to support a particular format. I will try writing down a wiki at some point with all the formats specs.

[Brian151]

alright

[marco-calautti]

I will close the issue for now, since it seems that Rainbow correctly deals with NUT textures, ok?

[Brian151]

sounds good to me, also... seems you forgot to close it

[GoldYoshi]

Hi there,

First of all, sorry for adding to a previously closed thread. You might understand why I'm doing this a bit later on.

Secondly, thank you so much for providing this awesome tool! It's so sweet to see the textures within the files themselves, rather than using a ripper than only shows what's on-screen.

But I'm noticing that files 57, 59-61 and 67-78 won't open... Is it possible for you to shed any light on why this is? The app gives their size as 32 bytes, so is it because they aren't big enough?

Thanks in advance!

[marco-calautti]

32 bytes NUT files are just dummy textures. They do not contain any image data.