HaloMods "Classic" Read-only Archive

Fallen Trunk Example


MATERIAL DEFINITION

Sometimes its name comes as 'col left rudder' or something.
I suppose its not quite a material name like 'rubber' but the structure is the same.

There exists a reflexive pointer to material list @ 0x234
(This is constant for all collision models).
It will specify a chunk count and an address for the start of this material list.

Each chunk/material definition is 0x48 Bytes long.
(Although this doesn't seem 100% constant more like 95%)

If you measure 0x24 bytes into the block there is a short,
if turned to FFFF results in a 'black hole' behavior. If turned to various other int values, ie: 0400 for wood.
Then when you hit/melee/collide with this thing, it gives off different sound/visual effects.

This is good because you don't have to swap metas, and potentially erase cool effects.


FRAME DEFINITION

Reflexive pointer to frame list @ 0x28C
It specifies a chunk count and an address
(This is constant for all collision models)
ie: Fallen Trunk

0100 0000 50CF 4E40
1 Frame Chunk of 0x40 Bytes beginning at That offset.

Swap the Endian, Subtract the Magic, (Subtract the Meta if your working with the sub-files).
And there's your offset.

Inside the small meta files
that turns out to be 0x3D4

The Frame definition is
0x40 Bytes long.
0x20 Bytes in is a single quad which if turned to FFFF turns off the collision model.
I don not know if this is an intended result, or if its some kind of parsing error.
0x34 Bytes in is another reflexive pointer to the frame collision definition.

ie: for fallen trunk

0100 0000 90CF 4E40



FRAME COLLISION DEFINITION (REFERENCED TO BY REFLEXIVE POINTER IN FRAME DEFINITION)

Given the 0x60 byte Frame Col Def. Block.
**NOTE**
When I say @POS I am referring to the fallen_trunk.coll.meta
This is for example purposes only.
**END NOTE**
@POS 0x414
0600 0000 F0CF 4E40
6 Chunks :: Size 0xC bytes at 0x474

@POS 0x420
0600 0000 38D0 4E40
6 Chunks :: Size 0x10 bytes at 0x4BC
These are the force plane definitions.

@POS 0x42C
0600 0000 98D0 4E40
6 Chunks :: Size 0x30/0x6 = 0x08 bytes at 0x51C

@POS 0x438
0600 0000 C8D0 4E40
6 Chunks :: Size 0x8 bytes at 0x54C

@POS 0x450
0600 0000 F8D0 4E40
6 Chunks :: Size 0x48/0x6 = 0xC bytes at 0x57C

@POS 0x45C
0C00 0000 40D1 4E40
12 Chunks :: Size 0x18 bytes at 0x5C4

@POS 0x468
0800 0000 60D2 4E40
8 Chunks :: Size 0x10 bytes at 0x6E4


BLOCK 1 (All shorts, except for that FFFF FFFF?)

0000 0000 0100 0000 0500 0080
0100 0000 0200 0000 0400 0080
0200 0000 0300 0000 0300 0080
0300 0000 0400 0000 0200 0080
0400 0000 0500 0000 0100 0080
0500 0000 FFFF FFFF 0000 0080

BLOCK 2 (THE FORCE PLANE BLOCK [ALTERED FOR MY OWN PURPOSES])

0000 0000 0000 0000 35FA 7F3F 9A99 993E
0000 0000 0000 0000 0000 80BF 9A99 993E
0000 0000 0000 80BF 0000 0000 CDCC AC3F
0000 0000 0000 803F 0000 0000 CDCC AC3F
0000 80BF 0000 0000 0000 0000 CDCC AC3F
0000 803F 0000 0000 0000 0000 CDCC AC3F

Does the force plane always go z, z, y, y, x, x? And if so, does the pattern repeat?



BLOCK 3 (All Shorts)

0000 0100 0000 0000
0000 0100 0100 0000
0000 0100 0200 0000
0000 0100 0300 0000
0000 0100 0400 0000
0000 0100 0500 0000

BLOCK 4 (All shorts)

0500 0000 0500 0080
0400 0000 0400 0080
0300 0000 0300 0080
0200 0000 0200 0080
0100 0000 0100 0080
0000 0000 0000 0080

BLOCK 5 (All shorts)

0000 0000 0000 0000 0000 0000
0100 0000 0200 0000 0000 0000
0200 0000 0200 0000 0000 0000
0300 0000 0600 0000 0000 0000
0400 0000 0100 0000 0000 0000
0500 0000 0700 0000 0000 0000

BLOCK 6 (All shorts...Or Verticies?)

0100 0000 0200 0000 0100 0000 0B00 0000 0000 0000 0300 0000
0200 0000 0000 0000 0400 0000 0900 0000 0000 0000 0400 0000
0400 0000 0500 0000 0300 0000 0A00 0000 0100 0000 0200 0000
0500 0000 0300 0000 0600 0000 0800 0000 0100 0000 0400 0000
0000 0000 0600 0000 0500 0000 0800 0000 0000 0000 0200 0000
0600 0000 0100 0000 0000 0000 0A00 0000 0000 0000 0500 0000
0300 0000 0700 0000 0700 0000 0900 0000 0100 0000 0300 0000
0700 0000 0400 0000 0200 0000 0B00 0000 0100 0000 0500 0000
0000 0000 0500 0000 0200 0000 0100 0000 0200 0000 0400 0000
0300 0000 0200 0000 0000 0000 0300 0000 0300 0000 0400 0000
0400 0000 0600 0000 0400 0000 0700 0000 0200 0000 0500 0000
0100 0000 0700 0000 0600 0000 0500 0000 0300 0000 0500 0000

BLOCK 7 (CO-ORDINATE BLOCK [ALTERED FOR MY OWN PURPOSES])

CDCC ACBF CDCC ACBF 9A99 993E 0400 0000
CDCC AC3F CDCC AC3F 9A99 993E 0000 0000
CDCC ACBF CDCC AC3F 9A99 993E 0100 0000
CDCC ACBF CDCC AC3F 9A99 99BE 0600 0000
CDCC AC3F CDCC ACBF 9A99 99BE 0200 0000
CDCC ACBF CDCC ACBF 9A99 99BE 0300 0000
CDCC AC3F CDCC ACBF 9A99 993E 0500 0000
CDCC AC3F CDCC AC3F 9A99 99BE 0700 0000

THE STRETCHING THE LOG EXAMPLE

I'll tell you straight out, I haven't yet figured out how to stretch a collision model unconditionally. There seems to be a limit on how big it can get, for this log anyway. My analysis of the other data blocks may yield results in the future.

BUT, for the standard log-streching, I have some addition information in regards to forces exerted on each of the walls. If you haven't seen my SPRING-LOG movie go here:

http://files.halomods.com/viewtopic.php?t=1787

The streching of the log deals with BLOCK 2 and BLOCK 7.
(NOTE THAT IN FRAME COLLISION DEFINITIONS, THERE MAY BE MORE THAN 7 BLOCKS. IF SO, THE LAST BLOCK IN THE DEFINITION HOLDS THE CO-ORDINATE BOUNDARIES)

As far as I have discovered, there seems to be a limit of about 1.35 for the X, Y and Z values. Alas. I shall endevor to find a way around this.

Step 1

FIRST STRETCH THE CO-ORDINATE DATA

Lets take for example the first line of data in BLOCK 7

CDCC ACBF CDCC ACBF 9A99 993E 0400 0000

AAAA <- quad, AAAA AAAA <- double-quad

The First three double-quads are the X, Y, and Z boundaries
respectively.
The last double-quad is a vertex to which it refers.

ie: CDCC ACBF is the X-boundary.
If your using a hex-editor (which I strongly suggest)
then if you highlight this d-quad, then you'll notice
it has a float value of -1.35.

I didn't exactly stretch it or multiply the origional by
a integer as xorange or GlasssJAw did, I simply set it
to a number I liked.

Ensure that your consistant with your co-ordinates for making
a panel or cube.

Ie:

CDCC ACBF CDCC ACBF 9A99 993E 0400 0000
CDCC AC3F CDCC AC3F 9A99 993E 0000 0000
CDCC ACBF CDCC AC3F 9A99 993E 0100 0000
CDCC ACBF CDCC AC3F 9A99 99BE 0600 0000
CDCC AC3F CDCC ACBF 9A99 99BE 0200 0000
CDCC ACBF CDCC ACBF 9A99 99BE 0300 0000
CDCC AC3F CDCC ACBF 9A99 993E 0500 0000
CDCC AC3F CDCC AC3F 9A99 99BE 0700 0000

You'll notice that my x-bound is varying between
1.35 and -1.35.
y-bound between
1.35 and -1.35
z-bound between
0.3 and -0.3

The original log file did as well, although
it was more like 1.35094 ...

9AEB ACBF = -1.35....

You can perform similar streching for each co-ordinate,
but keep in mind, I believe these to be only defining
the vertex at specified co-ordinates.

The above blocks (not BLOCK 7) I believe define the
connections of verticies in the collision model.
So increasing these numbers arbitraily may result in
holes.

NOW, go to block 2 (The force plane block).

In the original it appears as:

69DF 593C 0000 0000 35FA 7F3F 87BF 863E
CBBE 8BB4 CF1F A733 0000 80BF F862 7B3E

998D 643C A0F9 7FBF DB49 00B4 D0C1 933E
942B BABB F1FE 7F3F F914 7E33 649C 8C3E

0000 80BF 0000 0000 0E0A F334 95EB AC3F
0000 803F B73A EC28 DA6A 82B4 99EB AC3F

These 0x10 packets define the forces exerted throughout
the collision model.

In the fallen trunk example (not necessarily others)
Packets 1 and 2 define z-forces [up/down]
Packets 3 and 4 define y-forces [-/+]
Packets 5 and 6 define x-forces.[-/+]

The format of the packet changes slightly depending on what
axis it deals with.

ie: For z-axis.

Skew-X, Skew-y, Force-Z, Distance-Z

Skew-[XYZ]

What do I mean by Skew?
Well, here's the deal.

If you put a skew of 1 (float32) or 0000 803F
then it will result in a 90 degree inclination.

If you want say, a 60 degree incline then the value
should be 60/90 = 0.7 = 3333 333F

The same goes for y-skew.

Force-[XYZ]:
Its a ratio of gravity. So a value of 0.9999 results in
a stable platform. 1.0 doesn't work for some reason.
So, if you want a spring, turn it to say 1.45.
Careful though, falling hurts

Here's my new Collision Model Plugin

http://files.halomods.com/viewtopic.php?t=2925

Ah, its good to see you finally worked out the bugs in your plugin. Teh sticky time!

New Development:

It turns out BLOCK 1 is CRITICAL to the collision model functioning.
Not sure what it does, but it causes many exceptions if fiddled with.

New Development:

The B1 Block I believe defines triangles for the collision model.
BLOCK1 is filled with shorts, and so I took them to be verticies.

So I went into milkshape and created some verticies. And made some
faces that use these verticies.

I then used the data from BLOCK 7 to move the verticies to their
respective X, Y, Z co-ordinates.

And I saw THIS:::

http://files.halomods.com/download.php?id=3298

Hey, for those of us without milkshape, could you give us a brief synopsis instead of teasing us with cyrptic links

AWESOME job figuring this stuff out. I looked at the collision model data earlier and couldnt make heads nor tails of it.

-RunningRiot

yes, I think pics would be nicer for those of us who cant get milkshape to work... wah...

So I was doing more work on the collision model (as it is my all consuming obsession)

And I came to the realization, while looking up info on my PC-Model data,
that the format is remarkably similar to that of the Direct X 3D mesh format.
Which is probubly some kind of spin-off for the x-box.
I read it somewhere that it was a slightly different decendant of the same file type.

Anyways.

For each frame there are 0x60 block(s) [could be multiple chunk counts] of data that defines the Mesh-Data. Inside of it are up to 8 reflexive addresses
inside the meta to various other data-blocks. (I found another one from my exploration of the banshee collision model).

Anyways,
The reflexive addresses are at the following offset from the frame's mesh-data (which is not necessarily right beside the frame data itself
, look for a pointer at the end of the 0x40 byte frame definition)

