XeNTaX

[out]

Some interesting progress is going on here.

I don't have this game/data, and looking at the samples provided on page 1 the rip is clearly fucked. Thoughts:

- No runtime is going to be intuiting image format/size from file size, find the proper place to get reliable header data (possibly another archive/binary entirely) before running around in circles.
- Don't use the raw untile function on DXT data. The routines for each are very different. (the Noesis implementation isn't based on any existing code in the wild)
- Some of the "garbled pixels" shots provided in this thread are telltale signs of trying to interpret tiled DXT1 as tiled DXT5.
- You aren't limited to DXT1-5, a number block compression formats are also possible which don't even fall under moden BC*, including a DXT1 normal map compression. (Noesis supports these as well)
- Tiling/twiddling/etc. is of course lossless. If you think about the reason to use any form of micro/macro tiling mode, and what Morton coordinates give you, you can see that it's all about maximizing efficiency of the texture cache. It's just the same data, but sampling patterns are usually going to dictate that caching that texture block that lays out linearly in memory is going to be of much greater benefit than caching the rest of a linear-ordered row of pixels occupying the same memory.
- You need to be obeying expectations for implicit alignment between rows (or rows of blocks in the case of DXT), mipmaps, and cube faces as applicable. For example, a 30x30 DXT1 texture will contain block data for a 32x32 texture, as a single DXT block represents 4x4 texels. There are also different alignment/padding requirements depending on the format/tiling for mipmaps and cubemaps. Tiling may also dictate row alignment/padding beyond DXT block-alignment. If variable modes are employed then the correct header data for each texture no doubt specifies this.

Ok, have fun.

gistech wrote:Some interesting progress is going on here.

Indeed!




*i removed the attached file and turned off logPopup, see the first post for this Noesis python plugin*


Thanks to chrrox for the base code from fmt_star_wars_kinect_tga.py.
This script is titled for SWBF3 but it is mostly universal for swizzled 360 textures.
You have to open the script and set the format type, width and height.
i have not tested on a lot of textures, its pretty much trial and error but it should get the job done.

AceWell wrote:

gistech wrote:Some interesting progress is going on here.

Indeed!

fmt_SWBF3_x2t.zip

Thanks to chrrox for the base code from fmt_star_wars_kinect_tga.py.
This script is titled for SWBF3 but it is mostly universal for swizzled 360 textures.
You have to open the script and set the length of data in bytes, format type, width and height.
i have not tested on a lot of textures, its pretty much trial and error but it should get the job done.

Alright so most of the characters are what 1024x1024? but what are the faces 512x512?

I don't know you'll have to play around with the settings.

I forgot to turn off the logPopup in the script, you comment line 7 out with this # so it won't appear.

maybe someday we can hook the script into a tool window.

[out]

[out]

Wobble wrote:Here is the fixed Noesis plugin.

x2t_image_noesis_final.zip

Thanks all!

So i'm finding a lot of textures that aren't working mainly if you go by name in Noesis and go down to 7efb9702.x2t that's where i started cause i was looking for the DC15 carbine first person texture and i found that.

From what i'm seeing all the texture that are after 6fd20406m.x2t to the end of 7ffad30at.x2t are broken and that's just what i've viewed so far, but some of them are so small it doesn't even matter but the ones that aren't are broken.

There are way more i'm seeing now.

[out]

Wobble wrote:

JakeGreen wrote: So i'm finding a lot of textures that aren't working mainly if you go by name in Noesis and go down to 7efb9702.x2t that's where i started cause i was looking for the DC15 carbine first person texture and i found that.

From what i'm seeing all the texture that are after 6fd20406m.x2t to the end of 7ffad30at.x2t are broken and that's just what i've viewed so far, but some of them are so small it doesn't even matter but the ones that aren't are broken.

There are way more i'm seeing now.

There are still textures with zero headers. Nothing is going to fix that.
If you need to see a particular texture, then you need to guess its header.

For example, if you want to see the storm trooper texture posted above, add this to the filename:

Code: Select all

7f40ed02.x2t  ->   7f40ed02 1024 1024 32 5.x2t

Always use spaces to separate parameters.

Alright, well i've noticed some of the vehicle textures you can view them but they look like this.

They mostly look like they are complete just wrong format.

[out]

Wobble wrote:

JakeGreen wrote: They mostly look like they are complete just wrong format.

You got it right, just the wrong size. When you see a texture with "bands" like that, it means you need to increase the texture size by a power of 2. If you picked 512x512, go up to 1024x1024.

Try:

Code: Select all

0350b882 2048 2048 32 5.x2t

Ah that works great i kept having problems with it even after i seen your updated post and i realized i had Acewell's plugin in there and once i removed it that did the trick.

[out]

Wobble wrote:If you want a texture loader that uses a "fixed" size, all the time, then using his Python script is a good idea.
You can scan for all 1024x1024 textures, and nothing else.

Well so far i've found textures that have been so messed up with pixels and used your method and it worked perfectly.