(Apologies for slight thread necro)
WayForward tends to save texture offset and UV coordinates in 32-bit floating-point representation, so here's what I'm getting as values starting from 0x2C (After byte swapping from big endian):
Piece 1:
-22, 17, 0.0147059, 0.0208333, 26, 17, 0.720588, 0.0208333, 26, -27, 0.720588, 0.9375, -22, -27, 0.0147059, 0.9375
Piece 2:
-38, 14, 0.75, 0.0208333, -22, 14, 0.985294, 0.0208333, -22, -0, 0.985294, 0.3125, -38, -0, 0.75, 0.3125
Piece 3:
26, 14, 0.75, 0.354167, 32, 14, 0.838235, 0.354167, 32, -3, 0.838235, 0.708333, 26, -3, 0.75, 0.708333
The pieces are stored as:
Where:
Note that a lot of this info is redundant (Other titles I've worked with just stored top left and bottom right coordinates), hence the overlap you both noticed.
Negative values for the first fields are totally A-OK, as these are pixel coordinates are stored relative from the center of the final image. UV coordinates are in the range [0, 1] and are multiplied by the width and height of the input image to get input texture coordinates.
Whew. It took me a while to figure all this out, even though it was staring me in the face the whole time.
So just using our topLeft/Right and bottomLeft/Right info, our final image for the anvil will be in the form:
![[Image: boyblobanvilUV.png]](https://dl.dropboxusercontent.com/u/31816885/photos/boyblobanvilUV.png)
Where 50, 50 in this image is 0, 0 as far as texture coordinates are calculated. Looks correct! All that remains is to multiply out the UV coordinates and piece the image together.
The issue here is that each piece is larger than drawn here. The main anvil chunk in the image you provided is 50x46, rather than the 48x44 result we get here. From a game engine standpoint, drawing it slightly smaller is totally easy, but this degrades the quality a bit if you don't scale it all up a tad.
Another small caveat is the repeated pixels on each side of the image, which you can see from the anvil image you posted. This is pretty standard from WayForward games (as you can see from the titles I've ripped, I just left those there cause I didn't feel like cropping every. single. image. And my calculations were a bit too off to crop the images programmatically).
There's enough similarities here to other WayForward titles that I can reuse a lot of my old code and whip up a program to extract the images and piece them together without too much hassle. I just couldn't figure out the image format itself (I suck at image formats), so I need either that explained to me, or you can just use this info to piece it all together yourself.
Have fun!
Oh, and from what I can tell, the first part of the ANB is a header in the form:
Again, all in big endian.
WayForward tends to save texture offset and UV coordinates in 32-bit floating-point representation, so here's what I'm getting as values starting from 0x2C (After byte swapping from big endian):
Piece 1:
-22, 17, 0.0147059, 0.0208333, 26, 17, 0.720588, 0.0208333, 26, -27, 0.720588, 0.9375, -22, -27, 0.0147059, 0.9375
Piece 2:
-38, 14, 0.75, 0.0208333, -22, 14, 0.985294, 0.0208333, -22, -0, 0.985294, 0.3125, -38, -0, 0.75, 0.3125
Piece 3:
26, 14, 0.75, 0.354167, 32, 14, 0.838235, 0.354167, 32, -3, 0.838235, 0.708333, 26, -3, 0.75, 0.708333
The pieces are stored as:
Code:
typedef struct
{
Vec2 topLeft;
Vec2 topLeftUV;
Vec2 topRight;
Vec2 topRightUV;
Vec2 bottomRight;
Vec2 bottomRightUV;
Vec2 bottomLeft;
Vec2 bottomLeftUV;
} piece;
Where:
Code:
typedef struct
{
float32 x;
float32 y;
} Vec2;
Note that a lot of this info is redundant (Other titles I've worked with just stored top left and bottom right coordinates), hence the overlap you both noticed.
Negative values for the first fields are totally A-OK, as these are pixel coordinates are stored relative from the center of the final image. UV coordinates are in the range [0, 1] and are multiplied by the width and height of the input image to get input texture coordinates.
Whew. It took me a while to figure all this out, even though it was staring me in the face the whole time.
So just using our topLeft/Right and bottomLeft/Right info, our final image for the anvil will be in the form:
![[Image: boyblobanvilUV.png]](https://dl.dropboxusercontent.com/u/31816885/photos/boyblobanvilUV.png)
Where 50, 50 in this image is 0, 0 as far as texture coordinates are calculated. Looks correct! All that remains is to multiply out the UV coordinates and piece the image together.
The issue here is that each piece is larger than drawn here. The main anvil chunk in the image you provided is 50x46, rather than the 48x44 result we get here. From a game engine standpoint, drawing it slightly smaller is totally easy, but this degrades the quality a bit if you don't scale it all up a tad.
Another small caveat is the repeated pixels on each side of the image, which you can see from the anvil image you posted. This is pretty standard from WayForward games (as you can see from the titles I've ripped, I just left those there cause I didn't feel like cropping every. single. image. And my calculations were a bit too off to crop the images programmatically).
There's enough similarities here to other WayForward titles that I can reuse a lot of my old code and whip up a program to extract the images and piece them together without too much hassle. I just couldn't figure out the image format itself (I suck at image formats), so I need either that explained to me, or you can just use this info to piece it all together yourself.
Have fun!
Oh, and from what I can tell, the first part of the ANB is a header in the form:
Code:
typedef struct
{
uint32_t numImages;
uint32_t unknown1;
uint32_t pieceOffset;
uint32_t imageOffset;
uint16_t imageW;
uint16_t imageH;
uint8_t unknown0[8];
uint16_t numPieces;
} anbHeader;
Again, all in big endian.