CMP to SUR Conversion Tests

Gisteron

heh, watcha say? for years our community had problems and still has with building SURs manually. the sur builder is probably going to solve this problem entirely once it is perfectionised.

ZetaPirate

Gibbon wrote:
…still get the same error saying a dll is missing.

If this is still an issue, as I also had this, you could go to www.dll-files.com and search for the missing. Worked for me. What was funny to me was that I had V.2, fixed it w/ that website, then downloaded v.3 and had to download another one Just extract them to the System 32 folder.

? Offline

You obviously missed my last post then where i mentioned it was sorted

oZed

Hmm, great tool, haven’t found many problems yet. If you are looking for other features, maybe if you can make it possible to create shield surs with the attached CMP, it would be easy to use a template CMP since it is all but empty and rename it original CMP name_shield.CMP and SUR. I’m just running out of things that this could do its that great!

Thanks to you all for making this
Ozed

StarTrader

Hi BW.

Yes, it ran in my 1GB RAM after I deleted my page file, and finding d3dx9_42.dll from dll-files.com.

I still have to delete my page file every 3-4 runs. Annoying. Thanks for reducing it over time.

1. On the cmp splitter - I was not complaining about it, please leave it as it is for now, I like it for a quick fix because for some ships it will be fine. It’s only when there are odd shapes on the ship that it will not be perfect.

2. On the .sur bubble - load up a vanilla model in HardCMP and look at the largest sur bubble, surroundng the ship - that is the one I’m talking about. (In fact there are 2 of them, identical - see below).

Yes as you say, as far as I can tell it is just a sphere squashed around the ship shape. I can’t see how far away from the ship surface the nearest sphere surface is, but I would think 1 unit (equates to 1 real metre) in all directions is fine? The easiest way would be to make the sphere height = ship height + 2 metres, sphere width = ship width + 2 metres, and sphere length = ship length+2 metres. But it must be totally convex, and it must be named HpMount. It would be great if this can be an option, as many modders don’t want them (and some like me do).

3. "Vert " means Vertex (plural=vertices), which is a modelling point in space - every face of a model is the surface made by connecting three adjacent vertices with ‘edges’ and a ‘skin’ that forms a surface, and becomes a 2D triangle. The function we are decribing is “up to what distance apart should I combine proximate vertices?”. And (m) means metres, to tell the user what distance unit he is setting. The current Duplicate Radius is not descriptive of this function. Remember this utility will be used by new modders for many years to come after we who are here now have all lost interest. So think up something else that fits in the same space.

4. I don’t know how much LS has briefed you on the intricacies of the sur file. If we are going to try to make identical surs to the vanilla ones, there are some additional sur parts needed, and some difficulties.

Additional sur parts needed:
4A. Damageable Equipment
All damageable equipment needs a sur on its Hardpoint. These are simple shapes positioned on the hardpoint, fortunately only

2 shapes are used -

a 3D pentagonal box (height about 1/2 length) for equipment and
a long tapered 3D Rectangular box (a 4x1 stretched cube with its front face about 1/3rd smaller than the rear face) for weapons.

I attach these sur shapes in .ms3d format in the zip below. The Hardpoint shape is a marker to show how the shape is aligned on the actual hardpoint the sur shape is meant for.

Here are the hardpoints that need sur parts, and the shape:
HpCM01-HpCM99 - pentagon
HpMine01-HpMine99 - pentagon
HpShield01-HpShield99 - pentagon
HpThruster01-HpThruster99 - pentagon
HpTorpedo01-HpTorpedo99 - rectangle
HpTurret01-HpTurret99 - rectangle
HpWeapon01-HpWeapon99 - rectangle

Attributes
a. The name of the sur part must be exactly the same as the Hardpoint name.
b. The pentagon’s bottom surface is centred on the hardpoint centre, and its axes are identical to the hardpoint’s axes.
c. The rectanguloid is mounted with the middle point of its bottom rear (larger) edge centred on the hardpoint centre. The shape’s axes are parallel to the hardpoint axes.

