XeNTaX

Posted: **Thu Feb 04, 2016 11:52 am**

lolbas wrote:Here they are. The header field points to the start of selection. The first bytes after selection have been recognized by you as start of FVF data.

Thx. Sadly I don't know their meaning.

btw: you used the unzipped data which is the correct way, I guess
My previous infos refer all to the zipped bdae, so does the H2O file.

But I dont understand how could you say for sure that this value at this offset means amount of vertices! And also, why exactly this offset?

I can't say it for sure. But 0xC5 (C5 000000) and 0x150 (50010000) appear only once in that bdae so there was a really good chance that they were the counts.
This has to be proven by another (static) model sample, of course.

For the char model elf_m_h.bdae there's no occurence of A701000 (FI count: 423 dec.) so forget about what I said.

Once in 10 years maybe you'll realize, too that this analyzing stuff is a big waste of life and time, I guess.
That's the reason why I created hex2obj which allows to get the first submesh within 15 min in most cases
(with some experience).

Posted: **Thu Feb 04, 2016 2:09 pm**

shakotay2 wrote: For the elf (elf_m_h.bdae) use a FVFsize of 60.
H2O file:
0x2E02C 423
Vb1
60 24
0x2C8BA 100
020000
0x0 255

Do you mind posting h2o file for staff_05? The elf one only shows panties

Posted: **Thu Feb 04, 2016 2:50 pm**

0x21AA 336
Vb1
32 20
0x906 197
020000
0x0 255

to be used with the (compressed) staff bdae.

(Don't ask me for this weird plane attaced!

)

Posted: **Thu Feb 04, 2016 4:32 pm**

shakotay2 wrote:0x21AA 336
Vb1
32 20
0x906 197
020000
0x0 255

I dont understand few things. In the compressed file, 197 FVFs end at 0x21A6, but you say that face indices start at 0x21AA. That's 4 byte wiped out. Why? You also ignore the very last two bytes yet they are 0x00. There is no reason to put them by model specification, can't they be another face that will solve the plane issue? And yes, I understand that that is only 2 out of 3 required values to make up a face

