Rage (idTech5) model format md6

[TehDave]

So meshes are fine, but how are we supposed to get textures? iirc there was never a way to get textures for Rage models and we had to wait until the toolkit got released before we could get them in tga. A toolkit seems highly unlikely for this game.

[volfin]

I've been trying the importer with bmd6model files extracted from Wolfenstein: The New Order using the bms script found here. Same error as artmancarver and BjornBear mentioned. In case anyone wants to take a look and fix up the blender importer, it would be very much appreciated! Here's two example files. Hope it helps!

shakotay's tool works on smaller models, but it breaks on the larger ones (over 65535 verts). Which is sad since so many Wolfenstein models are larger than that.

I looked into this, the main problem seems to be that MachineGames changed the bmd6model container so the skeletal data is separated out into a file pointed to (usually with extension *.bmd6skel) while before the skeletal data was included. They also added a bit more padding. I was able to hack up a workaround that can extract the full models into blender 2.49b but it's a two step process.

First you have to run this QuickBMS script on your bmd6model, choose 'Y'es when it asks to overwrite (it's just appending to a file), and it will produce a file by the same name called "*.bmd6model.new". This is basically just tacking on a Rage header with a 1 bone skeleton.


Then use this modified Python Script in the Blend file to import the "*.bmd6model.new" file, and it will import all models, past the 65536 vertice limit. The only thing lost is the skeleton.

[volfin]

Had to do second post for the Blender file.

[Wobble]

[out]

[volfin]

I'm just looking at these MD6 formats, and I don't understand why some of these values are stored as Big-endian,
while other values are completely reversed in memory, like a 4-byte float. This is neither little-endian
or Big-Endian, and easily confused for a Big-Endian WORD or SHORT (which a 4-byte float is obviously not).
These RAGE programmers really screwed up this format, imho.

Yes I noticed they go back and forth between Big and Little a lot. Makes things much harder.

[Wobble]

[out]

[volfin]

Also, in the .bmd6model file, there's a list of bytes after the skeleton string. Without knowing the bone count,
I don't see how it's possible to continue parsing the file. It's just an odd dependency that seems sloppy.

Yes for my parser I did a bit of guess work. From what I have seen the format is always like this:



7 long inteters, with the last one value 0x01. Then a byte (alignment I guess) which is usually 0. Then a series of single byte bone numbers, which as you say you can't know for sure how long it is. But, for most models, it's well below 0xC0, and so far with every model I've seen, a value of 0xC0 or greater directly follows the end of the bone list. So I just keep reading bone numbers until I read a value that is 0xC0 or greater. It's could possibly break on some models if they have enough bones, but so far I've not found one that breaks that pattern. It may be necessary to back up a byte as the 0xCX number may be part of a different value. But it's still a pretty good indicator of where the bone list ends.

[Wobble]

[out]

[volfin]

Yeah, it looks like the older bmd6model files had the skeleton data embedded in the file,
but then later, it was ripped out to an external skeleton file for the newer models.

So, for the newer models, if you read in the skeleton file first to get the bone count,
you can continue parsing the bmd6model file without problems.

Have you figured out how bone-vertex assignment works? I assumed this list of bytes
was a bone remap list, but even after remapping them, the vertices are still not
assigned to the correct bone. The original bone indices are not correct either, so
I assume they must be remapped somehow.

btw, I think long_thing1 to long_thing6 is the model bounding box:

Code: Select all

float min[3];	// big-endian, reversed floats
float max[3];	// big-endian, reversed floats

And the byte list is equal to the bone count, aligned to 8-bits:

Code: Select all

#define ALIGNED8(bits)		(((bits) + 7) & ~7)

Well, using the format originally suggested for Rage, it seems to be working, almost.


the model reconstructs fine, and the vertices are weighted in what does look to be proper weight groups. But I do see a lot of flaws. And of course the actual weights are not given.

But I do think there was one thing missed when suggesting the orignal format. I think the last 5 bytes are bone assignments, not the last 4.



On models that have no weights, the last 5 bytes are always zero, not just the last 4. It's not a bone number, but is somehow related.

But it still doesn't explain why when using these bytes as bone IDs, there's some apparent corruption of the weight groupings, or why like in the example above, bone '02' is referenced 3 times, that makes no sense really. So clearly there's still something missing.

[Wobble]

[out]

[Wobble]

[out]

[volfin]

I'm looking at a model called commander60_01, and if I use the 4 bone indices found in the vertex,
they don't assign to the correct bone. For example, I see his "head" bone is mapped to his left leg vertices,
which is not correct.

Code: Select all

name1: "head_02_msh"
name2: "models/characters/standard/commanders/commander60/commander60_head01"

MESH: 4
[ 0] (p: -3.652265, 1.268753, 87.789482),  (uv: 0.945047, 0.509531)  (08AA, 7200, 550A, 984E)  (bone:  16,  11,   8,  16)
[ 1] (p: -2.892268, 2.717173, 88.365829),  (uv: 0.888635, 0.461807)  (2BDA, 6500, 2230, A21A)  (bone:  16,  11,  16,  16)
[ 2] (p: -3.813759, 1.290491, 88.655296),  (uv: 0.945763, 0.469497)  (0BA4, 5C00, 550B, 9C18)  (bone:  16,  11,  16,  16)
[ 3] (p: -2.829458, 2.659876, 87.597191),  (uv: 0.889502, 0.503089)  (28DD, 7900, 242A, 9749)  (bone:  16,  11,  16,  16)
[ 4] (p: -2.774626, 2.734160, 86.362488),  (uv: 0.879250, 0.578442)  (2BDE, 8920, 232A, 8D65)  (bone:  11,  16,   8,  11)
[ 5] (p: -1.714629, 3.216272, 87.410271),  (uv: 0.851318, 0.501059)  (58F9, 7E00, 0958, 9249)  (bone:  16,  11,  16,  16)
...

BONE_COUNT: 122
...
[ 4] name: "spine2"
[ 5] name: "neck"
[ 6] name: "head"
[ 7] name: "leftshoulder"
[ 8] name: "leftarm"		-> bone 8 is not head!
[ 9] name: "leftforearm"
[10] name: "lefthand"
[11] name: "lefthandthumb1" 	-> bone 11 is not head!
[12] name: "lefthandthumb2"
[13] name: "lefthandthumb3"
[14] name: "lefthandindex1"
[15] name: "lefthandindex2"
[16] name: "lefthandindex3"    -> bone 16 is not head!
[17] name: "lefthandmiddle1"
...

The bone byte list is not correct either, if I try to use it as a remap list:

BYTE_COUNT: 128
...
[ 4] bindex:  8  (leftarm)          -> reverse mapping does not remap to head!
[ 8] bindex: 17  (lefthandmiddle1)  -> index 8 does not remap to head!
...

After the triangle list, there are 3 DWORDs:

Code: Select all

DWORD dw1;			// 0, 16, or 32
DWORD mesh_bone_count;
DWORD mesh_weight_flag;

Do you know what the first DWORD is used for? It is always 0, 16, or 32.
I first assumed it might be related to bone remapping (count, offset, starting index?), but it may also
appear to be bit flags.

I don't know what those 3 DWORDS are, But I do know I encountered at least one mesh that had a flag in that area to indicate it had a secondary UV map (seems to be hair, so double sided transparent faces).

Code: Select all

Vertice Data[177280]		
Faces Data[26160]		
DWORD unknown1		16	
DWORD unknown2		1	
DWORD unknown3		1	
BYTE  Extra_UV_Flag	1	
Secondary UV[11080]		
DWORD unknown4		
BYTE Onebyte_End	0

next model or end.

I assume the 3 DWORDS you m ean are unknown1 thru unknown3. Not sure their purpose. But the single Byte directly after is a flag. If it's present, additional UV data is present. Will be the same as the original, two floats per vertice.

[Wobble]

[out]

[Wobble]

[out]

[volfin]

Also, some of the older ID/Doom formats (MD5,etc..) don't store things like vertex normals, binormals, tangents, for lighting.
I think these values are pre-calculated. So, if they don't store this info, then what remains? Bone weights?

That is a lot of room for just bone weights. These don't look like simple byte weights either (0-255).
Compressed SHORT floats don't make sense. Nor do they add up to 1.0. Negative weights don't make sense either.

Yes, that's been the real mystery, i can't figure out where they would be placing the bone weights or the normals, unless it's somehow in that 7 bytes of 'unknown' data in the vertex definitions. I think though it's not that unusual for game models to have no normals. But bone weights, a must have.

There is another file associated with each model, with a *.BCM extention. Usually in "Generated\templates\c01\" for instance. Since these files are named the same as various models, it could be they also contain model data. But I haven't yet explored their format.