4B. Type 5 sur parts
These are not yet fully understood, they are composite sur shapes used for wings with weapon hardpoints. Import the dagger (DATA\SHIPS\BORDER_WORLD\BW_FIGHTER\bw_fighter.sur) to follow this description:

Ignore the Mnn prefixes in the sur part names, these are inserted by the sur importer to separate model or sur groups.

1. You will see the shield bubble sur is named f00fb9de - this is the hashcode for “HpMount”, the author of the importer didn’t spot it to add it to his list for auto-decoding. You will also see the duplicate shield bubble is named 000014c0. This sur part’s name is different for different ships. This is a Type 5 sur part, thought to be for hit detection. This name 000014c0 is thought to be an offset to the same mesh as the shield bubble - LS/adoxa, has this been proven to be so? Then we need to understand the location offsets so that it is placed in the correct place. For this shield bubble it should be 0, 0, 0. But not so for the others below…

2. In the Groups list, find M12_bw_port_wing01_lod1 - this is the proper wing sur. Select it and you will see it is in the same place as the ship’s wing.

2a. Find M19_bw_port_wing01_lod1 - this is a duplicate of the wing sur, but the importer does not understand its offset values and accidentally puts it at the origin (x, y, z = 0, 0, 0) instead of at the wing sur’s location.

2b. Find M13_HpWeapon03 - this is the rectangular weapon hardpoint sur.

2c. Find M20_HpWeapon03 - this is a duplicate of the weapon sur, and inerestingly is located on the duplicate wing sur but in the correct place.

2d. Now find M21_00000270 - this is the interesting one, the Type 5 sur - it is a composite sur covering the duplicate wing sur and the duplicate weapon sur together. Again its offsets are not understood by the importer and it is placed at the origin, overlapping the misplaced duplicate wing sur.

3. You will find the same set of sur parts for the starboard wing and weapon: M14_bw_star_wing01_lod1, M22_bw_star_wing01_lod1, M15_HpWeapon04, M23_HpWeapon04, and the Type 5 composite sur M24_00000290.

This method is applied to all wings that have weapon hardpoints on them. For instance, the Sabre (bw_heavy_fighter) has four wings, two upper and two lower, and each has the dulpicate wing, weapon and composite wing+weapon surs.

A surprise here - the Sabre’s bottom wing duplicate surs are named the same as the top wing surs - could this be because they are the same shape in this case and are they pointing to the same meshes? - adoxa/LS?

4. There is one more anomaly - all engines also have a duplicate sur, placed at the origin. Find M11_bw_eng01_lod1 and its duplicate M18_bw_eng01_lod1.

–-------

These duplicates of the wing surs, weapon surs and the Type 5 surs are the parts that we need to add to a ship sur, to emulate the original surs correctly. The naming (or are they offsets) need to be worked out and this is where the problems will be.

I attach the text dump of the bw_fighter.sur (using Colin Sanby & Adoxa’s SUR dumper), I hope adoxa will be able to help you to understand it better to construct the headers correctly.

Did you have a go at making the surs for the KTinga? There are problems of asymetry every way I tried, so I sent you the cmp in the zip file to see for yourself. It is caused by the model’s wings and cockpit having a very large number of polys.

Many thanks BW, much appreciated.

Quarks

StarTrader wrote:
Here are the hardpoints that need sur parts, and the shape:
HpCM01-HpCM99 - pentagon
HpMine01-HpMine99 - pentagon
HpShield01-HpShield99 - pentagon
HpThruster01-HpThruster99 - pentagon
HpTorpedo01-HpTorpedo99 - rectangle
HpTurret01-HpTurret99 - rectangle
HpWeapon01-HpWeapon99 - rectangle

What about the other hardpoints? Like the ones used for battleship turrets? Or custom ones? Better make a list where the user can select the hardpoints he wants to be gun/equipment/turret hardpoints.

StarTrader

Actually, weapons seem to detect hit damage anyway without these sur parts so they are not critical to have a working model as far as I can see.