Block 1 0x0
Block 2 0xC
Block 3 0x18
Block 4 0x24
Block 5 0x30 <-- the new guy
Block 6 0x3C <-- old block 5
Block 7 0x48 <-- old block 6
Block 8 0x54 <-- old block 7

Now in correspondance with DirectX 3D Mesh format, we know this:

From the Microsoft DirectX SDK

A mesh is composed of vertices, face indices, attributes, and attributes indices. The vertices are stored in a vertex buffer that is basically an array of all the vertices. Each vertex contains the information needed to render it in a polygon. Examples of the data contained in a vertex are position, normal, and texture coordinates.

The faces are defined by an index buffer that is an array of indices into the vertex buffer. So each entry in the index buffer has three indices into the vertex buffer that define the points making up the polygon. An attribute buffer exists that defines the way faces will be rendered. Each entry in the attribute buffer contains the information needed to setup the rendering pipeline to draw a polygon a particular way.

Now, keep in mind (faces != trianlges) But they are similar.
A face requires 3 verticies.

So here's the deal with the collision model thus, far,

Block 1 seems to be an adjacency matrix.
Characterized by the FFFF FFFF at the end. This means That the indice
in that line connects to the outside world. If you change that FFFF FFFF value, then its safe to say the game will crash.
The format of the adjacency block might go like this:

