[X360] Star Wars Battlefront III pre-alpha (*.rax)

[Kiriller12]

So, can anyone say how to extract models from the game? Do I need to unpack smth?

[shakotay2]

to take a break from the hansolo model

why? Han is good. Contains allmost everything we need:

rax.jpg

I'm asking myself why you didn't create a Noesis script so far?

I'm about to create a Make_obj project (with 'C' source) for it which I was planning since a year now. ( But dunno if 'rax' is the very best start.)
Just trying to find the best pattern for getting the start adresses (0x3B80, 0x148F0).

Here is the project to be found: viewtopic.php?f=29&t=15955&p=128256&hil ... 2o#p128256

This is the result:


cheers

well, Ace, I see you're going for patterns (00 00 10 03)

[Acewell]

I'm asking myself why you didn't create a Noesis script so far?

I could easily make one to open that Han model, but the rax format is inconsistent from one model to the next and it wouldn't work for many.
until now all research was done behind closed doors and compiled into a closed source plugin that no one is learning anything from.
hopefully this new open research will give a basic understanding of this format that can be extended to work with currently unsupported rax models.

[shakotay2]

well, as you may know I'm not a friend of a full format analysis because it's tedious, annoying, boring.

Any 3D model extracting project I started relies on pattern searches (which have some caveats, though).
And magic tables (with offsets and counts) some times.

For the rax format it might have different categories of models.

I could try to check different models from time to time - maybe there's some similarities in them that are not to obvious on a first glance.

[Acewell]

thats fine, thanks for helping, there is however no pressure here for anyone to do anything,
i will continue to contribute my findings here over time regardless.
if you or anyone would like some unsupported samples to look at i will upload them

i'm fairly certain there are different categories of these rax files from what i've seen.

So, can anyone say how to extract models from the game? Do I need to unpack smth?

use Quickbms and this script
http://aluigi.altervista.org/bms/swbf3.bms

[Kiriller12]

use Quickbms and this script
http://aluigi.altervista.org/bms/swbf3.bms

Thanks, I already found it. Is there some plugin for 3d editing software, besides Ultimate Unwrap3D?

[shakotay2]

if you or anyone would like some unsupported samples to look at i will upload them

as a second step I'd like to check a sample where you partially could extract some meshes from. (Checking models where you didn't get any meshes from would be a last step.)

[Acewell]

Is there some plugin for 3d editing software, besides Ultimate Unwrap3D?

we're working on it

I'd like to check a sample where you partially could extract some meshes from.

that could be difficult, because usually it either works or it doesn't, and its hard to say if something is incomplete unless its obvious like a missing arm or head etc,
and when i say unsupported i mean the U3D plugin will not open it or open it properly.
here is something that looks complete but the UVs are possibly destroyed

Code: Select all

http://www.mediafire.com/file/lao8a42l6ln1660/imp_interdictor_exterior.zip

edit
here is h2o file for first submesh with working UVs

Code: Select all

0x10A640 33858
Vb1
20 99
0x3600 17953
120300
0x5B0A4 20

the actual start address for the UV block is at 0x5b0a0 (this address is stored at 0x34f4 )
but you have to skip 4 bytes to display it properly in Hex2obj.
20 byte stride for the UVs, there must be flag that indicates this change.



edit again
h2o for 2nd submesh

Code: Select all

0x11AEC4 924
Vb1
20 99
0xB2B40 212
120300
0xE3690 16

this submesh and the rest are clumped together unlike the first one, all the vertices and UVs run together.
the start address for the 2nd submesh vertex data is stored at 0x3508
the start address for the 2nd submesh UV data is stored at 0x351c
the UVs here have a 16 byte stride and are stored as floats instead of halffloats like the first submesh.

okay it looks like some of this stored data under the "POS" sections (0x3528 and 0x3598) is lining up with the change in stride from one submesh to another.
the first "UV2" 16 bytes of data has 0x14 staored at 0x3584
the second "UV2" 16 bytes of data has 0x10 stored at 0x35f4
still don't know how to tell whether the data is going to be floats or halffloats though.

[shakotay2]

here is something that looks complete