shakotay2 wrote:(Don't ask me for this weird plane attaced! )

My understanding is that it's just non-optimized width of model, probably some wrong faces...

Posted: **Thu Feb 04, 2016 5:09 pm**

lolbas wrote:That's 4 byte wiped out. Why?

These 01 00 00 00 might be some kind of marker.
It's experience that tells me the face indices must start at 0x21AA (00 00 01 00 02 00).

You also ignore the very last two bytes yet they are 0x00.

yes, I always reduce it to the min.

There is no reason to put them by model specification, can't they be another face that will solve the plane issue?

Do you have a full format specification for this bdae file?
I don't have. I just give people a start and don't bother with details.
This may lead to severe misses, of course. I'm aware of that.
(But it's just a relaxing hobby of mine - I don't need to earn my money with it, luckily.

)

Nope, I don't think these two zero bytes will solve the plane issue.
I've divided the mesh up into 5 submeshes by inserting group separators (g submesh_x) all 50 face lines
to see whether the sms might be part of a collision mesh or something like that:

staff_5_submeshes.JPG

But normally the CS (collision shape) is in a separate file.

Posted: **Thu Feb 04, 2016 11:39 pm**

shakotay2 wrote:This bdae is a zipped file without compression (at least the contained model doesn't seem to be compressed).

Yeah its not compressed but with 7-zip you can extract it down one time to where the header begins with bres and looks very much like the one described here
http://wiki.tockdom.com/wiki/BRRES_(File_Format)

edit
fixed the link

Posted: **Fri Feb 05, 2016 12:33 am**

Thx - I changed the signature to lowercase but BRRES Viewer v1.3.1, 3 Jan 2011
By Kentilan doesn't recognize it (maybe a matter of endianess?).

There's a brres-splitter, but it doesn't produce an output because a signature like 'MDL0' is missing in the staff05.brres.
Even worse, there's no strings at file's end.

Posted: **Fri Feb 05, 2016 2:18 pm**

AceWell wrote:Yeah its not compressed but with 7-zip you can extract it down one time to where the header begins with bres and looks very much like the one described here
http://wiki.tockdom.com/wiki/BRRES_(File_Format)

shakotay2 wrote:...BRRES Viewer v1.3.1, 3 Jan 2011 By Kentilan doesn't recognize it (maybe a matter of endianess?).

I assume the BRRES file format has been taken as starting point. Specification described in link and the one I've been able to partly hack within last 3 days differes a lot, starting right after BOM Padding.

Here is my table. Comparing to the one from link will reveal the difference:

Code: Select all

    'str_signature'     => '',      # 0x0000    # String 'BRES' in ASCII. Signature #
    'bom'               => '',      # 0x0004    # Byte Order Mark. 0xFE 0xFF for Big Endian #
    'bom_padding'       => 0,       # 0x0006    # BOM padding. 0x0000 #
    'header_size'       => 0,       # 0x0008    # ? 0x50 - might be a header size
    'BDAE_size'         => 0,       # 0x000C    # size of model data
    'data_1_count'      => 0,       # 0x0010    # amount of 8 byte values from offset available at 0x18
    'data_1_offset'     => 0,       # 0x0018    # ? 0x50 - might be a pointer to other kind of data
    'string_start'      => 0,       # 0x0020    # offset to strings (string map: 4 bytes for string length; unknown logic for taking additional zero-value bytes (mod 4), seem to have at least 1 zero-value byte
    'string_end'        => 0,       # 0x0028    # 'string_section' end, start of 'unknown_section_1'
    'unknown_section_2' => 0,       # 0x0030    # 'unknown_section_1' end, start of 'unknown_section_2'
    'unknown_section_3' => 0,       # 0x0038    # 'unknown_section_2' end, start of 'unknown_section_3'; most likely section of model vertices, faces and uvs; with extra 5x 8 bytes values
    'unknown_data_1'    => 0,       # 0x0040    # might be an offset to 'section 4', but doesn't really seem to be so; might be an amount of vertices or polynoms
    'unknown_value_1'   => 0,       # 0x0044    # might be amount of FVF + face indeces blocks (2 for single-object model)
    'unknown_value_2'   => 0,       # 0x0048    # ? 0x0 - check other models
    'unknown_value_3'   => 0,       # 0x004C    # ? 0x0 - check other models
    # possible header end #

Posted: **Sat Mar 05, 2016 8:27 pm**

Yay! I've been able to convert .bdae models' objects to one I need to use and it all looks cool with all that shapes and textures but... I failed with normals. The models in game look all that smooth but the one I get are pretty rough. Due to some factors, I assume that every vertex has its normal, but how does this normal builds? I mean, what values does it use?

shakotay2 wrote: there are three floats (pos x,y,z) for the vertices and two floats for the uv coords (tx, ty), marked blue. (Maybe the remaining 12 bytes build a normal, didn't check it.)

According to what I've done, a vertex block (size = 32b) consists of:

Code: Select all

+--------+----------+
| offset |  content |
+--------+----------+
|   0x00 | vertex x |
+--------+----------+
|   0x04 | vertex y |
+--------+----------+
|   0x08 | vertex z |
+--------+----------+
|   0x0C |  no idea |
+--------+----------+
|   0x10 |  no idea |
+--------+----------+
|   0x14 |  no idea |
+--------+----------+
|   0x18 |     uv x |
+--------+----------+
|   0x1C |     uv y |
+--------+----------+
...

Do those 3x "no idea" build a vertex normal (I am not sure, because these values can be negative)? If so, what do they mean?

By the way, some models have vertex block size = 56 bytes, thats 6 extra values, what can they be?

Posted: **Tue Jun 07, 2016 9:11 am**

Hello,
sorry for poking in this old-ish thread, but I currently want to get textures/models/etc out of the game of files of the Game "Gangstar: Miami Vindication" which was available for Android and is still available for iOS.
The game files mostly contain .bdae files and .tga files (also .bmp, .gmap, .pycst, .pyarray, .array, .bin, .ogg (which are actually playable), and some more). The .bdae files are normal zip files (as mentioned in this forum), which contain the files:
dependancies.txt (yes, it is really wrongly spelled)
little_endian_quantized.bdae
version.nfo

I have looked at the actual (not zip) .bdae file in a bit more detail and as also already mentioned it has a very similar header to the Nintendo BRRES format, although not the same. I have documented my findings until now here: https://gist.github.com/z3ntu/93d05b38d ... 2d0ae214a6

I will attach one .tga file and one .bdae (zip) file so maybe you can find out more, as I have little to no experience in this area.

Cheers.

Posted: **Tue Jun 14, 2016 11:24 pm**

while you can extract the bdae file down to 3 files you gain nothing because the data is already uncompressed
but you should extract it anyway so the offsets in the model file make sense.
this is the first submesh of little_endian_quantized.bdae from your car_delivery.bdae sample

find byte pattern 30 2C 30 2C 30 2C (0x9E8)
go back 8 bytes and read address
jump to that address which is where the model name offset is
go back 12 bytes to get number of submeshes

the table before the first submesh
0x9840 - number of submeshes counting from zero
0c984C - offset to model name
0x9850 - length of first vertex block
0x9854 - offset to first vertex block
0x9858 - length of first face indices data (divide by 2 to get num faces)
0x985C - offset to first face indices
0x9860 - length of second vertex block
0x9864 - offset to second vertex block
0x9868 - length of second face indices data (divide by 2 to get num faces)
0x986C - offset to second face indices
etc

vertex strides for each submesh in order from 0-6
0x37C0 - 32
0x3878 - 36
0x3940 - 36
0x3A08 - 32
0x3AC0 - 32
0x3B78 - 32
0x3C30 - 32

the structure of this file looks a little like the bre model files here
viewtopic.php?f=16&t=14455

Posted: **Wed Jun 15, 2016 5:12 pm**

Many, many thanks for finding that out

Thanks to this wonderful forum full of extremely nice people

I now have this model in the unity engine:

(everything parsed with BinaryReader, etc in a C# script).
Now I just have to find out, how to get some data out of the .tga (probably) files that I get textures for everything.

Apparently these are all the textures from a car in the game...

Code: Select all

$ ls -al car_*.tga
-rw-r--r-- 1 luca luca  43716 Jun 25  2011 car_body_reflection.tga
-rw-r--r-- 1 luca luca  43716 Jun 25  2011 car_body_reflection_night.tga
-rw-r--r-- 1 luca luca 174788 Jun 25  2011 car_cops_texture_d.tga
-rw-r--r-- 1 luca luca 174788 Jun 25  2011 car_cops_texture_damage_d.tga
-rw-r--r-- 1 luca luca  87420 Jun 25  2011 car_interior_d.tga
-rw-r--r-- 1 luca luca  16436 Jun 25  2011 car_interior_d_lo.tga
-rw-r--r-- 1 luca luca 699076 Jun 25  2011 car_poor_texture_d.tga
-rw-r--r-- 1 luca luca 262196 Jun 25  2011 car_poor_texture_d_lo.tga
-rw-r--r-- 1 luca luca 699076 Jun 25  2011 car_poor_texture_damage_d.tga
-rw-r--r-- 1 luca luca 262196 Jun 25  2011 car_poor_texture_damage_d_lo.tga
-rw-r--r-- 1 luca luca 699076 Jun 25  2011 car_texture_d.tga
-rw-r--r-- 1 luca luca 262196 Jun 25  2011 car_texture_d_lo.tga
-rw-r--r-- 1 luca luca 699076 Jun 25  2011 car_texture_damage_d.tga
-rw-r--r-- 1 luca luca 262196 Jun 25  2011 car_texture_damage_d_lo.tga

The other .tga files are just textures for other objects or atlas*, alpha* or night* (like night59.tga, etc) files...
Link to the "car_texture_d.tga" and a "DefaultEffects.bdae" file is here: http://www.mediafire.com/download/ylpe6 ... ntax_2.zip (can't attach here because it's too big)

XeNTaX

bdae to 3ds model

Re: bdae to 3ds model

Re: bdae to 3ds model

Re: bdae to 3ds model

Re: bdae to 3ds model

Re: bdae to 3ds model

Re: bdae to 3ds model

Re: bdae to 3ds model

Re: bdae to 3ds model

Re: bdae to 3ds model

Re: bdae to 3ds model

Re: bdae to 3ds model

Re: bdae to 3ds model