Vertex_A Face_ B Array_Pos 0080
...
...
Vertex_Z FFFF FFFF 0000 0080

Block 2 is what I have called the Force Plane Buffer
I still have yet to determine the face the force applies to.
But be patient, it has to be recorded somewhere.
Keep in mind, in the fallen trunk example there are
6 indice total, and 6 force packets.

Block 3 is what I believe to be the Attribute buffer.
Notice in the D3D definition that each indice must have an
associated attribute.

This 'attribute' is most likely the material or surface of collision.
In the fallen trunk example:

0000 0100 0000 0000 INDICE 0 USES MATERIAL 1?
0000 0100 0100 0000 INDICE 1 USES MATERIAL 1?
0000 0100 0200 0000 INDICE 2 USES MATERIAL 1?
0000 0100 0300 0000 INDICE 3 USES MATERIAL 1?
0000 0100 0400 0000 INDICE 4 USES MATERIAL 1?
0000 0100 0500 0000 INDICE 5 USES MATERIAL 1?

And notice that this 1:1 relation is in NO OTHER DATA BLOCK
that fits the number of materials in the file, 1.

Block 4

0500 0000 0500 0080 INDICE ARRAY?
0400 0000 0400 0080
0300 0000 0300 0080
0200 0000 0200 0080
0100 0000 0100 0080
0000 0000 0000 0080

