CMP to SUR Conversion Tests
-
**Yeah, the bit offset is wrong since I did not do a subtraction on it. Actually it is a 7 bit offset, 128 to 255 is negative, 0 to 127 is positive (bit 8 is the sign). Since I am the only person to see it until the previous post I didn’t bother with converting it to the proper number….
I just checked, all 3 of those entries are not part of the standard cmp node entries in any vanilla ship, I am getting an ‘unknown’ value on those 3. A very interesting discovery. I will run a full decompilation on every cmp & 3db file in FL tommorrow to see if it pops up somewhere else. Also since it could be a naming difference in a Fix, Rev, Pris or Sphere object name, I will check those as well on those specific ships. My decompiler only pulled the node names, not the Cmpnd info…
Good catch, if you want, I can post the string list for every node name if you want it for your sur decompiler, I simply build the crc list as I load them.**
-
Erm… sorry to rain on your parade guys…
You haven’t picked up the duplicate sur parts that cover the hull parts and (wings+weapons) parts. These exist in every standard FL ship, and have hashcodes like 00000290, 00000270, 00001b10, 000018d0, 00001e10. The easy ones are the 00001b10, 000018d0 and 00001e10 which are the shield bubble duplicates, and usually these have the “4-digit” numbers as I call them. The “3-digit” ones like 00000270 and 00000290 are wings+weapon surs but have no clear meaning of left/right or function - for example in the bw_elite (stiletto), there are two identical left wing+weapon surs both with the hash 00000270, but of the two identical right wing+weapon surs, one has the hash 00000270 and the other has the hash 00000290 !
In the bw_vheavy_fighter (sabre) there are two wingsets, upper and lower, and these have only 1 wing+weapon sur each - the two upper wing+weapon surs (1 left and 1 right) both have the hash 00000540 ! And the two bottom wing+weapon surs (1 left and 1 right) both have the hash 00000270 !
The 2 bw_freighter hashcodes you haven’t identified cover the front hull of the dromedary and the rear hull, and both have identical duplicates. I am still looking but it will just be a random name someone chose like maybe “dromedary_front_hull” and maybe “dromedary_rear_hull” so they won’t be found easily!!
The odd thing is neither of them match any of the .cmp group names so I don’t see how they can work under the conditions that we have deduced for them to work, but obviously they do work !
Here’s the full listing of the dromedary (bw_freighter) surs as imported by the sur importer, and observations…
M01_Root - covers middle of hull M02_f00fb9de (HpMount) - the Shield Bubble M03_HpMine01 - HpMine01 M04_HpCM01 - HpCM01 M05_HpShield01 - HpSHield01 M06_HpThruster01 - HpThruster01 M07_HpWeapon02 - HpWeapon02 M08_HpWeapon03 - HpWeapon03 M09_HpWeapon01 - HpWeapon01 M10_HpTurret04 - HpTurret04 M11_HpTurret01 - HpTurret01 M12_HpTurret05 - HpTurret05 M13_bw_star_eng_lod1 - covers starboard (right) engine M14_bw_port_eng_lod1 - covers port (left) engine M15_bw_port_wing_lod1 - covers port (left) wing M16_HpTurret02 - covers HpTurret02, on top of port wing M17_bw_star_wing_lod1 - covers starboard (right) wing M18_HpTurret03 - covers HpTurret03, on top of starboard wing M19_bw_glass_lod1 - covers cockpit glass M20_E5A5F5DD - covers front part of hull M21_0E4ADA66 - covers rear part of hull M22_baydoor01_lod1 - covers right baydoor M23_baydoor02_lod1 - covers left baydoor M24_00001B10 - duplicate of shield bubble, same location M25_bw_star_eng_lod1 - duplicate of M13 but located near origin. Should be centred on M13. M26_bw_port_eng_lod1 - duplicate of M14 but centred near origin. Should be centred on M14. M27_bw_port_wing_lod1 - duplicate of M15 but centred near origin. Should be centred on M15. M28_HpTurret02 - duplicate of M16 but centred near origin. Should be centred on M16. M29_00000290 - shape covers port wing plus HpTurret02 but is centred near origin. Should be located on M15+M16. M30_bw_star_wing_lod1 - duplicate of M17 but centred near origin. Should be centred on M17. M31_HpTurret03 - duplicate of M18 but centred near origin. Should be centred on M18. M32_00000290 - shape covers starboard wing plus HpTurret03 but centred near origin. Should be located on M17+M18. M33_bw_glass_lod1 - duplicate of M19 but centred near origin. Should be centred on M19. M34_E5A5F5DD - duplicate of M20, same location. M35_0E4ADA66 - duplicate of m21, same location. M36_baydoor01_lod1 - duplicate of M22 but centred near origin and rotated 90 degrees clockwise (looking from top) M37_baydoor02_lod1 - duplicate of M23 but entred newr origin and rotated 270 degrees clockwise (looking from top) -
**@ 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
