HaloMods "Classic" Read-only Archive

Ok, I've been messing around with the collision of the famous log, because it's a simple box with 8 "verts".

I've attempted to turn it into an model file by reading the verts in hex (I read the collision sticky, and from what I read the order is x coord, y coord, z coord, vertice number. That's what I based the rest on.), converting the coordinate values from hex to dec and then entering the values for the respective coordinates in the correct locations.

I read the collision sticky, and from what I read the order is x coord, y coord, z coord, vertice number. That's what I based the rest on.

However, the decimal values are huge, way to big for gmax. So I divided each number by 100000, which makes them an ok size for the program, it works.

Except that uh-oh, after entering the values for each 8 verts, the verts look nothing like what it should. I deleted the faces prior to moving, so I only have 8 vertices, and they're in no way the shape of a box.


I have a feeling I missed something. I dont know if I have to do anything with map magic, or anything else relating to that, or something else. if anyone can tell me what I did wrong, that'd be awesome.

I'm using windows' calculator to convert, I paste the number in hex into the hex mode under scientific, and then click "dec", to get the number. Example:

hex: F0AE883E
dec: 4037969982


Is that anywhere near right?




I'm hoping to somehow get a method to make it easy to edit basic collision models, because the process I use now is extremely tedious and requires memorization of which vertice corresponds to which point in hex. It'd be awesome if somebody knowledgeable in Programming could help automate any step of this process.

You need to use floats (or singles depending on your terminology), and make sure the number is read as in little endian.

example(s)
org hex: F0AE883E
float: 4.321207873e+029

Little endian hex: 3e88aef0
float: 0.2669596672

Thank you very much conure. I'll try that out.

This, is what the fallen logs' collision model would look like, if it were a model:






Oh wow! A BOX!!!

What I'm hoping is that this process can be somehow automated to get rid of the tediousness and guess work involved with plotting points and connecting them into faces, and somehow get a method of retaining which point is which. This would allow for the first real collision model changes outside of CE since Ang88's Platform, which was done blindly through straight hex editing.


I'm sure that it would be rather easy to design a program to put the points and their coordinates into OBJ file-form, which would keep which points are which, allowing for actual editing of collision models, as opposed to blind stretches and guesses. Being able to visualize the actual model as your editing it is a huge help.

However, it's far from being at that stage. I have no knowledge of what dictates which "verts" connect, this was simple because it's an 8 corner box, something like a banshee or an Elite won't be.


I am illiterate in almost all forms of programming, outside of simple "If-Then-Else" statements through my calculator. Needless to say, those bored days of math class are no help to this. If anybody is interested in assisting me in any of this, that would be amazing.

Great work Shef. I would like to see a collision model editor too.

http://forums.halomods.com/viewtopic.php?t=79702

look there Philly. I'm trying.

Is that a parallel universe or something?

Ooops, wrong one.

http://forums.halomods.com/viewtopic.php?t=79715

there we go.

Sorry, I don't know anything about that sort of stuff at all. Go to askconure.com or contactaltimit.net.

/virtual high five

If/when I restart work on Esch this'll definitely be used. That's some good job on the research.

Right now I have plugins in HMT format using eschaton that allow for editing of the 8 verts of the "log", working fully and perfectly to an extent.

However, planes I'm still working on, and I need to figure out what the i, j and k values in the planes section of the collision model in HEK represent.

I have the d (which I believe is distance from the orgin) mapped out, and is also editable in the plugin, however changing it to match the vertice layout causes it to go all fubar. I think I need to find out what the IJK does to perfect it.


I also think that there might be a limit to the size of a collision model, which would explain why you cant stretch the X and can only stretch Y so far, Ang88 stretched Y 5x it's stock, which is roughly .22

X stock is roughly 1.35, .22x5 is 1.1. This could be why he couldn't go 6x, if there is a limit. I'm looking to see if anything resembles a possible limit for it.

I'm also recording everything I find out, so that if anybody tries to continue what I do it'll be easier on them. It's sort of like a journal, I'm writing down any ideas and things I've figured out, as well as brief explanations on how I believe things work. I have it in HTML format so that I can easily include pictures to explain things better. I'll release that alongside the plugin's final release.


And thanks Alt, that means a lot coming from you.

i,j and k are normally used to denote vectors corresponding to the cartesian coordinate system. i along the x (horiz) axis, j along the y (other horiz) axis and k along the z (vert) axis. I'd assume that they represent the orientation of the planes by being normal to them. (If there's one vector per plane.) One extra note on d. I'd be wary of assuming it's distance from the origin. When I was working with bones for mod2 tags, they had d be displacement from the parent node. So it's the distance from the previous bone as opposed to distance from the origin. It's possible that the coll tag has a similar structure. I'd keep an eye out for words like "parent", "next" and "child" which would indicate a node structure as well. If that's the case, then this will quickly become difficult to work with purely through plugins since it'll give plenty of info about a given plane but not the shape becomes very difficult to understand. That tangent aside, I wonder if the vert values are actually verts relative to a point at the center of the plane displacement d from the previous plane. In the case of the log this would be starting from the origin. (I'm writing this mostly stream of consciousness so forgive my rambling nature.) Actually working from that assumption you could have the vector represent the direction of the displacement, d represent the magnitude or displacement along that vector and then define the finite plane with verts whose x,y and z values are relative to where the vector ends.

