CMP to SUR Conversion Tests
-
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
-
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.iniThe 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.
-
@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…
-
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>
-
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.
-
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.
-
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_Bounds2. 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: 5So 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.
-
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.
-
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_Boundsor 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).
