XeNTaX

your last pluggin, is great !! more things can be loaded ... miss only ships interior and textures for ships ( nothing is load ) , station cannot be loaded

[out]

Wobble wrote:

CZW wrote:your last pluggin, is great !! more things can be loaded ... miss only ships interior and textures for ships ( nothing is load ) , station cannot be loaded

I think the data in havok.rax and novodex.rax contain the same mesh data for interiors/backgrounds.
So, you can at least see what you're missing.

Also added a fix to include some missing vertex weights.

I know it may not be able to be done but there are still a few models that don't have a proper uv map a couple being the DH17 and the Munificent, Do you have any plans to try and fix that soon?

[out]

Wobble wrote:

JakeGreen wrote: I know it may not be able to be done but there are still a few models that don't have a proper uv map a couple being the DH17 and the Munificent, Do you have any plans to try and fix that soon?

Ok, I added a fix for these two models specifically. The data that tells how these UVs are stored appear to be wrong.

Any chance you could look at the empire weapons cause it seem that almost all of them have uv problems.

[out]

Wobble wrote:Pick one specific model, and I'll take a look at it. After that, I'm done. Can't do anything more with this format.

Ah damn right well the E11, but you should really release your source so someone else can finished it cause getting out some of the maps and ship interiors would really help some peoples projects.

[out]

+1 for the shared source, you've done an awesome job ironing out this rax format and i know you said there was variations in some files but i'd like to see what format specs you have so far so we can continue the research. I think it could eventually lead to something that can import the bigger level files too.

edit

[out]

since known format specs aren't being shared except for the vague table in Han's model on the first page i guess
we have to figure this out from the start if there is to be hope for extending support to the bigger rax models.
i just don't know why anyone would keep game format specs to themselves on a game research forum


*.rax format research reboot

I'm going to start with Han's stormtrooper model since there was nothing mentioned except this
viewtopic.php?p=115108#p115108
I know this looks messy, so bear with me.

big-endian
0x00 - 4bytes - stored start address of some unk table near the end of the file
0x10 - 4bytes - stored address that takes you 20 bytes after "deft"
0x28 - 4bytes - stored start address of where that first unk table data is
0x2c - 4bytes - stored start address of material data (0x60)
0x30 - 4bytes - number of materials (4) --each material block is 288 bytes

0x60 - start material data - 1st material
---- 0x60 4bytes - diffuse texture name
---- 0x70 4bytes - normal map texture name
---- 0x80 4bytes - specular texture name
0x180 - 2nd material
0x2a0 - 3rd material
0x3c0 - 4th material

-loop through the 3 texture names in each material block (4)
you reached the end of material data when you see "deft" which i assume is the start of skeleton data.

i know nothing of the "deft" data so i skip it to a submesh info table starting at 0x2d00
116 byte stride, the last block in this table has 112 byte stride
loop through this table the same number of submeshes
i have yet to see anything that indicates how many submeshes there are
i guess you could just use the number of names as the variable here?

0x2c8c - technically the start of first block, but it is empty, so i will skip to next one ????
0x2d00 - first block - each block starts with 00 00 00 01 FF FF
----0x2d06 - 2bytes - the number of bytes relative from the end of the table to read the string for submesh name
----0x2d6c - 4bytes - offset to submesh info
0x2d74 - 2nd block
0x2de8 - 3rd block
0x2e5c - 4th block
0x2ed0 - 5th block
0x2f44 - 6th block
0x2fb8 - 7th block
0x302c - 8th block
0x309c - ends table, names are relative to this address

0x30a3 - start array of submesh names (8 in total)

0x30e8 - first submesh info starts with "00 00 10 03"
----00 00 10 03 - 4bytes
----vertex count - 4bytes
----face indices count - 4bytes
----0x30fc - 4bytes - number of material groups indicated by "FACE"
----0x3108 - 4bytes - stored address of where "FACE_OPA" starts
----0x310c - 4bytes - stored address of some unk
----0x3110 - 4bytes - stored address of where bounding box data is stored?
----0x3134 - 4bytes - stored address of where "POS" starts
------POS starts a 16 byte stride table, the last integer likely indicates where in the vertex stride certain data is stored for that submesh
----0x3148 - 4bytes - stored address of where "RGB" starts
----0x31d4 - 4bytes - stored address of where the first "FACE" starts
-----if more than one material is assigned to the submesh the stride will be 24 bytes untill the next one
----0x31e0 - start "FACE", first material group
------0x31f0 - relative offset of indices assigned to this submesh, indices start at 0x17600 in this model
------------0 for this integer because it starts with this submesh and only has 1 mat group, so it begins at 0x17600
0x3200 - next submesh
0x3380 - next submesh
0x34a0 - next submesh
0x35c0 - next submesh
0x36e0 - next submesh
0x3800 - next submesh
0x3980 - last submesh, starts with "00 00 10 0B", i am unsure why this is different from the rest

some of thes block start with "00 00 10 0B" , "00 00 10 03" or "00 00 00 02", i bet this is significant in some way.


16 bytes after the last submesh "FACE" section is the start of more data

0x3b00 - 4bytes - unk
0x3b04 - 4bytes - unk
0x3b08 - 4bytes - offset to some unkown table near end of the file
0x3b0c - 4bytes - offset to end of UV data
0x3b10 - 4bytes - stored start address of face indices data block (0x175e0) indicated by "FACE"
-------- 20 bytes after that address (0x175f4) is the stored start address (0x17600) where word face indices actually start
0x3b18 - 4bytes - stored start address of a table with 40 byte stride
----0x3b1c - 4bytes - stored address of where "POS" starts
----0x3b20 - 4bytes - stored start address of vertex block
----0x3b28 - 4bytes - vertex stride(?) (24) --if integer is 0 stride is usually 16
----0x3b30 - 4bytes - stored address of where "RGB" starts
----0x3b34 - 4bytes - stored start address of UV data

According to what we see in the Hex2obj image here
viewtopic.php?p=115086#p115086
The vertices are stored as shorts and the UVs are word with 4 byte stride per vertex


I attached the *.rax sample used for this outline if anyone else wants to have a look I'll post more as i figure it out
If anyone else here can shed light on offsets/flags etc in this *.rax format feel free to jump in!

[out]

Wobble wrote:Because in the end, I was the only coder participating in this discussion. Everyone else, except the end-users, lost interest. If people want to discuss and exchange file format information on this forum, there has to be more than one coder participating in the discussion.

gameFormats != pentagonSecrets

anyway i attached the han solo sample used for the outline in my previous post
for anyone else that want to have a look, if you need more just ask and i will provide

[out]

Don't worry i'm not asking for anything here, already did that last year and you responded, you don't have to explain your reasons for not sharing info.

Now back to topic, i am going to look at a simple weapon with smaller file size next to take a break from
the hansolo model and i will attach the sample to this post and type out what i see in it later today maybe