Atlus's .PB (3D model format)

[Darkfox]

The new one is giving me trouble too. O_o

[prototypesky]

I was able to figure out parts of RMD data file based on the info given on .PB files

typedef struct {
UCHAR filetag[12];
USHORT rmdtype;
} rmd_header;

typedef struct {
UINT datatype;
USHORT datasize;
USHORT padding;
UINT seperator; // "55 0 2 28"
} data_header;

typedef struct {
UINT tex_width;
UINT tex_height;
UINT tex_bitdepth; //Not confirmed yet
UCHAR data0[52]; //No clue yet most likely additional image formating intel
} tex_header;


//Weapon Model File Read Example
//rmdheader
//dataheader ID 22 Size 9600 Data = Textures
//dataheader ID 1 Size 4 Data = "0 1 0 6" bytes
//dataheader ID 21 Size 9560 Data = Tx2 Header + Tx2 Data
//dataheader ID 1 Size 8 Data = "PS2 " Label
//dataheader ID 2 Size 8 Data = "bat01 " Label
//dataheader ID 2 Size 4 Data = " " Label
//dataheader ID 1 Size 9464 Data = Tx2 Data
//dataheader ID 1 Size 64 Data = Texture Info Data Width/Height/BitDepth/????
//dataheader ID 1 Size 9376 Data = Header/ImageData/Header/PaletteData
//dataheader ID 3 Size 16 Data = ?
//dataheader ID 272 Size 4 Data = 4032 ?
//dataheader ID 3 Size 0 Data = Nothing to Read

//dataheader ID 16 Size 3983 Data = 3D Data
//dataheader ID 1 Size 12 Data = "1 0 0 0 0 0 0 0 0 0 0 0" ?
//dataheader ID 14 Size 196 Data = ?
//dataheader ID 1 Size 116 Data = ? "Integers mixed with Floats" Matrix?
//dataheader ID 3 Size 0 Data = Nothing to Read
//dataheader ID 3 Size 44 Data = ?
//dataheader ID 286 Size 32 Data = ?
//dataheader ID 26 Size 3675 Data = ?
//dataheader ID 1 Size 4 Data = 1
//dataheader ID 15 Size 3647 Data = ?
//dataheader ID 1 Size 2856 Data = Texture Coord/Index/BoundingBox/Vertices/Normals
//dataheader ID 8 Size 226 Data = ?
//dataheader ID 1 Size 8 Data = ?
//dataheader ID 7 Size 194 Data = ?
//dataheader ID 1 Size 28 Data = ?
//dataheader ID 6 Size 80 Data = ?
//dataheader ID 1 Size 4 Data = ?
//dataheader ID 2 Size 8 Data = "bat01 " Label
//dataheader ID 2 Size 4 Data = " " Label
//dataheader ID 3 Size 16 Data = ?
//dataheader ID 272 Size 4 Data = 4032 ?
//dataheader ID 3 Size 50 Data = ?
//dataheader ID 287 Size 38 Data = " name 02 - Default" String
//dataheader ID 3 Size 529 Data
//dataheader ID 1294 Size 472 Data = ? "Integers"
//dataheader ID 287 Size 33 Data = "FVF.UserData " String
//dataheader ID 20 Size 40 Data = ?
//dataheader ID 1 Size 16 Data = ?
//dataheader ID 3 Size 0 Data = Nothing to Read
//dataheader ID 3 Size 0 Data = Nothing to Read
//dataheader ID 5 Size 64 Data = "Integers and Floats"
//dataheader ID 27 Size 88 Data = ?
//???????????

[prototypesky]

Well that was tricky I decoded about 70% of the format here is the result
of the RMD model posted earlier. So I guess the PB format evolved into the RMD format

[cippyboy]

Shit, I bookmarked the post, and I was continually checking the first page .

Anyways, sorry about the exe DarkFox, I have no idea why it's not working.
prototypesky good job man , can you post some updated data structs ?

I continued my work on the .PB reader but damn, I get these array flags which are pseudo-random and I thought there might be a pattern but It seems like I was wrong... Anyways, that RMD format seems much easier than the crappy .PB. By the way, do they store uncompressed images in the RMD or pallet based ones ? Because I don't know (as of yet) how to read that TMX format. Anyway, if it helps I will post some updated structure & reading code for the PB reader.

[prototypesky]

Well I am now able to view most RMD models now

I am now trying to see if reverse engineering the animations are possible

Here are some of the additional discoveries I've made

//data types 22 = GROUP OF TX2 DATA
// 21 = TX2 DATA
// 20 = ??? DATA
// 31 = ??? Count Value or Type
// 288 = ??? Count Value or Type
// 1 = SUB DATA
// 2 = STRING DATA
// 3 = SUB DATA
// 16 = Marks the Start of 3D Data first 4byte = Int holding the number of models 16 marks bone data 26 marks vertex data
// 26 = Marks the Start of 3D Data first 4byte = Int holding the number of meshes
// 14 = ??? //the 1 Sub Data that follows this seems to be a mix of Ints and Floats
//The first 4 bytes is the number of this data type and 286 Type that follow afterwards
//12 Float values followed by a Int Numbers increase but duplicate in some case then e.g 0 1 2 2 2 5
// 286 = ??? //Starts of with the Int value 256
//Then followed by an array of intergers seems to be in groups of three's but there are some inconsistancies
// 15 = MESH DATA
// 8 = GROUP OF MATERIAL DATA
// 7 = MATERIAL VALUES //Ambient Diffuse etc
// 6 = MATERIAL DATA
// 272 = ??? // seems to have "192 15 0 0" 4032 // Probably a divider/padding
// 287 = Seems to be a desc for the Material
// 1294 = ???// An array of INT or SHORT DATA
// 278 = ??? //
// 42 bytes of Header Info
// 6192 bytes of INT or SHORT DATA 1548 3096
// 24768 bytes of FLOATS 6192
// 44 byte of FLOATS 11
// Mix of Floats and ints with "17 1 0 0" and "120 37 1 38"