It might be trivial to look at but see:

Indice_Number Array_Pos 0080

Block 5

This block does not appear in the fallen trunk example,
so I have yet to characterize it. Since it is clearly not
essential to my understanding, it can wait.
Its a rare packet, that occurs in the banshee collision meta.
Take a look if you want, it has a packet size of 0x14 bytes.

Block 6 & Block 7

These two blocks are still unknown to me.
But as you will notice, through elimination, we have only three
essential areas these blocks could be.

Indice Buffer,
Vertex Buffer,
Texture information? (May not be needed in the collision model)

We know the vertex buffer is Block 8. (Block 7 in my above notes).
So that leads me to believe that Block 7 (the large 0x12 byte packet one)
is the indice buffer.

Unfortunatly, experimentation in these blocks usually results in halo hanging up and crashing. They are essential to a functional collision model however.

Block 8

Well we knew it had to do with verticies before, so now its official. This is the vertex buffer. Listing positional bounds on each vertex.

For more information on DirectX 3D Meshes goto

http://msdn.microsoft.com/library/defau ... d=28000410
Goto the left side tree menu DirectX->Columns->Driving DirectX->D3DX Meshes, Part 1

So, there's my update. Its not of much practical use, but there ya go.

Hey, good job Berkano!
This is about where I'm at too.

