CMP to SUR Conversion Tests
-
Sushi wrote:
I put in the model back into milkshape and reexported it. It works now. Attached are the .3db, .cmp, .mat and .surNice!
I see that you exported as a CMP rather than as a .3DB, which gives me a clue to investigate. Something about the CMP exporter was required.
I can confirm that the CMP produces both Single-Part and a nice, form-fitting, Multi-Part SUR.
Thanks!
-
Well, the .3db should be there in the file, too. I just exported to .cmp to test the .sur out as HardCMP doesn’t read .3db with .surs
-
Sushi wrote:
Well, the .3db should be there in the file, too. I just exported to .cmp to test the .sur out as HardCMP doesn’t read .3db with .sursAha.
Maybe the SUR Builder did the job, the first time, but HardCMP could not display it? I may need another test…
-
OK Bullwinkle, we’ll bear it and see. Your efforts are appreciated, I’m not being bad just errm… expressing my frustration! I don’t want to change my trusty lapty!
Right - my first feedback:-
Multi-part models: Sur builder - Looks pretty close, well done!!
My Findings:
1. I built a sur for my Nephilim Tripleskate large fighter, which is a multi-part cmp. It is made of three Skate fighters bolted together into one, and the sur looks pretty good on each of the ship hulls. The first time I built it I accidentally left the “Duplicate Radius” at 1 and the surs were pinched up. I set it to 0.1 and it built a very good sur. Because of the way I had grouped all the weapon tips of the three ships into one group, the sur builder built one sur that covers all of them - this is expected. Not a problem, I can fix that easily by separating the weapon tips into more groups in the cmp.2. I built a sur for a 1-group fighter, the ravenstalon, with Duplicate Radius = 0.1 - perfect-looking sur.
3. I used the cmp converter in the builder to split this ravenstalon into multiple groups. It split it into 17 groups. Some sur parts that were then generated seemed to be inside others (for example engine cores well inside the engine bodies) and these are not required. Also some groups were ignored, a good thing if they aren’t needed, but can you tell us how those are selected for omission? In this case from the 17 cmp groups only 9 sur parts were built.
The resulting sur looked more or less OK but the ship has small stabiliser fins that were grouped together and the surs it made bridged the gaps between them. But this too would be easily fixed by making the cmp in sensible groups manually, or during design, with sur builder in mind, like my Tripleskate weapon tips above.
4. Enterprise 1701A - Large Scale - perfect looking sur.
5. Romulan Warbird - Very Large Scale - Sort: Type 2:- Engines, top & bottom wings are fine, but fore and tail sections have no sur parts at all! Set to No Sort:- All OK!
6. KTinga Destroyer - Large Scale - couldn’t get a symmetrical sur at all, got fine netting on one side and 2-3 huge faces on the other side. Played with Sort settings - no symmetry still. Seems worse with No Sort. Got better surs sometimes but not as I would like.
I have not had time to try these new surs in-game, I will do so and report back. They look good though.
General Thoughts:
1. I am very happy with this tool as it is. I can easily design or regroup my ships in proper groups in MilkShape, and others can learn to make them right too. We cannot depend on the builder to split a single-group ship into correct groups, and to even program this to be better will be nigh-on impossible in my opinion as there is no standard way of identifying sensible groups from the meshes.2. When the cmp splitter is used, it names the new groups as <shipname>_1 to <shipname>_nn.
Builder will then create sur groups with the same names, so that they connect to the cmp groups. So when the splitter is used, we will have to use the new cmp too, because the sur will not work with the original cmp!So there is no point in using the cmp splitter function if the sur it produces is not brilliant - it would be better to split the cmp manually and then run the multi-part function of the builder. This way the group names would be meaningful too.
My Personal Requests:
1. It would be better to set the default Duplicate Radius to 0.1 (10cm) because 1 means 1 metre! This will join any vertices that are within 1 metre from each other - it will work OK for big stuff but not for small ones.2. Rename “Duplicate Radius” to “Vert Combine Radius (m):” or “Combine verts within (m):” to be more understandable.
3. Is it easy to make roll-over tool tips or othe method to explain some of the button functions on-screen?
4. The output folder location is not obvious, I forgot from last time and it took me some time to realise where it is again. Can you put in a prompt or make the output folder user-selectable?
5. Try to find the cause of the memory hunger and reduce it as much as possible.
6. To get it to run I had to install LS’s VC Redistributable dll’s, this downloaded something unidentified from Microsoft, and then it still lacked d3dx9_42.dll - the previous version lacked d3dx9_41.dll. I would like this problem to be removed. Thanks.
7. At some stage I would like a Shield Bubble option to complete this for small ships, please. That puts in 2 identical bubbles around the ship - although we aren’t sure if it is these that detect hits or if it’s the shield sur from the shield_link entry specified in shiparch.ini that does that. The MilkShape sur Exporter plugin has a way of doing that but nobody has come up with the source for it.
8. And for the puritans, (includes me to a point) how hard would it be to make the final touches of weapon and other hardpoint surs as is in standard FL ship surs? For your info, there are 2 surs for each of the engines, weapons, countermeasure droppers, and mine droppers, and 2 extra surs per wing for wings with weapon hardpoints on them, one covers the wing alone and the second covers the wing+weapon sur.The duplicates are Type 5 and the format of he headers is dfferent, not sure if adoxa and Lancer worked those out yet? Our sur importer doesn’t know how to intepret the offsets for them and puts them all at the origin (0, 0, 0) in a heap. If you import a sur into MilkShape you will see what I mean. You should move these surs over the part they cover to see their structure.
Minor Observations
For conformity/clarity:
1. “Re-Build SUR” - “Rebuild SUR”?
2. “Duplicate Radius” - “Combine verts within (m):”?
3. “Min-Max Sort”- not clear what this section does. I don’t understand Type 1, Type 2 from the readme file. Can it be better explained and these labels fixed?
4. Also for “Secondary Sort” to be explained?
5. “Sur Types” - “SUR Types”?
6. “Multi-part” - “Multi-Part”?
7. “ReMap Single-Part CMP into One-Part-per-Mesh (for Multi-Part SUR)” - “Convert Single-Group CMP to Multi-Group CMP (uses CMP Meshes)”?I’ll get back with any more and the in-game testing results. I attach a zip file wth the KTinga cmp and screenshots of the surs of all ships I used.
Many thanks for this guys.</shipname></shipname>
-
Thank you for the detailed report, StarTrader. I assume this means that you were able to get the SUR Builder to work in 1GB, which is excellent news!
You have four groups of numbers that begin with “1”, so I will respond mostly to your requests. In general, the answers to your questions about using the features are in the ReadMe.
Regarding the feasibility of automated remapping, I was thinking the same thing myself, but I wanted to hear it from an experienced modder. Thank you… I think I will remove that button, at least for now.
1. Eventually, I want to use an INI file to manage the defaults.
2. Agreed on the concept of renaming controls for better clarity. If there are standard terms then I would like to use them.
“Duplicate Radius” seems more obvious, to me, than “Vert Combine Radius (m)”. But what do I know?
3. ToolTips are on my list to implement, but they are recalcitrant in this dialog for some reason. I wound up using MessageBoxes and the ReadMe for the short term, and intend to add ToolTips later.
4. A normal Windows SaveFile() dialog is on my list, as well.
5. I will work on down-sizing the memory requirement… but memory is cheaper than my time. Well, except that I am doing this as a volunteer.
6. It is not a “problem”… you just followed Lancer’s old instructions rather than my new instructions.
As LS mentioned, I used a newer DirectX library than his.I documented this better in the ReadMe for the next version, complete with links to the required libraries.
7. When you say “Shield Bubble”, you are thinking of something more bubble-shaped than the single-part SURs, right? Is there any reason not to pick a generic bubble-shaped SUR and resize it?
8. You are going to have to educate me more about what you are asking here.
Thank you again, ST.
-
I still can’t get this to run at all. I’ve downloaded the direct x sdk as suggested Bullwinkle, all i get is a folder full of zip files, so not sure what use they are. I downloaded and installed the runtime library files form Lancers site, still get the same error saying a dll is missing.
-
Gibbon wrote:
I still can’t get this to run at all. I’ve downloaded the direct x sdk as suggested Bullwinkle, all i get is a folder full of zip files, so not sure what use they are. I downloaded and installed the runtime library files form Lancers site, still get the same error saying a dll is missing.There should be a program in that folder full of .cab files called “DXSETUP.exe”. Run that to update your DirectX files.
HOWEVER, I gave you the wrong link in the other thread, so you should probably download the newest version. Sorry!:
This is the DirectX End-User Runtime files with the Feb2010 updates. I would think that running Microsoft Update would do the same thing for you, but you might have to run it manually. I do not have a good way to validate that, but the link above should install the correct files.
-
Gibbon wrote:
Ahh yes, world of difference, thx for that Bullwinkle, now to try and blow up the converterExcellent. I look forward to your report.
I get a little bit excited about this project… I think that Lancer made a very cool tool with the SUR Builder.
-
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. -
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 -
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 only2 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 - rectangleAttributes
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.
-
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 - rectangleWhat 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.
-
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?
-
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?
-
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…