The vanilla battleships already have surs, so even though they have strange names like HpTurret_K1_01 they are catered for.

New ship models - there can only be 32 weapons fired simultaneously, so what’s wrong with HpWeapon01-99 and HpTurret01-99? These are more than enough.

The big battleship guns use a different sur shape, and modders will go on making even bigger guns that will need more different sized sur parts and so on and so on. As far as I am concerned it’s not needed.

And I hope everyone will agree that we want a working sur builder utility as soon as possible, not a wish-list story that never ends to cover all imaginations?

Bullwinkle

Thanks for the enhanced detail, StarTrader. I have a lot to digest here before I respond to most of your note. A few things did stand out:

I would be interested in hearing how useful the CMP Remapper is in its current state. My impression is that it does not work very often, but you can test better than I can.

The symmetry of the generated SUR should be roughly similar to the symmetry of the model, although the results can appear to be exaggerated. For example, I made a multi-part SUR for a Titan and the SUR came out with an extra shape that looked almost like an additional fin. I assume that was due to some inconsistency in the model, such as asymmetrically-overlapping faces, or something along those lines.

Making a single-part SUR solved the problem.

I thought that the goal of the SUR builder is to make SURs that are substantially different than vanilla SURs?

I am not sure that I understand the desire for hardpoint SURs. I can understand a SUR for a weapon, but why for a hardpoint?

If I understand the intention of SURs correctly then, in most cases, they should not be precisely like the shape of the model. It seems to me that the most realistic game-action comes from single-part SURs, except for some specific cases, such as building a base with fly-through parts. For any but the largest cap ships, a bubble shape is more “correct” than a form-fitting shape, isn’t it?

As you say, any hits or collisions will hit the shield rather than the hull, and electromagnetic shields are going to be roughly bubble-shaped.

Have I got that right?

? Offline

I would think the goal of the Sur builder is to make surs that work and are as form fitting as possible.

Let’s use a couple of examples. The sur exporter in milkshape, one of them, can’t remember which, makes totally form fitting surs, absolutely perfect, problem is they don’t work. The method offered by the sur builder uses the shrink wrap method which is an excellent way to make a sur but not perfect.

Problems arise when you have a wierd shape model, an example would be an ‘L’ shaped base. Because of the nature of the shape, the sur will always be a triangle so worse than useless if you’re making a single sur. This is where the multipart side of things come in. The model has to be broken down into groups, seperate surs made and grouped together and hope it works. Hopefully we are at that stage or very close to it with the current version.

The goal should always be to make a sur as form fitting as possible, as easily as possible. I’m no expert at surs, i just need a utility where i load in the model, press a button or two, and bob’s your uncle. Definately getting there

StarTrader

Yes precisely as Gibbon says.

Bullwinkle wrote:
I would be interested in hearing how useful the CMP Remapper is in its current state. My impression is that it does not work very often, but you can test better than I can.

It’s been OK for the couple of tests that I did, so we can get more results from others - but I would like it left in anyway.

Bullwinkle wrote:
I thought that the goal of the SUR builder is to make SURs that are substantially different than vanilla SURs?

No, it was to get working surs, and until now we thought we had to emulate the vanilla surs. But this is the first utility that gives consistently good surs, so we can live with it as long as we get proper hit and collision detection. With multiple groups we are already on a win path.

Bullwinkle wrote:
I am not sure that I understand the desire for hardpoint SURs. I can understand a SUR for a weapon, but why for a hardpoint?

Hit detection for equipment as well as weapons. Well these are only two fixed-sized shapes and if its not too hard just need to be mounted as I explained on the hardpoints listed.

I have not lost Countermeasures mine launchers or shields etc in combat with custom surs, which vanilla models do have, and this may well fix that. On the other hand, I’m not that bothered personally, since the weapons do seem to suffer hit damage - but then I usually get totally destroyed so may not have noticed.

Can anyone else confirm hit damage is received on weapons and equipment in custom ships with custom surs?