Thanks a lot for the material definition!
I hadn't figured that out...but I was looking for it.
Do you have any idea where it references these numbers?
Somewhere in the map it should define what effects/snds/etc to use for each material type.
Also, have you experimented enough to know how many different materials there are?

I believe the blocks of shorts are indices, like you said, to define the triangles.
The indices for the regular models are in triangle strips but I haven't figured out these indices yet.
They will likely become important when we want to build collision models from scratch or reshape existing ones.
Note: I've always thought that block6 were indices also, but if so, they don't make sense because they contain numbers higher than the number of verts.

The "force" can be incremented in the other direction to achieve "attach"
...only small increments though, just like with "bounce"...or strange things happen.

What I did to see the collision model was to replace a model's vertices with collision model vertices.
That way I was able to use HMT to extract a model containing the collision model's verts.

I have not yet been able to get past the apparent size limits....still trying.
I wonder if there is some sort of global size limit, and if so where is it defined.

On the Xbox this collision model also has a block that looks like this (4 packets):I noticed you didn't mention this...does HPC not have anything in this section?

Btw, do you use hex workshop?

Berkano wrote:So I was doing more work on the collision model.........

Good stuff!

Wow, praise from xorange!

Do you have any idea where it references these numbers?

I assume you mean the list of 'material numbers'. Then no I do not.
I would assume they would be placed in a general block of data that would
deal with all collision models/pc-models... hell just models in general..

And IF there is such a place in the code it is likely that this is where the size limit is for scenery. To my knowledge no piece of scenery is larger in the x-direction than the log. And we're all aware that even the z, and y axis have their limits as well.

If you want to know a full list of materials, then it would be a long one. I experimented for a long while and there seems to be no end of sound effects heh. But then again I was using raw hex to do it.
My plugin is available for meddling with those numbers.


So yeah, we need to find the master block of data that deals with these globals.

I was aware that force could be negated to achieve attachments, this is most likely how plasma grenades stick to an opponent.

The data block to which you reffered to is directly below a tag called __base or base0N
N being a Integer > 0.

This is where I believe effects are triggered. The warthog spin-tires for example. Or a ghost/bansee/wraith destruction =) I have documented it a bit, but I have not experimented yet.

My goal for that block is to be able to make a warthog explode and die. =)

Since I hit a brick wall with these stripped/optimized face definitions. I might try to go down that direction.

Anyway, lets change this thread into a knowledge database, so if you find anything significant, document and post here. I have no wish to keep anything secret from Halomods.

Oh yes, and I do use hex workshop.

That just gave me an idea!

As far as extending the size of the platforms, why not just increase the size in the z direction(the tree is much taller than the platform is, so there may not be as strict a limit there) and rotate it in sparkedit.

-RunningRiot

Best case scenerio for that is we get VERY long platforms.
Reducing the need for several thousand, granted, but still.

It would be better if we could figure out how to make larger ones in all axis directions.

Also I suspect that the z-axis has limits as well, I can't test it here from the school but I recall a similar experiment.

