Here is the update you guys wanted.
It would be great if someone could plug in the new planes and vectors for the hill to see if it works
http://files.halomods.com/viewtopic.php?p=57229#57229
bye Talin64
xbox bsp editing
Talin64, you freakin' rock!! 
Thank you! That was exactly what i needed.
No offense, but I didn't quite understand your spreadsheet this morning.
It was totally accurate & very comprehensive, I just wasn't quite up to par yet.
So, I spent all day reading a bunch of vector tutorials & stuff, and wrote my own spreadsheet
using your results & formulas to check my work along the way.
Now it all makes sense!
The only thing I straight ripped from your spreadsheet was the calculation for the distance.
I found examples & explanations of all the other formulas online, but
for some reason I couldn't find an example of that one anywhere.
How did you know how to calculate that?
Btw, do you know why the distance comes out a little off?...very, very slightly off....probably a negligible amount.
In case you're not sure what I'm talking about it's the formula in cell L6 of your spreadsheet.
The value for the first one (unchanged) is: 1.223746...which would round to about 1.224...in the cache it's 1.217.
It's probably just because of a slight difference in the base numbers used for the calculation.
I wonder if a difference that small would cause a hole in the bsp...
Well, when I finish my spreadsheet I will also share with you guys.
Thank you! That was exactly what i needed.
No offense, but I didn't quite understand your spreadsheet this morning.
It was totally accurate & very comprehensive, I just wasn't quite up to par yet.
So, I spent all day reading a bunch of vector tutorials & stuff, and wrote my own spreadsheet
using your results & formulas to check my work along the way.
Now it all makes sense!
The only thing I straight ripped from your spreadsheet was the calculation for the distance.
I found examples & explanations of all the other formulas online, but
for some reason I couldn't find an example of that one anywhere.
How did you know how to calculate that?
Btw, do you know why the distance comes out a little off?...very, very slightly off....probably a negligible amount.
In case you're not sure what I'm talking about it's the formula in cell L6 of your spreadsheet.
The value for the first one (unchanged) is: 1.223746...which would round to about 1.224...in the cache it's 1.217.
It's probably just because of a slight difference in the base numbers used for the calculation.
I wonder if a difference that small would cause a hole in the bsp...
Well, when I finish my spreadsheet I will also share with you guys.
Xorange-
You are right there is a little error in the Excel file
It is a rounding error. The points are taken from the original bsp txt file wich only go out to three significant digits.
I took it a step further last night and converted all the new floats to hex put it back into my cache file and guess what happened.
It was very dicouraging I think those rounding errors become a very big problem. The collision model just didn't work right I would start walking up the hill and then fell through or just fall through right when I got there.
I think the theory works but I didn't have accurate enough points. I believe the planes were not alligned correctly because of this.
I think the next step is to put in the points vertices again into Excel but take them directly form the cache file and covert them to float keeping as many significant digits as possible. This should clean up the Collision model.
In the excel file there are numbers in front of each point.
111 is the main point and it has the offset given from my last post.
112 is the next point down....
If you are up for it. Grab the other points and try and see if you can get it to work.
I think if this works then It would be best to try to collaborate further and write a Program to do this. Maybe we can get some more people to help us. I am not very good at programming but this is a major breakthrough. If you ask me. If we could get Grenadiac interested in pursuing this also we could get this thing figured out even faster.
bye- Talin 64
p.s. That one formula you couldn't find is out there somwhere, I didn't create it. Some of those formulas were taken directly from my Calculas book.
By the way I am not going to poost a movie or pic or ppf on friday becasue it doesn't work yet.
You are right there is a little error in the Excel file
It is a rounding error. The points are taken from the original bsp txt file wich only go out to three significant digits.
I took it a step further last night and converted all the new floats to hex put it back into my cache file and guess what happened.
It was very dicouraging I think those rounding errors become a very big problem. The collision model just didn't work right I would start walking up the hill and then fell through or just fall through right when I got there.
I think the theory works but I didn't have accurate enough points. I believe the planes were not alligned correctly because of this.
I think the next step is to put in the points vertices again into Excel but take them directly form the cache file and covert them to float keeping as many significant digits as possible. This should clean up the Collision model.
In the excel file there are numbers in front of each point.
111 is the main point and it has the offset given from my last post.
112 is the next point down....
If you are up for it. Grab the other points and try and see if you can get it to work.
I think if this works then It would be best to try to collaborate further and write a Program to do this. Maybe we can get some more people to help us. I am not very good at programming but this is a major breakthrough. If you ask me. If we could get Grenadiac interested in pursuing this also we could get this thing figured out even faster.
bye- Talin 64
p.s. That one formula you couldn't find is out there somwhere, I didn't create it. Some of those formulas were taken directly from my Calculas book.
By the way I am not going to poost a movie or pic or ppf on friday becasue it doesn't work yet.
Xorange-
Check this stuff out it is very helpful.
I found this intersting post and
http://www.gearboxsoftware.com/forums/s ... t=all&vc=1
and Grenadiac bsp tut
http://www.halomods.com/users/grenadiac/bsp_tut.zip
Check this stuff out it is very helpful.
I found this intersting post and
http://www.gearboxsoftware.com/forums/s ... t=all&vc=1
and Grenadiac bsp tut
http://www.halomods.com/users/grenadiac/bsp_tut.zip
Hmm, so it does make a difference.Talin64 wrote:Xorange-
You are right there is a little error in the Excel file
It is a rounding error. The points are taken from the original bsp txt file wich only go out to three significant digits.
I took it a step further last night and converted all the new floats to hex put it back into my cache file and guess what happened.
It was very dicouraging I think those rounding errors become a very big problem. The collision model just didn't work right I would start walking up the hill and then fell through or just fall through right when I got there.
I think the theory works but I didn't have accurate enough points. I believe the planes were not alligned correctly because of this.
I think the next step is to put in the points vertices again into Excel but take them directly form the cache file and covert them to float keeping as many significant digits as possible. This should clean up the Collision model.
In the excel file there are numbers in front of each point.
111 is the main point and it has the offset given from my last post.
112 is the next point down....
If you are up for it. Grab the other points and try and see if you can get it to work.
I think if this works then It would be best to try to collaborate further and write a Program to do this. Maybe we can get some more people to help us. I am not very good at programming but this is a major breakthrough. If you ask me. If we could get Grenadiac interested in pursuing this also we could get this thing figured out even faster.
bye- Talin 64
p.s. That one formula you couldn't find is out there somwhere, I didn't create it. Some of those formulas were taken directly from my Calculas book.
By the way I am not going to poost a movie or pic or ppf on friday becasue it doesn't work yet.
I suppose it would.
When trying to modify a scenery collision model to match it's model you have to do it absolutely perfectly or there will be holes.
...very easy to fuck up.
So, what I'm working on right now is trying to make a data sheet, to add to my spreadsheet, that contains all the verts, in the right format & with all their digits.
That way on the calculator sheet we can just reference the verts on the data sheet, instead of having to type them all in.
The problem is that I'm having an extremely hard time finding a program (hex editor, base converter, whatever) that will show the verts as floats.
I mean, hex workshop (what I use) has a data inspector of course, which shows the floats, but what I need is a program that will display or export a file similar to the bg_bsp_only.txt that we have....only all the digits.
I can't find anything anywhere. I have pretty much every single hex editor in existence and none of them will do what I need it to do.
Anyway, if you know of an app that will display hex/dec/bin numbers as 32bit floating point numbers that would be perfect.
I've already added a data sheet containing all the planes, but it's not really formatted like I want it. Besides, it's really just for reference atm, unless I can think of some interesting way to incorporate it into the calculator.
Btw, where did you get the 111, 112 & 113 from?
I couldn't find the offset that you mentioned was in a previous post.
Yeah, I think that once we get this all worked out it would probably be pretty easy for a good programmer to look at our research and put together an app that could just open the cache, read all the verts & do all the work.
If Grenadiac were so inclined possibly he could make SparkEdit capable of modifying the model/collision model meshes & recalc all the planes.
Unfortunately I'm only an aspiring programmer. heh
Thanks for those links.
I read that BSP tut a while back. Too bad it doesn't touch on the collision portion.
...and that is an interesting thread. They're headed in the right direction.
Hey when youre putting youre verts etc. into excel just right click on the colum at the top and hit cell formatting, change it to text instead of normal, and it will leave them how they are. Good luck
I am still learning C++, the only prog ive written is one to read the CLuis Dependency and reflexive dats and converts the reflexives, but i will take a shot at the program. now that i understand it a bit more at least, if someone could send a in depth explenation of what you want, and how you do it etc. I am also learning OpenGL, but i cant program in it yet so a map editor etc. is out of the question.
I am still learning C++, the only prog ive written is one to read the CLuis Dependency and reflexive dats and converts the reflexives, but i will take a shot at the program. now that i understand it a bit more at least, if someone could send a in depth explenation of what you want, and how you do it etc. I am also learning OpenGL, but i cant program in it yet so a map editor etc. is out of the question.
just here to say
good job guys, keep up the good work, hopefully your will crack this bitch soon. I cant wait till we can start making new MP maps. If you need some resources I might have something, but not much. Good luck.
Ok, when I'm done with this spreadsheet it will practically be an application. heh
I now have a great data sheet going, not only showing all the verts as floats with all their digits, but also arranged into triangles & sorted!
This makes it so that when you have identified a face in the model that you'd like to move, it only takes about 30 seconds to identify all the faces that are connected & thus, planes that need to be changed.
Unfortunately I still have a small problem where some of the faces in my data do not have the verts listed in the right order, which influences the results, so I've got a bit more work to do on that.
I haven't tested this much yet, but from one test I found that performing the calculation with the vertices in a different order returned the same result, only negative rather than positive.
I've kind of taken this at face value & assume it means that the vertices definitely need to be in the same order that they are in the indices (triangle strips) to accurately return a result that will match the planes in the cache file.
Well anyway, once I'm done with this sheet I'm going to reformat the calculator sheet and make it so it references EVERY face on the other sheet.
That way we won't need to manually enter ANY verts, as they will all be auto-populated for us...and every plane will be precalculated.
All you will need to do is to determine what changes you want to make to individual verts (in a modeling app), just plug the new vert coordinates into the calc, then write the new vert coords & plane results to the cache.
...and I'm trying to come up with a way to make this even easier, if possible.
I now have a great data sheet going, not only showing all the verts as floats with all their digits, but also arranged into triangles & sorted!
This makes it so that when you have identified a face in the model that you'd like to move, it only takes about 30 seconds to identify all the faces that are connected & thus, planes that need to be changed.
Unfortunately I still have a small problem where some of the faces in my data do not have the verts listed in the right order, which influences the results, so I've got a bit more work to do on that.
I haven't tested this much yet, but from one test I found that performing the calculation with the vertices in a different order returned the same result, only negative rather than positive.
I've kind of taken this at face value & assume it means that the vertices definitely need to be in the same order that they are in the indices (triangle strips) to accurately return a result that will match the planes in the cache file.
Well anyway, once I'm done with this sheet I'm going to reformat the calculator sheet and make it so it references EVERY face on the other sheet.
That way we won't need to manually enter ANY verts, as they will all be auto-populated for us...and every plane will be precalculated.
All you will need to do is to determine what changes you want to make to individual verts (in a modeling app), just plug the new vert coordinates into the calc, then write the new vert coords & plane results to the cache.
...and I'm trying to come up with a way to make this even easier, if possible.
For future referance (after you awesome guys figure this out 
): I was playing bg ctf today and i noticed that there are also values for how bright a given model should be at at any location. Its just that I always thought there was only collision and bsp to a map and i noticed a whole new demention. Probably isnt any help but thought i should throw it out there.
): I was playing bg ctf today and i noticed that there are also values for how bright a given model should be at at any location. Its just that I always thought there was only collision and bsp to a map and i noticed a whole new demention. Probably isnt any help but thought i should throw it out there.-
silencer88
- Posts: 303
- Joined: Fri Oct 24, 2003 10:18 am
Well, yeah...we probably should do some more testing.Talin64 wrote:Xorange-
I am a little worried that we haven't tested the collsion model. I think we need to make sure that the reason it didn't work the first time was because of rounding errors.
Bye- Talin64
I've double-checked all the formulas and the reason that the results have been off isn't due to rounding but is due to the fact that our original vertex coordinates are slightly off.
I haven't done much actual testing yet because I want my spreadsheet to be perfect, but I'm kind of stuck on the same problem as before.
I have a good data sheet, showing all the verts, and I got the faces in the right order, but now it's back to the fact that I still don't have all the digits.
Well, what I did was to import the bloodgulch.obj into Milkshape3D, then exported as .RAW. Almost all model file formats are just ascii, so I tested them all and RAW was the only one that listed the verts in sets of 3 (triangles) instead of just listing the verts & the indices.
Anyway, that's how I got all the verts, but the problem is that when you use Sparkedit to export an obj of the level it only goes to 8 or 9 digits, and some of the verts use more digits!...so the results are very, very slightly off, which as we've learned will most likely make a difference.
So, basically, the only good way to get the vert coords for the data sheet is to pull them straight from the cache file...but I still can't find a program that will display hex numbers as floats. aarrgghh!
I wish I could program.
I'm really quite determined to finish this because once I'm done it will make the whole process a lot easier, and make it very easy for someone, like zero_cool, to understand the process enough to write an app.
So...the only thing I still need is a program that will read a file as hex and export as floats, using ALL possible digits.
It seems like something that would be easy to find...but apparently not.
Can anyone help?
-
XBOX War3z
- Posts: 49
- Joined: Fri Sep 26, 2003 12:26 pm
made this a long time agoo:
Hex To Float (simple dos program):
enter the hex as 0x12345678 and it will show your float
it only takes one value so you'll have to open the app again everytime
but if anyone is interesed it's made in c++ and I can give you the source
anyways here it is http://users.pandora.be/-_X_-/HexToFloat.rar
Hex To Float (simple dos program):
enter the hex as 0x12345678 and it will show your float
it only takes one value so you'll have to open the app again everytime
but if anyone is interesed it's made in c++ and I can give you the source
anyways here it is http://users.pandora.be/-_X_-/HexToFloat.rar
Hey, thanks XBOX War3ez, I do have that though.XBOX War3z wrote:made this a long time agoo:
Hex To Float (simple dos program):
enter the hex as 0x12345678 and it will show your float
it only takes one value so you'll have to open the app again everytime
but if anyone is interesed it's made in c++ and I can give you the source
anyways here it is http://users.pandora.be/-_X_-/HexToFloat.rar
That is a handy program & it's almost exactly what I need.
How much of a pain would it be to modify that program to use a hex file as input and export a file of floats, using 10 digits for each number?
If you could modify it for me that'd be really cool, but if not I would appreciate the source!
Thanks!
Xorange-
If you are still interested in this little project with HEK out and all. I am working on some code based on Xhzjang Verfilter.cpp to grab the points and export them to a txt file as a high precision float. I will post the code, and the txt file with the points and the exe when it is done. How is your progress coming along? I wanted to know how did you get the plane points in excel. I could write a program to pull out the plane points from the cache file if needed. Did you get a collision model working yet?
bye, Talin64
If you are still interested in this little project with HEK out and all. I am working on some code based on Xhzjang Verfilter.cpp to grab the points and export them to a txt file as a high precision float. I will post the code, and the txt file with the points and the exe when it is done. How is your progress coming along? I wanted to know how did you get the plane points in excel. I could write a program to pull out the plane points from the cache file if needed. Did you get a collision model working yet?
bye, Talin64
-Xorange
Here is the code,txt,exe, and updated excel files
havent had a chance to try out the new collision planes yet.
http://files.halomods.com/viewtopic.php?t=6070
I would love to see what you've been working on
bye, Talin64
the exe file should work on any bg map just make sure you put in cache003.map and not just cache003. The map needs to be in the same directory
-zero_cool
This program might get you started in the right direction.
Here is the code,txt,exe, and updated excel files
havent had a chance to try out the new collision planes yet.
http://files.halomods.com/viewtopic.php?t=6070
I would love to see what you've been working on
bye, Talin64
the exe file should work on any bg map just make sure you put in cache003.map and not just cache003. The map needs to be in the same directory
-zero_cool
This program might get you started in the right direction.