CMP to SUR Conversion Tests

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.

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)

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.

great !
it also works in 1.8.2
thx adoxa ^^

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.

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.

Speaking of SurDump, I’ve just put up a new version that reads the mesh names from the cmp (copied from the importer) and adds a brief option, outputting similar to the above (using “Bounds” instead of “type 5”).

OK, some light is dawning now you set it out better.

Well, it is a complex subject after all, so no wonder I didn’t yet see the whole pic! lol

Yes I saw “ofs” and I understand it means “offsets”, don’t be flippant! lol - but what I mean is that the offsets in the vanilla surs are not interpreted correctly by either one of the importers, because they place the type 5 surs near or at the Origin instead of over the objects they “bound”. Oddly, they are in correct relation to the wing in each case, as I mentioned in my analysis.

If the second big bubble is not a duplicate of the HpMount but a bounds box, then - is it just a coincidence that it’s always the same size and shape as the HpMount other than a couple of vertices you said? And it seems that it’s always centred over the model correctly by the way, unlike the other bounds surs.

We have assumed that HpMount is a collision sur for when the shield is up, is this your opinion too?

Thanks bud.

because they place the type 5 surs near or at the Origin instead of over the objects they “bound”.

You’re still not quite getting it. The other objects are independent of the root object. As touched on earlier, when the wings get blown off they become separate objects, requiring their own surface, since they are no longer a part of the root object. Looking at just bw_fighter.sur (with All), we have M12_bw_port_wing01_lod1 and M13_HpWeapon03 as part of the Root object, with M19_bw_port_wing01_lod1 and M20_HpWeapon03 as part of the bw_port_wing01_lod1 object. M21_bw_port_wing01_lod1_Bounds then covers the wing and its weapon, as a separate entity to the Root object. I was thinking of using Snn, where nn counts the objects (so the Root wing would be S01_bw_port_wing01_lod1 & S01_HpWeapon03 and the bw_port_wing01_lod1 wing would be S02_bw_port_wing01_lod1 & S02_HpWeapon03). This would result in some duplicates, but the cmp importer has duplicated names anyway, so does it matter?

We have assumed that HpMount is a collision sur for when the shield is up, is this your opinion too?

Initially I was going to say “No, the *_shield.sur provides the surface,” but just as well I experimented first. Sticking with bw_fighter, we have:

DATA\EQUIPMENT\select_equip.ini
[Shield]
nickname = bw_fighter_shield01
DA_archetype = Ships\border_world\bw_fighter\bw_fighter_shield.3db
HP_child = SpConnect

DATA\SHIPS\shiparch.ini
shield_link = bw_fighter_shield01, HpMount, HpShield01