I have yet to read the above in all its entirety, but I have to say: GOOD JOB!!! This looks very promising... perhaps this will help fix the bugs that BOLL and Grenadiac had with collision on the BSPs... YES, the bsp can be edited in the same way that the models can, just htat the collision info wasn't known... (perhaps) until now...

bloodgultch - HPC (xbox layout is same, offsets may differ)
scenery/rocks/boulder/boulder - collision model

Meta begins: 8EC1AC

Ready? Here we go.

---- At 8EC1AC ----

+0x28C -- Reflexive to bone collision info (named "pieces" in plugin) located at meta + 0x28C: points to: 8EC520 -- Count 1 (count & name always same as number of bones for real model)


---- At 8EC520 ---- (following bone collision reflexive above)

+0x00 -- 32 byte name (same as bone data for real model)
+0x34 -- Reflexive to Collision BSP/model info

Reflexive to Collision BSP Info: points to 8EC560 -- Count 1




---- At 8EC560 ---- (following collision bsp reflexive above)

BSP Reflexives
1st: 8EC5C0 -- Count 50 -- 3d nodes
2nd: 8EC818 -- Count 32 -- planes
3rd: 8ECA18 -- Count 42 -- leaves
4th: 8ECB68 -- Count 51 -- 2d references
5th: 0 -- Count 0 -- 2d nodes
6th: 8ECD00 -- Count 32 -- surfaces
7th: 8ECE80 -- Count 50 -- edges
8th: 8ED330 -- Count 20 -- vertices

Vertices: same as boulder model; same number, same locations. -- This is not the case for

all models.

---- At 8ED330 ---- (following vertex reflexive above)

0x00 x coord Float (x-coordinate for current vertex)
0x04 y coord Float (y-coordinate for current vertex)
0x08 z coord Float (z-coordinate for current vertex)
0x0C edge references - integer (edge that touches this vertex)



Note: Changed vertices to construct a 1x1x1 cube; results interesting. Due to mistakes with edge references(?), I was able to walk one way through portions of the model, but not back through the opposite direction. Rather than constructing a cube, I'll try doubling the vertex magnitudes effectively scaling the model and collision model 4x, but leave edge references the same; should prevent some of the odd artifacts.

Doubled each vertice by hand, still have strange artifacts, such as walk through model from certain angles, regular sized model from other angles, enlarged model from others...?

Nice stuff tjc...nice stuff

Hey, right on you guys! Thank tjc!
I was wondering if the collision models were little BSP trees, or if they were some stripped down version of a BSP...like, organized differently than a standard BSP tree.
That clears it up as I now know where the leaves, etc are! woohoo!
I love progress. ^_^

Ok, on to larger platforms, etc....

I've looked at a lot of collision models and they do all appear to adhere to the same specific limits. (i.e. how far the surface of the BSP can be pushed out, etc.)

Collision models that appear larger than that are probably just larger/longer BSP trees.
They have several different sections that fit together to create a larger collision model.
I think that this is going to be the best way to create longer bridges and such.
I'd say it's as "simple" as making a nice stable uniform panel and then combining that with another, etc in the same way that other collision models are set up, like leafy trees....seperate frames for the trunk & leaves.
(presumably connected in the BSP tree, but perhaps not)

It may be relatively easy to combine collision models, especially if it's not necessary to connect them in any specific way.
Perhaps there's a way to just put them very close together.
This would definitely require some experimenting, and I haven't done any yet...all theory. hehe

I'll be working on this a bit later and let you guys know what I come up with.
...and I agree that this thread makes a perfect knowledge base, particularly since it's already sticky.

Berkano made a new HMT plugin to incorporate a lot of his most recent findings, just thought I'd link it from here.

It's over in the files section: http://files.halomods.com/viewtopic.php?t=2925

I think the most recent sticky, Sticky: Collision Model Numbers, should be moved into here also, moderators...