Bullwinkle wrote:
If I understand the intention of SURs correctly then, in most cases, they should not be precisely like the shape of the model. It seems to me that the most realistic game-action comes from single-part SURs, except for some specific cases, such as building a base with fly-through parts. For any but the largest cap ships, a bubble shape is more “correct” than a form-fitting shape, isn’t it?

Not at all. Some small ships that have no booms with space between are fine for single-part surs, but as many of them do have arms, booms, fins, multiple wings, a close-fitting sur is the only way or they will be sitting ducks…

Now - many mods have scaled ships from fighters at about 5-6 metres, to battleships over 1000 metres, and then up from there as in mine, cruisers 1000-2000 metres, heavy cruisers and starships up to 3000 metres. Gunboats upwards will need close-fitting surs because of their shapes with space between.

Bullwinkle wrote:
As you say, any hits or collisions will hit the shield rather than the hull, and electromagnetic shields are going to be roughly bubble-shaped.

Have I got that right?

No -
Let me clarify a confusion. The shield-bubble on the ship sur is a different one from the shield-bubble of the shield, which is specified in the shield_link = line in shiparch.ini

The shield’s bubble is the electromagnetic shield you refer to. (In vanilla FL, gunships, cruisers, destroyers and battleships do not have shields, they were put in by wimpish modders! lol)…

The shield will take hits as long as it is up, but when it is fully discharged, it stays down for a timer, and the hull will start to take damage. So the sur (forget the sur shield-bubble for now) has to follow the ship surface. If the sur is large the ship will take hits on empty space around it. If there is a shield bubble on a 3mx2m oval ship the bubble will be approximately 5mx4m - huge difference.

The ship’s shield bubbles (the HpMount and its twin) are used (only?) for collision detection. On a small ship it doesn’t matter if the other ship is touching the hull or the bubble, it’s only about 1 metre away anyway - but on larger ships there should not be a bubble or collision will be far from the ship surface. It feels nice to scrape along the hull of a large ship in a small fighter! lol

You’re very nearly there.

I am happy to compromise as long as the main requirements are satisfied, I can already make the shape surs that I want by careful grouping of my models, and others will need to learn the finer skills of doing that too.

The nicety is to have also accurate weapon and equipment hit detection - if we can get confirmation from others that both equipment and weapons are detecting hits and being destroyed on ships with custom surs, then we won’t need to make identical surs to the vanilla ones, and you can just debug and beautify the builder as it is now.

adoxa

@StarTrader: Weren’t you going to attach something?

I forgot about the sur importer, I’ll see if I can get it working. Not sure if I’ll be able to build the exporter (VC Express doesn’t have MFC, but I might be able to get away with compiling the VC6 version; I’m also a little reluctant to get the 500 meg DX SDK, anyone able to compile the exporter and send me the necessary DX files?) I was also thinking about stripping the exporter code, reading the data directly from the model, bypassing the need for Milkshape. All just hypothetical atm…

StarTrader

Ah! Sorry,

I didn’t check and it had not attached…

Here it is, thanks for prompting me.

A working importer would be great!

<thinks>Plus de-engineering it may well give the answer to making a working exporter too…</thinks>

Gisteron

heh, i love the tag. sounds like someone’s stopping to think xDDD

adoxa

I did get the importer compiled, but you’ll have to wait a bit, now (it’s 3:20am here, I gotta get to bed). The type 5 looks to simply be a bounding box type surface, so I’ll ignore it for the importer. I’ll also ignore the duplicated components, since presumably they’re for when they get blown off. So in the case of bw_fighter.sur, it’ll just be M01 to M16.

adoxa

Find attached an updated Milkshape SUR Importer. It adds a new option “All” - if off (the default), it only imports the first object, which is expected to be Root; if on, it will import everything, same as before. The type 5 triangles (which I kept, after all) are named after the main object, plus “_Bounds”. For example, with bw_fighter.sur, what was M21_00000270 will now be M21_bw_port_wing01_lod1_Bounds. Improves the log (but SurDump is still a much better choice for textual viewing of surs) and uses two digits for the M prefix (so M1 becomes M01). Have a play with it and if there’s no more suggestions, I’ll put it on my site (with the source). Oh, I don’t know if it matters, but I’ve used Milkshape 1.8.4.

