Teh collision is not quite the same as the visible model... Someone esle has also been workin on this for awhile.
http://files.halomods.com/viewtopic.php ... highlight=
Here's a link to check out.
__Blaz0__
xbox bsp editing
Thats for PC, we're talking about Xbox here. Try learning about the BSP's collision model and compair the points on the collision and the actual BSP, then try changing the same points on both and then you'll have an actual hill.
And does anyone realize this? Talin is the first to actualy CHANGE the BSP of a map and have positive results. Keep plugging away Talin, and eventually you'll get the hang of it.
And does anyone realize this? Talin is the first to actualy CHANGE the BSP of a map and have positive results. Keep plugging away Talin, and eventually you'll get the hang of it.
well....so far it seems that the visible model can be edited...all we need now is the collision model. Is there some way to do a byte comparison of large portions of the map to find the same points for the collision model?, because they should have the same coords as the visible model. (also, having modeling without collision later would provide a great way to make secret areas in halo i.e. invisible bridge leading to invisible room or something like that) just a thought! 
btw, 64, this breakthrough is great....oh, and not to be pushy or anything, but what about a proggie XW that converts a txt file of hex to float?....dunno if thats too hard, ive never programed anything, but ill be working on figuring this out as well....w/ the collision model i mean. Ciao! 
btw, 64, this breakthrough is great....oh, and not to be pushy or anything, but what about a proggie XW that converts a txt file of hex to float?....dunno if thats too hard, ive never programed anything, but ill be working on figuring this out as well....w/ the collision model i mean. Ciao! Awesome stuff, I really think we can find out how to edit the collision model. 64, how the hell did you figure this out? Were you just looking through the lines of hex and noticed that the hex was actually float? How ever you did it you have opened the door for the all new game halo 1.5 (its between halo 1 and 2). Keep up the great work!
Grenadiac and BOLL tried this WAYYY back when... before HMT was around. They also had the problem with collision models - and yes, it was the XBOX maps that they tried this on... I asked Grenadiac a few weeks back about it. He said that they couldn't figure out where the collision data was stored, so they gave up on it... I will say, however, that with HMT v3.5, I think the modability of xbox maps will be further pushed. "The Void" proves this. just wait. full bsp mesh editing and collision editing will be around soon.... Either that, or wait for the HEK so we can reverse engineer that, and create proggies to convert between PC and xbox versions.... (I only wish I knew what the hell the difference in the model formats was for xbox and pc.... I HAD the friggin decoding source code at one point... I never thought to look and see what was different... perhaps the key was held in HME's source...)
Yep, I did all this months ago too, and ended up in the same situation.
Anyway, I'm picking it up again, so I figured I'd add to the discussion.
When you look at the level's model in hex it's helpful to set your hex editor to group data in "longs" (4 bytes) like this 661FA897, rather than "shorts", like this 661F A897. It just makes it easier to understand.
It's also helpful to set your hex editor to 8 columns, because each line of model data is 8 shorts long. afaik
The format of the data is like this: ###, ###, ## (vertices[xyz], normals, uv mapping)
I hope that made at least some sense. Here's how that would look in hex:
35F26D42 1533E1C2 D8ADDC3F 8CFF7C7E FF2FE0F3 F8FB7F0E 6073D63E C2C3EC3E
See what I mean? 8 longs (all floats), the first three of which are x, y & z coordinates, the "second three" are the normals (for shading) and the last two are the uv (texture) mapping.
Ok...
A good way to find a nice vertex to play with is to use SparkEdit to export the model of BG (or whatever level), open it up in Milkshape3D and select a vertex. Now go to Vertex > Manual Edit and select "Show only selected". This will show you the xyz coordinates of your vertex. Now go back to your hex editor and search for a "32bit float" with the same x value (you can also use the y or z value...doesn't matter). Keep in mind that Milkshape may add an extra # on the end of the coordinate. i.e. Halo shows 59.48653 and Ms3D shows 59.486530. So, when searching for that value you may need to change it a bit for the search to return what you're looking for.
Now, you might notice that when you searched for that value you found it more than once.
If it's very near the top of the file and has a bunch of similar longs around it then it's probably your model vertex.
If it's a little further down in the file & has a short next to it (like this: 35F26D42 1533E1C2 D8ADDC3F B10A0000) then it should be the matching collision model vertex. afaik
Now you can manually move that model vert (and others) around and make the level look differently...just like some of you have already been doing.
You can also change the coordinates of the collision model vertex, but the problem is that there is more to the collision models than that.
The way that they're put together makes it so that they don't behave the same way as a model. Moving the vertex up unfortunately won't make a hill. You may end up with a hole, or maybe just a "destabilized" spot, but probably not what you want.
When working with other collision models simply moving vertices didn't achieve the results I wanted.
With collision models for other objects (which are also BSPs) there is a bunch of other data besides the vertices, some of which is attributes of each plane in the BSP tree. This is what I have had to edit to really resize/reshape other collision models, and it may be the key to reshaping the landscape in the level BSP also.
At the moment though I'm not sure if I'm on the right track, and I don't know enough about the level BSP tree to know where the plane attributes are...or anything else besides the verts.
So, anyway...I hope some of that made sense, good luck to everyone who is studying this, and I'll make sure to post if I make any progress.
Anyway, I'm picking it up again, so I figured I'd add to the discussion.
When you look at the level's model in hex it's helpful to set your hex editor to group data in "longs" (4 bytes) like this 661FA897, rather than "shorts", like this 661F A897. It just makes it easier to understand.
It's also helpful to set your hex editor to 8 columns, because each line of model data is 8 shorts long. afaik
The format of the data is like this: ###, ###, ## (vertices[xyz], normals, uv mapping)
I hope that made at least some sense. Here's how that would look in hex:
35F26D42 1533E1C2 D8ADDC3F 8CFF7C7E FF2FE0F3 F8FB7F0E 6073D63E C2C3EC3E
See what I mean? 8 longs (all floats), the first three of which are x, y & z coordinates, the "second three" are the normals (for shading) and the last two are the uv (texture) mapping.
Ok...
A good way to find a nice vertex to play with is to use SparkEdit to export the model of BG (or whatever level), open it up in Milkshape3D and select a vertex. Now go to Vertex > Manual Edit and select "Show only selected". This will show you the xyz coordinates of your vertex. Now go back to your hex editor and search for a "32bit float" with the same x value (you can also use the y or z value...doesn't matter). Keep in mind that Milkshape may add an extra # on the end of the coordinate. i.e. Halo shows 59.48653 and Ms3D shows 59.486530. So, when searching for that value you may need to change it a bit for the search to return what you're looking for.
Now, you might notice that when you searched for that value you found it more than once.
If it's very near the top of the file and has a bunch of similar longs around it then it's probably your model vertex.
If it's a little further down in the file & has a short next to it (like this: 35F26D42 1533E1C2 D8ADDC3F B10A0000) then it should be the matching collision model vertex. afaik
Now you can manually move that model vert (and others) around and make the level look differently...just like some of you have already been doing.
You can also change the coordinates of the collision model vertex, but the problem is that there is more to the collision models than that.
The way that they're put together makes it so that they don't behave the same way as a model. Moving the vertex up unfortunately won't make a hill. You may end up with a hole, or maybe just a "destabilized" spot, but probably not what you want.
When working with other collision models simply moving vertices didn't achieve the results I wanted.
With collision models for other objects (which are also BSPs) there is a bunch of other data besides the vertices, some of which is attributes of each plane in the BSP tree. This is what I have had to edit to really resize/reshape other collision models, and it may be the key to reshaping the landscape in the level BSP also.
At the moment though I'm not sure if I'm on the right track, and I don't know enough about the level BSP tree to know where the plane attributes are...or anything else besides the verts.
So, anyway...I hope some of that made sense, good luck to everyone who is studying this, and I'll make sure to post if I make any progress.
Xorange, You have definetly summarized exactly what I have found out too. I beleive Grenadiac had a xbox bg bsp txt file at some point that had all the important hex converted to floats. I have a copy I will post it in the miscelaneous section. It should help you compare your work making the plates to the bsp.
Also, I was looking you tut on this plates and was a bit confused
What did the last two floats that you multiplied by 5 correlate too?
I wonder if that fellow GlassJaw has any input on this subject too?
Also, I was looking you tut on this plates and was a bit confused
What did the last two floats that you multiplied by 5 correlate too?
I wonder if that fellow GlassJaw has any input on this subject too?
Cool, yep, I have that BG BSP text file. I've taken a good look at it, but haven't yet had time to directly compare it to the cache.Talin64 wrote:Xorange, You have definetly summarized exactly what I have found out too. I beleive Grenadiac had a xbox bg bsp txt file at some point that had all the important hex converted to floats. I have a copy I will post it in the miscelaneous section. It should help you compare your work making the plates to the bsp.
Also, I was looking you tut on this plates and was a bit confused
What did the last two floats that you multiplied by 5 correlate too?
I wonder if that fellow GlassJaw has any input on this subject too?
Now I'd just like to find a hex editor that has a function to display data as floats, etc....in the main display, not just the data inspector.
Those last 2 floats were part of the "plane" attributes I mentioned in my previous post.
Take the tree_leafy_fallentrunk coll for example. (this is what I made the panel out of)
It's made up of 6 planes, each of which have 4 attributes (all floats): two rotations, bounce/attach/(pass-through?) & "surface".
Note: The rotation coordinates are relative to the initial rotation of the plane (...that should make sense in a moment)
(I might be visualizing the axes in Halo differently than other people, so sorry if my "yaw" is your "roll", or anything like that. Hopefully it'll still make sense.)
So, here's what the plane attributes look like for tree_leafy_fallentrunk:
69DF593C 00000000 35FA7F3F 87BF863E
CBBE8BB4 CF1FA733 000080BF F8627B3E
998D643C A0F97FBF DB4900B4 D0C1933E
942BBABB F1FE7F3F F9147E33 649C8C3E
000080BF 00000000 0E0AF334 95EBAC3F
0000803F B73AEC28 DA6A82B4 99EBAC3F
...and here's my translation:
+Z plane (yaw, pitch, bounce/attach, surface)
-Z plane (yaw, pitch, bounce/attach, surface)
+Y plane (roll, bounce/attach, pitch, surface)
-Y plane (roll, bounce/attach, pitch, surface)
+X plane (bounce/attach, roll, yaw, surface)
-X plane (bounce/attach, roll, yaw, surface)
See, 6 planes (6 data packets), 4 attributes (4 floats).....alright...
So, the rotations are pretty much self explanatory, so is the bounce/attach attribute.
By modifying that attribute you can also achieve various degrees of "pass-through", but I'm not sure if that is what was intended.
Anyway, to the point, the "surface" attribute is basically the distance of the panel from the center of the axes.
When I modified the tree to make the panel I moved the verts out, which achieved part of what i wanted, then moved each Y plane out to match the verts. That's what those two floats were.
Hey, Xorange
Well I have been giving this a lot of thought and research over the past few days and I believe I have come up with an answer to the collision model problem. Because we are not adding anything to the collision model we only have to deal with blocks 2 and 8 of the collision model.
Berkano Said that the block 8 was all the points in the model which are identical to the points for the graphics. I have already updated both points, the graphics one and the collision one. However in block two all of the planes are described. This is much harder to update. Since these planes are mostly non axial planes meaning they are not parellel to any axis system they are harder to calculate. I beleive that the planes are described by a normal vector and a distane. I beleive Grenadiac thinks this too. He said that some some planes are shared for instance the bloodgulch base Top. I don't think this will be an issue if we are only changing the terrain. The plane formats are D, X , Y , Z . The xyz is in the form of a normal vector meaning that x^2 + y^2 + z^2 = 1
Already went through one to figure that much out.
These are not fun to calculate out. You definetly need to write a program. The rotations are in this format -1> x < 1.
to find a normall vector you need three points on the plane ABC.
Then make two vectors AB and CB. take the cross product of those. and that should give you the normal vector. Now you can calculate out the rotations. The distance is a little more invloved. You need the distance from 0,0,0 to the plane along the normal vector. This is a lot more fun.
A program definetly needs to be written. I am willing to help but, I can only write in c++ or maybe vba. I think you would definetly need a gui interface like sparkedit. If grenadiac wants put this into sparkedit. I will write the functions he will need. However I think there is some more research that needs to be done. We need to know which points go with which plane and so forth. Give it some thought Grenadiac. Everyone would love it. The noobs would love you. So, Xorange what are your thought do you think this is possible?
Bye Talin64
Well I have been giving this a lot of thought and research over the past few days and I believe I have come up with an answer to the collision model problem. Because we are not adding anything to the collision model we only have to deal with blocks 2 and 8 of the collision model.
Berkano Said that the block 8 was all the points in the model which are identical to the points for the graphics. I have already updated both points, the graphics one and the collision one. However in block two all of the planes are described. This is much harder to update. Since these planes are mostly non axial planes meaning they are not parellel to any axis system they are harder to calculate. I beleive that the planes are described by a normal vector and a distane. I beleive Grenadiac thinks this too. He said that some some planes are shared for instance the bloodgulch base Top. I don't think this will be an issue if we are only changing the terrain. The plane formats are D, X , Y , Z . The xyz is in the form of a normal vector meaning that x^2 + y^2 + z^2 = 1
Already went through one to figure that much out.
These are not fun to calculate out. You definetly need to write a program. The rotations are in this format -1> x < 1.
to find a normall vector you need three points on the plane ABC.
Then make two vectors AB and CB. take the cross product of those. and that should give you the normal vector. Now you can calculate out the rotations. The distance is a little more invloved. You need the distance from 0,0,0 to the plane along the normal vector. This is a lot more fun.
A program definetly needs to be written. I am willing to help but, I can only write in c++ or maybe vba. I think you would definetly need a gui interface like sparkedit. If grenadiac wants put this into sparkedit. I will write the functions he will need. However I think there is some more research that needs to be done. We need to know which points go with which plane and so forth. Give it some thought Grenadiac. Everyone would love it. The noobs would love you. So, Xorange what are your thought do you think this is possible?
Bye Talin64
-
silencer88
- Posts: 303
- Joined: Fri Oct 24, 2003 10:18 am
do you know how awesome it would be to have a program that did all this for us...being able to change the collision and surface points in a program would be soooo sweeet... it would basically allow map creation
i think the first thing that people should try to do (i would but i have like no time) is change the bases in bg to be taller than they are now since all of those points should have a point in common (am i right?) which would just need to be changed
i think the first thing that people should try to do (i would but i have like no time) is change the bases in bg to be taller than they are now since all of those points should have a point in common (am i right?) which would just need to be changed
Hmm...I think I get everything you're saying...Talin64 wrote:Hey, Xorange
Well I have been giving this a lot of thought and research over the past few days and I believe I have come up with an answer to the collision model problem. Because we are not adding anything to the collision model we only have to deal with blocks 2 and 8 of the collision model.
Berkano Said that the block 8 was all the points in the model which are identical to the points for the graphics. I have already updated both points, the graphics one and the collision one. However in block two all of the planes are described. This is much harder to update. Since these planes are mostly non axial planes meaning they are not parellel to any axis system they are harder to calculate. I beleive that the planes are described by a normal vector and a distane. I beleive Grenadiac thinks this too. He said that some some planes are shared for instance the bloodgulch base Top. I don't think this will be an issue if we are only changing the terrain. The plane formats are D, X , Y , Z . The xyz is in the form of a normal vector meaning that x^2 + y^2 + z^2 = 1
Already went through one to figure that much out.
These are not fun to calculate out. You definetly need to write a program. The rotations are in this format -1> x < 1.
to find a normall vector you need three points on the plane ABC.
Then make two vectors AB and CB. take the cross product of those. and that should give you the normal vector. Now you can calculate out the rotations. The distance is a little more invloved. You need the distance from 0,0,0 to the plane along the normal vector. This is a lot more fun.
A program definetly needs to be written. I am willing to help but, I can only write in c++ or maybe vba. I think you would definetly need a gui interface like sparkedit. If grenadiac wants put this into sparkedit. I will write the functions he will need. However I think there is some more research that needs to be done. We need to know which points go with which plane and so forth. Give it some thought Grenadiac. Everyone would love it. The noobs would love you. So, Xorange what are your thought do you think this is possible?
Bye Talin64
Well, I'm looking at what I think is the "surface distance" and rotations for each plane.
I agree that the planes are non-axial, and that their surface distance must be from 0 to the plane's normal.
I've been trying to identify a plane, calculate it's normal and match it to a surface, but no luck.
I have used your algorithm and several others to try to calculate the normal, but I haven't gotten anything that I think is correct.
I might be doing it wrong...
I think this is the way to go though.
We just need to be able to match faces to planes.
I've played with what I believe is the surface distance, and I've played with the vertices, but I haven't modified both at the same time, seeing as how I don't really know where the verts need to be to match the surface.
If the verts aren't moved to the proper spot, adjusting the surface doesn't have the right effect.
Granted, the number I'm changing may not even be the surface, but I think it is...and it's next to a bunch of numbers that appear to be rotations.
Well, I'm also back to working on other collision models, but I'll be working on this too....so, I'll post any new progress.
I'm still VERY, VERY interested in modifying the existing landscape.
We haven't really quite figured that out.mrhyperpenguin wrote:can someone recap on how to do this?
That's the point of this thread. We're still researching it.
So far it's pretty easy to modify the model of the level, but there's not much point until we can modify the bsp, i.e. the collision model.
That's pretty much what we're working on now.
-
mrhyperpenguin
- Posts: 357
- Joined: Sun Mar 07, 2004 4:34 pm
|
|
|
Xorange,
I have figured out the Plane format with a little help from excel.
It is setup like this.
offset: D1, x2, y2, z2
offset: D2, x3, y3, z3
plane 2 is defined by d2, x2, y2 z2
I have checked 9 planes with excel and the format has worked out everytime.
I was able to find the points that go along with each plane by comparing sparkedit to Autocad and getting the points directly from cad.
I will now try to find a better way.
Bye Talin64
mrhyperpenguin: We are trying to edit the bsp graphically as well as the collision model. Look at the bsp txt file posted in the files misc. section it has crucial hex converted to float.
I have figured out the Plane format with a little help from excel.
It is setup like this.
offset: D1, x2, y2, z2
offset: D2, x3, y3, z3
plane 2 is defined by d2, x2, y2 z2
I have checked 9 planes with excel and the format has worked out everytime.
I was able to find the points that go along with each plane by comparing sparkedit to Autocad and getting the points directly from cad.
I will now try to find a better way.
Bye Talin64
mrhyperpenguin: We are trying to edit the bsp graphically as well as the collision model. Look at the bsp txt file posted in the files misc. section it has crucial hex converted to float.
Hmm...I'm not quite sure what you mean.Talin64 wrote:Xorange,
I have figured out the Plane format with a little help from excel.
It is setup like this.
offset: D1, x2, y2, z2
offset: D2, x3, y3, z3
plane 2 is defined by d2, x2, y2 z2
I have checked 9 planes with excel and the format has worked out everytime.
I was able to find the points that go along with each plane by comparing sparkedit to Autocad and getting the points directly from cad.
I will now try to find a better way.
Bye Talin64
Could you explain it a bit more, or differently?
If you could give me an offset to one of the packets of data you're looking at and an example of your calculation, based on those numbers, that would be really cool! (If you could send me your spreadsheet that'd be cool too, but it's ok if you don't want to.)
I think we're looking at the same thing, but there's something I'm missing about what calculation you're doing and which numbers you are using.
Thanks! ^_^