Altimit01 wrote:i,j and k are normally used to denote vectors corresponding to the cartesian coordinate system. i along the x (horiz) axis, j along the y (other horiz) axis and k along the z (vert) axis. I'd assume that they represent the orientation of the planes by being normal to them. (If there's one vector per plane.)

Ok, so you think the IJK are coordinates, just like the XYZ, and each one is used to denote the location of planes relative to the others?

I no longer believe that the d value is what I earlier said, I'm sure you're right with your assumption.

And yeah, there are multiple references to children and nodes, BSP3D Nodes and BSP2D References. I was going to try to steer clear of that unless neccescary, partly because I don't understand their functions and have a feeling I won't be able to without a lot of work and thought, and partly because chances are if somebody knows what they do they'd be using CE anyway.

After that part you kind of lost me. I was never really planning to get in as far as what you're describing, I was hoping to just make this plugin allow users to create a box of any size, without limits in any direction, have the faces match up, and then take a break for a while, maybe going back to it later on. I just don't have the knowledge to completely understand everything about it, and it'll take a bit for me to be able to.



Thank you so much for all of your help with this Alt.

If you're interested, I found the method by which verts are connected. I've been using conure's coll.ent plugin which is basically everything out of the HEK to work through the structure. The reflexive for edges has an index to the starting and ending vert chunk which describes the edge. So it might have a 0 and a 1, meaning that it is the edge between vert chunk 0 and vert chunk 1 from the vert reflexive. It's a bit different from the usual model method of defining verts and inds for faces. Luckily, if an OBJ model is triangulated, determining edges is a simple matter of taking the three combinations of two verts out of the three listed verts for a given ind and removing duplicates.

That gets the general shape of the collision model but there's more to it. I haven't been able to check this yet, but I have a strong feeling that each collision model also uses a BSP. I'm willing to bet that the planes are actually for dividing the model. The bsp2d reflexive is similar in that it has a 2D vector which could describe a line for dividing along a plane. There's still a lot to go through and test but I think that might be along the right track.

I already knew about the edges, I've jotted down which edge contains which vertices in a little chart. Thankfully being on PC gives me the luxury of having the HEK to help guide me with things, and pretty much any value I need, else I would be rather lost.


Yes, there is a BSP, it's the main branch, and the planes/verts/surfaces/BSP3D/BSP2D References are a part of it, little sections of the bigger whole.


If you're right on the plane thing, I'm sure you're right on the BSP2D, because it references the plane that is opposite it. What I mean is, the last BSP2D references the first plane, the 2nd to last the second plane, etc. etc.

It also contains a value input for the BSP2D node it uses, however in the log collision there are no 2D nodes, that section is empty. In each of the BSP2D's it contains a number, (-2147483643), that number goes down by one (mind that it's negative, next in sequence is -2147483644) every time the count goes up.

Meanwhile, the BSP3D nodes do the same, starting at that same number and going downwards, also containing offsets for planes, on the 3D the planes match up (0-0, 1-1, 2-2, etc.).


I dont know if any of this is helpful, but I'm just trying to throw out some stuff and see what you make of it, considering you're much smarter then I am.

Haha, woo, don't I feel dumb.

First person I contacted for help with this was neodos, and he answered a few questions and posted a link to a tutorial he wrote. I didn't really understand it, so I sorta ignored most of it.

I was about to re-PM him with some questions, when I re-read his tutorial:

http://forums.remnantmods.com/viewtopic ... 5048#p5048

Gold Mine right there, explains a lot about edges verts faces, and I'm happy to say IJK and D values. Turns out I was right on the distance from the origin assuming it's the same, which I'm sure it is.

It's for halo 2, but it's pretty much the same minus the [phmo] references which don't exist in PC.

Expect some progress on the plugins.

Ah. That makes some sense. It seems rather weird that they would also define planes using the vertices. I'm going to do a check to see whether or not the verts are coplanar with the defined plane but if they are then this might be a lot simpler than previously thought.

I just finished updating the plugin. I cut out the Pathfinding Spheres and put in the IJK and D values for each face, correctly mapped out (in Z+ Z- form, as is accustomed).

From what I can tell, this allows projectiles to hit it as opposed to flying through it. Which is nice.

I have a simple version with just the D value, and then a more complex containing the IJK values as well. From what I read they determine plane rotation, which I doubt the average user will ever use, so I'm giving them the option of a more straightforward plugin.

Check the download topic for an update everyone. give me a minute or two to upload it.

It still begs some questions about the purpose of the bsp, bsp3d, bsp2d and leave reflexives but those might be answered with more research. Some other things to consider are whether D is distance along the vector or simply the shortest distance from the origin to the plane. Also to think about is whether the vector if used distance D from the origin has to intersect a point between the four verts. If it didn't then the shape would not be convex which leads to some interesting guesses about the use of bsp nodes. Still this should be useful and lead to more research. Thanks to both you and neodos.

Edit:
I've been looking into it more and so far have been able to construct the collision models of several objects. I've been doing it by hand but now have a method down where I could do it programmatically (as soon as I get my dev tools sent to me). I'm not 100% on how planes interact with the origin and D yet but I'll start looking into it when I have the tools to do so. If the plane doesn't have to intersect the face then it's that much easier. It'd also be the simplest explanation. Here's the files I've created so far for those interested. The over shield has some extra stuff in it as I was testing the the plane vectors. Here.

I HAVE ABSOLUTELY NO IDEA WHAT ANY OF YOU ARE TALKING ABOUT.



PS HI DEAD HAMSTUR!!!