Quarks

StarTrader wrote:
The vanilla battleships already have surs, so even though they have strange names like HpTurret_K1_01 they are catered for.

New ship models - there can only be 32 weapons fired simultaneously, so what’s wrong with HpWeapon01-99 and HpTurret01-99? These are more than enough.

The vanilla battleships use such hp names to show which turret model should be mounted on it…that could also be useful on custom models.

Bullwinkle wrote:
I thought that the goal of the SUR builder is to make SURs that are substantially different than vanilla SURs?

I thought they should be as close to vanilla as possible…

Bullwinkle wrote:
I am not sure that I understand the desire for hardpoint SURs. I can understand a SUR for a weapon, but why for a hardpoint?

As far as I understood the hardpoint surs and the wing etc duplicates are used for collateral damage, so when the wing gets damaged, also the equipment on it gets damaged.

Bullwinkle wrote:
If I understand the intention of SURs correctly then, in most cases, they should not be precisely like the shape of the model. It seems to me that the most realistic game-action comes from single-part SURs, except for some specific cases, such as building a base with fly-through parts. For any but the largest cap ships, a bubble shape is more “correct” than a form-fitting shape, isn’t it?

The .sur should be hull fitting. The collision for the shield is done by the shield_link = .sur i think.
You also need multy-part .surs when you want damageable/destroyable parts such as fins, wings, …

StarTrader wrote:
I have not lost Countermeasures mine launchers or shields etc in combat with custom surs, which vanilla models do have, and this may well fix that. On the other hand, I’m not that bothered personally, since the weapons do seem to suffer hit damage - but then I usually get totally destroyed so may not have noticed.

On custom .surs equipment will only take damage if hit directly (since it’s model has a own .sur), but it won’t if only the part it is mounted on gets damaged . (That’s what I have experienced)

adoxa

A new version of msSURImporter is on my site. It reads object names from the associated cmp, so custom models should display the right names. It also creates a half-transparent texture, making the ship visible through the surface.

Mirkha

great !
it also works in 1.8.2
thx adoxa ^^

StarTrader

Heheh. You jumped the gun a bit, Jason…

The duplicate surs are not being placed in the right place.

Here’s my analysis.

If you use the naming of xxxx_Bounds for the Type 5 meshes I think it will not fit in to help build an exporter.

Did you work out what the numbers 00000270, 00000290 etc mean? Are they pointers, do they point to the mesh verts that they duplicate?

The other duplicate meshes in the model are Type 4 but use the same names as their parent mesh, _lod1 as you can see. They are just separate sur groups and easy to make.

Anyway, feedback…
A. General
1. If “All” is NOT checked, the duplicate meshes are not imported, but all of the ship sur parts are, did you say that only the root is imported? Anyway, how is this decided in the importer, what is looked at to decide which mesh to import and which not to import?

(By the way, would you rename it to “Import all Groups” for clarity?)

2. After several sequential imports without closing MilkShape, (File - New then File - Import repeatedly with different models) MilkShape stopped selecting groups. Don’t spend a lot of time on this, it may well be a MilkShape problem. Closing and restarting MilkShape resolves the problem.

3. Remember the duplicate collision meshes are made for HpWeapon hardpoints only if they are mounted on wings, not on the fuselage. HpWeapon hardpoints mounted on the fuselage do not have duplicate meshes made, only the first sur shape. Odd? And then the additional mesh is also made which covers both the weapon duplicate mesh and the duplicate wing mesh too.

4. HpEngine hardpoints seem to have an extra mesh always.

