Users browsing this thread: 1 Guest(s)
Switch BNTX research
#10
(07-26-2017, 12:15 PM)KillzXGaming Wrote: Ah yes true. Does appear to be identical to original if i copy to the other channels.

Also another note, BC5 textures in this case used as normal maps seem to look quite strange.
http://i.imgur.com/j9DzRIV.png

Original
http://i.imgur.com/RVVIw0T.png

Well, normals are unit vectors, so on BC5 the Z component is not stored on the texture, only X and Y. Then Z is calculated based on X and Y (since X² + Y² + Z² are always 1 on unit vectors, Z can be computed as sqrt(1 - (X² + Y²)). Those blocks does seems weird through, its probably because the sign [-1, 1] is not being interpreted correctly. The way fragment shader expects is usually 0 being -1, and 255 being 1, but on a signed byte it's mapped as 128 = -1, 0 = 0 and 127 = 1. Not sure if this is the problem through.

Anyway I didn't looked into this yet, My focus currently is getting the swizzle correct for all textures, and then I'll start working on each pixel format. But thanks for pointing out this issue, I'll try to fix it as soon as I have the swizzle fully working.

(07-26-2017, 11:39 AM)Random Talking Bush Wrote: The way I've got it for my QuickBMS script right now is incredibly hacky and frankly I'm not even sure how it's working, so I can't say for sure. Unsure

This seems to be quite a interesting piece of code. I kind of isolated the problem I have with the swizzle currently, and also managed to understand a little better how it is supposed to work.

The easiest way I found to understand the ordering was this:

We first we have a 2x2 block. I will call it the "small block". Each small block contains 4 (2x2) tiles, and is ordered like this:

Code:
+--+--+
|0 |2 |
+--+--+
|1 |3 |
+--+--+

Then, we have a 2x4 block. Let's call it the "medium block". Each medium block contains 8 (2x4) small blocks, and is ordered like this:

Code:
+----+----+
|0   |4   |
|    |    |
+----+----+
|1   |5   |
|    |    |
+----+----+
|2   |6   |
|    |    |
+----+----+
|3   |7   |
|    |    |
+----+----+

And then we have a 2x16 block, a "large block". Each large block contains 32 (2x16) medium blocks. The ordering follows the same pattern of the previous blocks, and this is the biggest swizzled block that a texture can contain (at least on the files I observed). When the image is smaller than the block size (for example, images with less than 128 pixels of height (or 512 for 4x4 tiles compressed textures), then the block is ignored, and swizzle is performed just on the block sizes that does "fit" inside the texture.

So, basically my current problem is - what happens when the image size is not a multiple of those block sizes? Or when they don't have a power of 2 size?

The following textures can be decoded fine:
- Size is power of 2
- Width and height are greater than 128 (or 512 for compressed textures)

All other cases may or may not work properly.

I also generated mapping for some of the texture sizes for analysis.

Both are extracted correctly with those patterns, but they were generated using different code, and they are also different. So I basically, don't know why this difference exists, and I'm currently trying to make some sense out of it. I spent some time yesterday trying different solutions, but none of them worked for all samples.

Also, another thing to take into account:  Unused values = space waste. Basically, for a 64x66 textures, this would mean 64x62 pixels worth of wasted space on the file, however this is not what it does, it never wastes so much space. I would expect it to round the texture down to 64x32 then address the top bits linearly, but that doesn't seems to be the case either - rounding it down fixes some textures but break others.
Reply
Thanked by: Random Talking Bush


Messages In This Thread
Switch BNTX research - by gdkchan - 07-21-2017, 09:59 PM
RE: Switch BNTX research - by Random Talking Bush - 07-22-2017, 09:41 AM
RE: Switch BNTX research - by gdkchan - 07-22-2017, 08:28 PM
RE: Switch BNTX research - by Random Talking Bush - 07-23-2017, 09:06 AM
RE: Switch BNTX research - by gdkchan - 07-23-2017, 11:57 PM
RE: Switch BNTX research - by aboood40091 - 08-18-2017, 12:23 PM
RE: Switch BNTX research - by gdkchan - 08-19-2017, 02:09 PM
RE: Switch BNTX research - by aboood40091 - 09-21-2017, 09:03 PM
RE: Switch BNTX research - by gdkchan - 07-24-2017, 10:22 PM
RE: Switch BNTX research - by KillzXGaming - 07-26-2017, 11:15 AM
RE: Switch BNTX research - by Random Talking Bush - 07-26-2017, 11:39 AM
RE: Switch BNTX research - by KillzXGaming - 07-26-2017, 12:15 PM
RE: Switch BNTX research - by gdkchan - 07-26-2017, 01:10 PM
RE: Switch BNTX research - by gdkchan - 07-27-2017, 10:50 AM
RE: Switch BNTX research - by aboood40091 - 07-26-2017, 03:23 PM
RE: Switch BNTX research - by gdkchan - 07-26-2017, 10:37 PM
RE: Switch BNTX research - by Random Talking Bush - 08-05-2017, 01:48 AM
RE: Switch BNTX research - by gdkchan - 08-05-2017, 08:20 AM
RE: Switch BNTX research - by Rich - 09-19-2017, 09:33 AM

Forum Jump: