CMP to SUR Conversion Tests
-
**@ Adoxa, I collect FL programs, never know when they may be of use. Didn’t know you included the source, I will definately take a look at it. No offense intended, I just prefer point and click type programs over CLI programs, just a personal choice….
Good find on the offset, looking at the layout of the offsets puts it as the following.
Vertex nn nn xx xx
Offset xx xx nn nn
Final face list flag is bit 16 of the Offset@ ST, the number you are looking at is a pointer to the bits section, for example from the bw_freighter.sur you listed…
** Face Base Offset 20960 0x000051E0 #2 Vertices List Offset 400 0x00000190 + 0x000051E0 = 0x00005370 CRC/Pointer 656 0x00000290 -> Bits pointer 0x00000290 + 0x000051E0 = 0x00005470 Type 5 0x00000005 Referenced Vertices Cnt 39 0x00000027 Unused 0 0x00000000 Face Cnt 24 0x00000018Points to…
**************** 0x00005470 ** Bits #0 0, 0x00000000 Sibling offset 56 0x00000038 : 1 0x00000001 Triangle offset = 656 0x00000290 Org 0xFFFFFD70 CX -0.329752 CY 0.025628 CZ 0.818943 Radius 3.353551 Color ABGR 0x00BD319DAs you notice, the ‘Triangle Offset’ points back to the face list.**
-
Aha! Thanks Lancer, now light begins to dawn!
So there is only one “physical” mesh of the shield bubble (or wing+weapon) sur, e.g. “HpMount” (f00fb9de) and the second shield bubble is using the same set of vertices as the first shield bubble mesh, by using the offset 00001b10 (which should be where the mesh pointers are located), is this right?
But the wing+weapon sur is defined using only the offset, twice, but likewise with only one set of vertices? (By the way - where are the vertices for that first mesh listed?)
If so then we still need to find a way to make and export these sur entries correctly with their correct structure/format from MilkShape to get complete surs. Is the type code different for these then?
(Yes! Type = 5 for these!)
However what of the anomaly of the stiletto, where one wing+weapon sur has offset 00000290 and its identical duplicate has the offset 00000270?
Is this an error in that sur file?
It looks correct when imported into MilkShape, although only one of them is in the correct location over the wing and weapon, and the other is near the origin.
Good work guys, sorry I can’t be of real help to you but I will keep clarifying with you when I fail to understand.
Thanks for replying to my meanderings!
-
What is the filename of that ship?
-
The stiletto is SHIPS\BORDER_WORLD\BW_ELITE\bw_elite.sur
-
**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 0x00D63577Which covers ‘bw_star_wing01_lod1’ and ‘HpWeapon04’.
I found multiple entries for 0x0270, same thing, points to a bits entry.**
-
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?
-
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.
-
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?
-
**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’** -
Ok, got that, I’ll investigate when I’m more awake, thanks.
-
**@ 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.**
-
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!
-
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.
-
NEXT STEP… .dfm’s
lol… yeah im cruel
-
**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…**
-
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
-
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.
-
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…