5. I am wondering… maybe the duplicate meshes are to do with when the weapon or wing or whatever part they cover is lost? e.g. when the wing is damaged and broken off, it is then replaced by a damage cap (a broken stub shape) and no hits or collisions should be detected where the rest of the wing used to be? Could this be why the mesh is near to the origin, deliberately out of the way? Doesn’t sound right though, I wouldn’t have done it that way. More likely it could be used to “cancel” the collision detection of the sur part that happens when the component is in place? If you can find the key to interpret the offsets of these duplicate meshes so we can see where they are meant to sit, it would give more clues.

B. Import the bw_fighter (All) to follow these findings:-
1. Bubble copy (named M17_Root_Bounds) should be named Mnn_HpMount_Bounds, as it is a copy of the HpMount mesh.

2. M18_bw_eng01_lod1 is at the Origin (actually very slightly off) - should be at same offset as its parent, M11_bw_eng01_lod1

3. M19_bw_port_wing01_lod1 is at the origin - should be offset 0 to its parent, M12_bw_port_wing01_lod1.

4. M20_HpWeapon03 is at the correct offset but to M19_bw_port_wing01_lod1 - should be offset 0 to its parent, M13_HpWeapon03.

5. M21_bw_port_wing01_lod1_Bounds is near the Origin - should be overlapping its parent, M12_bw_port_wing01_lod1, and M13_HpWeapon03.

6. M22_bw_star_wing01_lod1 is at the Origin - should be offset 0 to its parent, M14_bw_star_wing01_lod1.

7. M23_HpWeapon04 is at the Origin - should be offset 0 to its parent, M15_HpWeapon04

8. M24_bw_star_wing01_lod1_Bounds is near the Origin - should be overlapping its parent, M14_bw_star_wing01_lod1 and M15_HpWeapon04

C. Import the bw_vheavy_fighter (All) to follow these findings:-
1. M31_Root_Bounds should be named Mnn_HpMount_Bounds

2. M32_bw_eng01_lod1 should be offset 0 to its parent, M11_bw_eng01_lod1

3. M33_bw_eng02_lod1 should be offset 0 to its parent, M12_bw_eng02_lod1

4. M34_bw_port_wing01_lod1 should be offset 0 to its parent, M13_bw_port_wing01_lod1
*** Interesting - M34_bw_port_wing01_lod1 is precisely at the origin (checked by duplicating and centering the duplicate, no change) and the duplicate and Type 5 meshes of the port side are in the correct relative positions to this part, not at the origin.

Similarly for M44_bw_star_wing01_lod1 below.**

5. M35_HpWeapon03 should be offset 0 to its parent, M14_HpWeapon03

6. M36_HpWeapon08 should be offset 0 to its parent, M15_HpWeapon08

7. M37_bw_port_wing01_lod1 should be offset 0 to its parent, M16_bw_port_wing01_lod1

8. M38_bw_port_wing01_lod1 should be offset 0 to its parent, M17_bw_port_wing01_lod1

9. M39_bw_port_wing01_lod1 should be offset 0 to its parent, M18_bw_port_wing01_lod1

10. M40_bw_port_wing01_lod1 - looks like this is a badly made sur part, it covers too many parts: upper and lower port wings, port wing pylon and attached weapons and duplicate meshes (M13_bw_port_wing01_lod1, M14_HpWeapon03, M15_HpWeapon08, M16_bw_port_wing01_lod1, M17_bw_port_wing01_lod1, M18_bw_port_wing01_lod1, M34_bw_port_wing01_lod1, M35_HpWeapon03, M36_HpWeapon08, M37_bw_port_wing01_lod1, M38_bw_port_wing01_lod1, M39_bw_port_wing01_lod1, M42_HpWeapon05)

11. M41_bw_port_wing02_lod1 should be offset 0 to its parent, M19_bw_port_wing02_lod1

12. M42_HpWeapon05 should be offset 0 to its parent, M20_HpWeapon05

13. M43_bw_port_wing02_lod1_Bounds should be offset 0 to its parent, M19_bw_port_wing02_lod1

14. M44_bw_star_wing01_lod1 should be offset 0 to its parent, M21_bw_star_wing01_lod1.

See note at 4 above too.

15. M45_HpWeapon04 should be offset 0 to its parent, M22_HpWeapon04