```Everything is required: leaving out DA_archetype or any of the shield_link values results in no shield; leaving out HP_child results in a crash. However, as far as I can tell, the [Shield] entry has no effect; it is solely the second value of shield_link that determines the shield's collision sur. Making it something like HpTorpedo01 (I was testing with the Eagle) shows hits on the hull, but still decreases shield, so it doesn't look like separate fore and aft shields would be possible (in terms of effect, anyway, visually it would work).

Aha!! Alles Klaar!

Thanks for the explanation!

No names don’t matter at this time, it’s only for human-readable info isn’t it.

But - now does this give us a good clue on generating the Type 5s when you and BW get to the exporter/SUR builder? I prefer the builder to the exporter and its already almost there.

Well done, Jason.

Just updated the SUR Importer. Uses “Import All Groups” as StarTrader suggested; uses “S_n_” to prefix the surface meshes, counting by group, not mesh; and adds mesh names to the log (like in “0x12688f2d (Root)”).

Now I’m working on the SUR exporter. I’ll be splitting it into two. There’ll be a tool to generate the initial surface meshes; the exporter will take those meshes (or from an import) and create the sur file. This allows the meshes to be refined before exporting.

I can’t wait to use it.

Well done, Jason, and I like the translucent material too!

(Idea - How about a red translucent material for the duplicates and blue for the Bounds, or whatever you like? )

A couple of touch-ups:-

1. importing the bw_fighter, bw_vheavy_fighter and bw_freighter as samples, the duplicate engine surs are named the same as the engine primary surs, e.g.

S2_bw_eng01_lod1
S2_bw_port_eng_lod1
S3_bw_star_eng_lod1.

Should these also be named as _Bounds?
i.e.
S2_bw_eng01_Bounds
S2_bw_port_eng_Bounds
S3_bw_star_eng_Bounds

or have I lost the plot again?

2. Need a new version, in MilkShape’s menu it just shows as “Freelancer SUR…” and it can be mixed up with the old importer.

Hint:- I have tinkered with my other importer/exporters to get them all to show together in MilkShape’s menu by changing the plugin name to “FL xxx Importer vN.N” and the dll name to msFLXXXImportervN.N.dll etc.

Is this one going to be called v1.1?

It’s a great plugin, you shall go down in the Anals of History!

(Idea - How about a red translucent material for the duplicates and blue for the Bounds, or whatever you like? )

I could do that. Use “separate” for the “duplicates” (I really don’t like that term) and “bounds” for the bounds. That would also make it easier to select and hide them.

1. importing the bw_fighter, bw_vheavy_fighter and bw_freighter as samples, the duplicate engine surs are named the same as the engine primary surs, e.g.

S2_bw_eng01_lod1
S2_bw_port_eng_lod1
S3_bw_star_eng_lod1.

Should these also be named as _Bounds?

They are just single objects, so they don’t have a bounds. You should also notice (since I forgot to mention it) that the bounds are just named with the prefix, e.g. S1_Bounds.

2. Need a new version, in MilkShape’s menu it just shows as “Freelancer SUR…” and it can be mixed up with the old importer.

I wanted it to fit in with all the standard importers on the menu, so I removed the version. Plus that’s my hubris, assuming no one will ever use any other version.

Is this one going to be called v1.1?

Depends how precise you want it to be, internally I’ve called it 1.1.2.

It’s a great plugin, you shall go down in the Anals of History!

Ewww!

Version 1.1.3 - does everything except a versioned file name. Also adds “!fxd”, center (of gravity?) and (moment of?) inertia to the comment of the first mesh in each group, as well as another tweak to the log (calculates the scaled radius).

adoxa wrote:

1. importing the bw_fighter, bw_vheavy_fighter and bw_freighter as samples, the duplicate engine surs are named the same as the engine primary surs, e.g.

S2_bw_eng01_lod1
S2_bw_port_eng_lod1
S3_bw_star_eng_lod1.

Should these also be named as _Bounds?

They are just single objects, so they don’t have a bounds. You should also notice (since I forgot to mention it) that the bounds are just named with the prefix, e.g. S1_Bounds.

Yes, this is where I am struggling to understand still - the engines already have their surs, and then there are these separate additional sur parts too, as there are for the weapons.

Many questions in my head…
Do we yet know what is their function, (collision or hit or other)? (Then we might name them better, “Collision” or “Hit” or maybe plain “Secondary”).

Have you found where & how these are used in the game engine?

What would happen / not happen if we leave them out?

And of course the multi-million-dollar Question: do you now know enough to be able to generate a complete and identical sur to the vanilla one with the exporter or the sur builder from the .cmp model of the bw_fighter?

Very nice work Jason, many thanks, you’ve made an old and grey Trader very happy today, with a very nice, colourful and much easier to interpret sur importer!

Well… How is it possible to make SUR from CMP? It must be hard… :-?

TheDvDMan wrote:
How is it possible to make SUR from CMP?

There are several tutorials around for making SURs in MilkShape.

The easy way is to use the SUR Builder. Just be aware that some features are not fully functional yet.

SUR Builder 0.003

.

First - if it is a single-group model of a large ship, you should remodel it into several sensible groups in MilkShape before you attempt to make a sur for it.

If it is a small ship a single-group model is fine, just use SUR builder and it will make a perfectly acceptable sur.

Check out some of the tutorials, and see which one appeals to you.

Hey BW & adoxa,

Are we to expect any further development of sur builder/ a new MilkShape sur exporter? Gone very quiet here!

I’ve been humming and hawing about what to do. I’ve now decided to put it on hold and finish the UTF Editor. I’ll then create new cmp/3db importers/exporters, so everything works together. Is the source to the latest versions (CMP Importer V2.7, CMP Exporter v03) available at all?