// 43 = ???//Animation Data Maybe
// 27 = ???//Animation Data Maybe
// 14 and 286 Might Also be related to some Animation System


There is an array Structure under data type 14 that looks the follow
//Unknown Data[1]
//... 1.000000, 0.000000, 0.000000
//... 0.000000, 1.000000, 0.000000
//... 0.000000, 0.000000, 1.000000
//... 0.000000, 0.000000, 0.000000
//... 0
//... 3
//Unknown Data[2]
//... 1.000000, 0.000000, 0.000000
//... 0.000000, 0.000000, 1.000000
//... 0.000000, -1.000000, 0.000000
//... 0.000000, 107.609398, -3.500397
//... 1
//... 3
//Unknown Data[3]
//... 1.000000, 0.000000, 0.000000
//... 0.000000, 0.000000, 1.000000
//... 0.000000, -1.000000, 0.000000
//... 0.000000, 0.000000, 0.000000
//... 1
//... 3
//Unknown Data[4]
//... 0.000001, 1.000000, 0.000000
//... 0.000000, 0.000000, -1.000000
//... -1.000000, 0.000001, 0.000000
//... 0.000002, -1.496140, -95.843407
//... 3
//... 3
//Unknown Data[5]
//... 0.000000, 1.000000, 0.000001
//... -0.000001, 0.000001, -1.000000
//... -1.000000, 0.000000, 0.000001
//... -2.355187, -6.839119, -0.000000
//... 4
//... 3
//Unknown Data[6]
//... -0.112441, 0.000000, -0.993658
//... 0.000000, 1.000000, 0.000000
//... 0.993658, 0.000000, -0.112441
//... 1.580411, 1.352005, -0.181326
//... 4
//... 3

[prototypesky]

Shit, I bookmarked the post, and I was continually checking the first page .

Anyways, sorry about the exe DarkFox, I have no idea why it's not working.
prototypesky good job man , can you post some updated data structs ?

I continued my work on the .PB reader but damn, I get these array flags which are pseudo-random and I thought there might be a pattern but It seems like I was wrong... Anyways, that RMD format seems much easier than the crappy .PB. By the way, do they store uncompressed images in the RMD or pallet based ones ? Because I don't know (as of yet) how to read that TMX format. Anyway, if it helps I will post some updated structure & reading code for the PB reader.

I am yet to run into compressed Textures.
There propably isn't any since 4.7GB is alot of space and the largest textures I've see is 256x256 32bit
The Textures in the RMD are swizzled and the pallet indexes have the 4 and 5 bits reversed for 8bit textures.
Just unswizzle and swap the 4 and 5 bits of the pallete index values and you should be able to view the textures no problem

[prototypesky]

I found the bone data for the model that links the bones to the vertices and the respective weight values and the bones local matrix and an array that somewhat defines the parent child relationship of the bones. It's all stored in Data Header Id 278.

Unfortunately I can't pin point anything that resembles actually animation key frame data in the file

[cippyboy]

Hey, just found out that if you have any problems with the exe, this might help. I made some more advancements but still couldn't get entire models out. I have an upside down, 70% mass free Raidou Kuzunoha by now; I'll make a pic when I get the time .

[prototypesky]

Ok I found the actual animation data from a RMD file
the structure of it so far is
the first 4 bytes is a float value
the next 4 bytes is the number of animation key frames

Each key frame is 22 bytes in size
The first four bytes of each key frame is a float value
where the values range from 0.0f to 2.0f
then it is followed by 14 bytes of data which I haven't been able to confirm what each byte represents but they affect the bone matrix orientation for that frame and the last 4 bytes seems to be either 2 shorts or an interger value.

I've noticed that the first n key frame data structures where n = the total number of bones defined in the model, the last 4 byte values are the same and the first 4 byte float values are = to 0.0f
Then the next n value the first 4 byte float values now range from 0.0f to 2.0f and the 4 byte integer at the end of the 22 byte data structure value increments in multiples of 24 e.g (0, 24, 48, 72, 96 etc up until n*24 value after which the numbers don't don't ascend always the amount 24 but a multiple of 24 sometimes. I am guessing the last four bytes determines which bone matrix is altered and when on the animation time line they are altered.

Also after all the key frame data structures there are 6 float values.

Anyone wishes to try and make sense of this format?

[Darkfox]

Strangely the problem has become centralized with SHLWAPI.DLL and IEFRAME.DLL. The other problems however are gone.

[cippyboy]

Strangely the problem has become centralized with SHLWAPI.DLL and IEFRAME.DLL. The other problems however are gone.

If you got the VC9 redistributables and you still have problems it's kind of odd, did you try getting those DLLs off the internet ?

[Darkfox]

Yes. Hm... some say this is normal with Vista, they say it should work anyways... huh...

[Darkfox]

The contents of this post was deleted because of possible forum rules violation.

[cippyboy]

3 years after I started this I came back to it in an attempt to finish it . The format proves to be quite tricky, probably the trickiest thing I've seen so far. Anyway, I'm working on it and will post some final code & the application soon.

[Darkfox]

I-is that a Devil Summoner model I see!? IT IS! General Munakata, oh wow!

A lot is missing of him but this is simply amazing! And glad to have you back!