well, I see, the pattern 00 00 10 xx is not valid here. So we've two categories of *.rax files (at least) where that pattern applies and where not?
(I'll care for ob.rax asap, will have to include some debug lines into Make_obj.)

[Kiriller12]

Is there some plugin for 3d editing software, besides Ultimate Unwrap3D?

we're working on it

Good news

[shakotay2]

still don't know how to tell whether the data is going to be floats or halffloats though.

should be solvable, atm I've this, some addresses set manually, though:

ob-rax.JPG

Maybe someone could check the uvs for bogus?
Makeobj_log ob uvs err.zip

[Wobble]

[out]

[Acewell]

Maybe someone could check the uvs for bogus?

awesome, the UVs are lining up with the textures so that's a good sign and now i think i know what
all those "FACE" sections are for in the submesh data blocks, they might be material groups

the first submesh has 7 of these
24byte stride * 7 here
0x8544 - 1st submesh 1st material group - at 0x8560 = 0x0
0x8568 - 1st submesh 2nd material group - at 0x8584 = 0x3c78
0x8592 - 1st submesh 3rd material group - at 0x8608 = 0xacf8
0x8616 - 1st submesh 4th material group - at 0x8632 = 0xd674
0x8640 - 1st submesh 5th material group - at 0x8656 = 0xd6b0
0x8664 - 1st submesh 6th material group - at 0x8680 = 0xecdc
0x8688 - 1st submesh 7th material group - at 0x8704 = 0xf678

you can see the value increases after each one and could be indexing the indices length,
the 4byte integer at 0x1eb happens to store a 7 too which seems to indicate the
number of these "FACE" blocks and looks consistent with the other submesh data blocks.

also i think an identifier for different rax categories could be the letters that preceed "TOP",
for instance in the Han solo rax sample you had "CHRTOP" at 0x4c and in the ship sample
you have "BTOP" at 0x4c .

[shakotay2]

Hi Ace,
see you'll crack this format sooner or later!
(addresses are decimal here: "8544 - 1st submesh 1st material group - at 8560")

I've checked all FACE entries:
# 0x0 0x3c78 0xacf8 0xd674 0xd6b0 0xecdc 0xf678
----------
# 0x10884
----------
# 0x10fbc
----------
# 0x11034 0x1193a 0x11946
----------
# 0x11e9e
----------
# 0x11f1c 0x171d8 0x17208 0x17358 0x1a5b0 0x1a9c4 0x1aac0
----------
# 0x1aaf0
----------
# 0x1adfc 0x1b86a
----------
# 0x1b876
----------
# 0x1b9f0 0x1c0d4
----------
# 0x1c14c
----------
# 0x1c170
----------
# 0x1c7e8
----------
# 0x0
----------

For the first submesh it's 0 15480 44280 54900 54960 60636 63096 (decimal), but the face indices count is 33858.
But they are modulo 4 so they might be face indices (0, 3870, 11070,.., 15744) ?
For submesh 6 it's # 73500 94680 94728 95064 107952 108996 109248 -> 18375..27312
so this should do the trick.

(As offsets (0x3C78 - 0xF678) the values are too small, imho, since the first submesh covers 0x3600-0x5B094.)

Introduced some new groups:
Makeobj_ob-rax.zip
Looks promissing, although I could see two one-face-only groups on a quick glance.

ob_rax-SM_0_0.JPG

All thanks go to AceWell!

[Acewell]

cool thanks shakotay!

(As offsets (0x3C78 - 0xF678) the values are too small, imho, since the first submesh covers 0x3600-0x5B094.)

yeah i was just reading the values as they were stored in hexadecimal, i was thinking
those offsets were the position within the total face indices data size already known from
face count read in before that, so 0x10A640 would be position 0x0 and the length of the
first mat group would extend to 0x3c78 from 0x10A640

my theory for the last mat group
face indices (33858) * 2 = 67716 - 63096 (0xf678) = 4620 /2
so the last mat group would be assigned to the last 2310 faces out of the submesh total faces


EDIT
the entire face buffer is 0x1c866 or 116838 bytes long
the buffer begins at 0x10a641, this is considered the starting point, or 0x0 for the material groups
it looks to me like the positions given for the "FACE" groups are the absolute values within the face buffer
even the last material group in the last submesh has the value 0x1c7e8 supports this theory

so for the last material group in the last submesh
0x1c866 - 0x1c7e8 = 0x7e (126)
126 / 2 = 63

in theory the last material group in the last submesh is assigned to the last 63 faces indices in the buffer
this could be way off but it at first glance it makes sense to me and it seems to work with all the numbers given