CMP to SUR Conversion Tests

LancerSolurus

**I found only 1 instance of 0x0290 in that file, the same, points to the bits entry.

** Face Base Offset 20720 0x000050F0 

#2
Vertices List Offset 400 0x00000190 + 0x000050F0 = 0x00005280
CRC/Pointer 656 0x00000290 -> Bits pointer 0x00000290 + 0x000050F0 = 0x00005380
Type 5 0x00000005
Referenced Vertices Cnt 39 0x00000027
Unused 0 0x00000000
Face Cnt 24 0x00000018

**************** 0x00005380
** Bits #0 0, 0x00000000
Sibling offset 56 0x00000038 : 1 0x00000001
Triangle offset = 656 0x00000290 Org 0xFFFFFD70
CX 0.011413	CY 0.154522	CZ -1.029845
Radius 3.257238
Color ABGR 0x00D63577

Which covers ‘bw_star_wing01_lod1’ and ‘HpWeapon04’.

I found multiple entries for 0x0270, same thing, points to a bits entry.**

StarTrader

Yes, the possible problem is exactly this, that I would expect to find 2 x 00000290 meshes and 2 x 00000270 meshes.

Inthe Stiletto one of the starboard wing+weapon surs is 00000270 and its duplicate is 00000290, and the port wing+weapon is 2 x 00000270, so there are 1 x 00000290 and 3 x 00000270 surs in that file. I just spotted that 00000290 has 39 verts and 00000270 has 36.

The surs are mirror images, so is there maybe another way to use the same mesh and specify that it is in reverse order?

I just also confirmed that the dromedary (bw_freighter) has only one 00000270 and one 00000290. So the Stiletto may well have a bad sur file if it needs only 1 x 00000290 and 1 x 00000270?

LancerSolurus

Well the number is simply an offset so it can point past the vertices and face list. Just because it has more of them doesn’t mean it’s bad, the 270s and 290s are totally different parts of the sur file and have separate meshes.

StarTrader

Oh dear - so I didn’t understand then - each 00000270 has a separate physical mesh in the sur file?

So do we know why these are using an offset instead of a proper mesh name like other sur parts?

And - where is this offset measured from please?

LancerSolurus

**Look at the code section, it’s a relative pointer…

CRC/Pointer 656 0x00000290 -> Bits pointer 0x00000290 + 0x000050F0 = 0x00005380
0x0290 is the offset
0x50f0 is the start of that face list, as in ‘** Face Base Offset 20720 0x000050F0’**

StarTrader

Ok, got that, I’ll investigate when I’m more awake, thanks.

LancerSolurus

**@ Adoxa, thanks for your help, what you found in the FL source has been invaluable. At this point only 2 parts are left to be figured out…

The index in the face list and the color value in the bits section…

New findings tonight…

The face type 5 is the clincher, it appears to link all of the various parts of the sur section together. It jumps all over the vertex list and has a bits tree set aside just for it. I will be working on building a compiler just for that part tommorrow and see if it starts taking hits on all of the subparts of the root sur.

The bits tree for the type 5 face list starts with a link to that face list ending with the final bits section, it’s interleaved with all of the other bits sections. Also it’s always the first bits section if it is present.**

FriendlyFire

I have to say that your discoveries sound extremely exciting! I hope you can finally crack open this elusive format… That would be an exceptional achievement for sure.

Thanks for all you’ve both done so far!

? Offline

Right, enough messing around, when is this going to be finished? Some of us have mods to complete rofl

Joking aside, doing a sterling job chaps, can’t wait for a working version. Just wish i knew what you were all on about…

Sushi

FriendlyFire wrote:
I have to say that your discoveries sound extremely exciting! I hope you can finally crack open this elusive format… That would be an exceptional achievement for sure.

Thanks for all you’ve both done so far!

+1, totally agree. When you guys figure this out, it’s going to be a huge leap forward in mod development. I’m getting giddy with anticipation.

Xarian_Prime

NEXT STEP… .dfm’s

lol… yeah im cruel

LancerSolurus

**Actually the DFM format was completed some time ago (3+ months ago), the SUR format is much more complicated than that. Only thing I have left on DFM is exporting it to a format that can be loaded by Milkshape or another 3d editing program.

Thanks for both of us, Adoxa has helped me quite a bit, he has kept me in check and I appreciate it alot! Alot more help than I had when I was doing the ALE format which took nearly 5 months to figure out by pure guesswork…**

adoxa

I’ve already told you it’s not RGB, but another scale for the radius. Using your notation, it’s something like:

...
radius1 = Radius / 250
if (radius1 * R + something <= abs(CX)) then exit
if (radius1 * G + something <= abs(CY)) then exit
if (radius1 * B + something <= abs(CZ)) then exit
...
```That's pretty much all I can tell you, so I'll leave the rest to you. Oh, I'll just clarify some things.

Next Surface Offset 26836 0x000068D4 + 0x00000038 = 0x0000690C

Dupl Surface Offset 26836 0x000068D4

RimShot

hey guys, just to let you know there is +1 who appreciates all the efforts put into this, keep it up!

StarTrader

Well done guys, keep up the momentum please!

And… Yeh…

The Hills Have Eyes!!

(And so do all the skirting boards and every nook and cranny!!)

PS - sorry, tried but still unable to find the 3 unidentified hashcodes.

adoxa

Yeah, I got lucky with the other unreferenced ones. Since XGUN existed, I was able to eventually stumble upon SGUN, MGUN and LGUN (same for XBARREL). Presumably these are small, medium, large and extra large.

I’ve made one final revision to SurDump. The main triangle flag is only one bit and the “size2” and type 5 “size” values have been renamed to “bits ofs”. Now it’s up to LS (and other interested parties) to actually do something with it…

LancerSolurus

**I did a raw string dump of all of the exes,dlls,cmps,mats,txms,3dbs & utfs in FL, converted them to CRC values. No luck. It is the same routine I used to find those missing sound hashes used in FLEC. IMO its a sur that didn’t get remade when they made a change to the Border World models. A binary search only turned up a relevant CRC in those specific sur files. It could also be dummy nodes like those used for the sur splicer, as far I can tell, they don’t exist anywhere else…

Thanks Adoxa, BTW, like the format on the output files the SurDump makes, nice and clean. Nice touch on the Offset in the face list ;)**

LancerSolurus

**OK, one value left to figure out, the colors in the bits section…

The type 5 face list acts like a sort of shrink wrap on the mesh. It doesn’t take hits but it links all of a specific parts of the sur together (as in the Root sur part) by having faces that attach to each mesh. Look at the Liberty battleship for example. In that it looks like the ship is inside of a plastic bag but when you shoot it u don’t hit the bag.

I now have an opposite face calculation routine completed. It was listed in the face list as ‘Index’ a few pages back. How this works is that I create a normalized normal vector for each face then do a non-squared dot product of the normal vector between faces. The one with the largest negative dot product (that means it facing away from that face by more than 90 degrees) is selected to be the opposite face (excluding the same face). Hehe, I’m sure this sounds like Greek to most of ya so don’t worry about it, I have the math part covered.

So at this point there is only 1 part left to crack, once thats done then I will post a fully updated sur format file…**

FriendlyFire

LS, you may want to read one of adoxa’s reply a little up… He says they’re not color bits

LancerSolurus

True, they aren’t colors, just simply referring to them as I listed them a few pages back. Too bad it isn’t that simple