16. M46_HpWeapon07 should be offset 0 to its parent, M23_HpWeapon07

17. M47_bw_star_wing01_lod1 should be offset 0 to its parent, M24_bw_star_wing01_lod1

18. M48_bw_star_wing01_lod1 should be offset 0 to its parent, M25_bw_star_wing01_lod1

19. M49_bw_star_wing01_lod1 should be offset 0 to its parent, M26_bw_star_wing01_lod1

20. M50_bw_star_wing01_lod1_Bounds - looks like this is a badly made sur part, it covers too many parts: upper and lower starboard wings, starboard wing pylon and attached weapons and duplicate meshes (M21_bw_star_wing01_lod1, M22_HpWeapon04, M23_HpWeapon07, M24_bw_star_wing01_lod1, M25_bw_star_wing01_lod1, M26_bw_star_wing01_lod1, M44_bw_star_wing01_lod1, M45_HpWeapon04, M46_HpWeapon07, M47_bw_star_wing01_lod1, M48_bw_star_wing01_lod1, M49_bw_star_wing01_lod1, M52_HpWeapon06). See 10 above too.

21. M51_bw_star_wing02_lod1 should be offset 0 to its parent, M27_bw_star_wing02_lod1

22. M52_HpWeapon06 should be offset 0 to its parent, M28_HpWeapon06

23. M53_bw_star_wing02_lod1_Bounds should be offset 0 to its parent, M27_bw_star_wing02_lod1

I attach the imported surs for these two test ships as .ms3d files too.

I’ve not tried freighters. I looked at the bw_freighter (which has 2 unidentified hashcodes) briefly but I was too tired to analyse it the same way. Maybe another time.

Thanks pals.

adoxa

I don’t think you’re seeing the big picture. Here’s a heavily abridged dump of bw_fighter.sur.

Root (0x12688F2D)
      mesh:       Root (0x12688F2D)
      mesh:       HpMount (0xF00FB9DE)
      mesh:       HpCM01 (0xEF2423B0)
      mesh:       HpMine01 (0xE78AA52E)
      mesh:       HpTorpedo01 (0x0B4DA3C7)
      mesh:       HpShield01 (0xEC0AC291)
      mesh:       HpThruster01 (0x12FAFCD0)
      mesh:       HpTurret01 (0x0399E410)
      mesh:       HpWeapon01 (0x03981F6F)
      mesh:       HpWeapon02 (0x18914ED5)
      mesh:       bw_eng01_lod1 (0xF4082FBD)
      mesh:       bw_port_wing01_lod1 (0xFE3AEE4E)
      mesh:       HpWeapon03 (0x11967E43)
      mesh:       bw_star_wing01_lod1 (0xF51D449E)
      mesh:       HpWeapon04 (0xF5F2EBE0)
      mesh:       Root (0x12688F2D)
      type:       5

bw_eng01_lod1 (0xF4082FBD)
      mesh:       bw_eng01_lod1 (0xF4082FBD)

bw_port_wing01_lod1 (0xFE3AEE4E)
      mesh:       bw_port_wing01_lod1 (0xFE3AEE4E)
      mesh:       HpWeapon03 (0x11967E43)
      type:       5

bw_star_wing01_lod1 (0xF51D449E)
      mesh:       bw_star_wing01_lod1 (0xF51D449E)
      mesh:       HpWeapon04 (0xF5F2EBE0)
      type:       5

So when I say it imports the Root, I mean the top-level Root object, not just the Root meshes. Every object that has multiple meshes has a type 5 mesh (yes, it is offset; I would have thought where SurDump says “bits ofs” would give it away), which is the bounds for the object. The type 5 mesh is not a duplicate of HpMount, it is simply that the mount already encloses the Root (besides, they aren’t identical, the bounds has extra vertices where the wing weapons intersect with the mount). The “duplicate” objects are separate objects in their own right, and so they have their own center.

(By the way, would you rename it to “Import all Groups” for clarity?)

Fair enough.