CMP to SUR Conversion Tests

Good to see you Lancer!

Just as a reminder to all:

The beta is already fab for one-group models, and is absolutely fine for small ships.

This is because only one sur part is created by the beta, and that part covers the entire model in a tight-fitting convex shroud.

So if there are gaps between parts of the ship it really doesn’t matter when the ship is small, because hits will register on empty space but it is small space.

The utility Lancer is still working on is going to be great for large ships where the gaps between booms etc is huge, like the gap between the engines on the Enterprise 1701-A type for example, and shots that should pass through will be hitting the ship spaces instead.

This version will create one sur part per group, so it is important that the model is created (or modified) in sensible groups, for example for the Enteprise there should be the following MilkShape/.cmp groups:

1. Saucer
2. Main hull
3. Saucer Pylon
4. Left Engine
5. Left Engine Pylon
6. Right Engine
7. Right Engine Pylon

Each group of the ship will then have its own sur, so that there will be gaps in between the groups, and shots will pass through all the gaps instead of hitting.

In the .cmp each Group can (and should) have sub-parts for detail, but these should not be separate groups - you can determine this by placing each part under the main group that it belongs to in the MilkShape Groups list, and then in the .cmp exporter by setting the right Group Quantities (count of the parts plus the main Group itself) for each Group.

But you MUST make your ship in this way for this to be effective.

ST going into hybernation and long sulks after being told off by FF.

Let me know if you want me back.

<tearful sobs=“”></tearful>

StarTrader wrote:

LancerSolurus wrote:

Something is missing in the understanding of the cmp model format. I have generated Cons-Fixed entries,

Errm… I hope you mean Cons-Fix ??

Not Cons-Fixed!!

P1p3r’s .cmp exporter also caused a Cons-Fixed problem, we have to rename those nodes as Cons-Fix.

LS - you didn’t reply to this and I don’t know if it’s a typo or if it really is Cons-Fixed, causing the problem you have?

LancerSolurus wrote:
… this will be my last major project for FL, I am itching to get back on my game engine and get it completed since most of the basic functionality is built and working.

An offer though, I will release the code to somebody who is competent to finish this project, only thing is you can’t release the code. I’ve spent 12 years building my library and I don’t want it in the public domain…

Since nobody else seemed interested, I volunteered to help maintain this project. I am not a modeler, so I may need help from you guys to know when the SUR builder creates an incorrect SUR.

I did fix a couple of bugs and tried to make the user interface and documentation a little easier for new users to understand.

I still have a list of improvements to work on, so this is still an interim release:

• Creates single-part (bubble) SURs consistently.

• Creates multi-part (close-fitting) SURs if the CMP has one part per mesh.

• Sometimes can create a multi-part CMP from a single part CMP (still buggy).

Well done Bullwinkle. I’ve been waiting for progress on this for many months, and even got bo*****ed by FF for prompting LS too often!

Does this mean you are “da man” for this project now?

Should I expect it to do OK if there are no subgroups you mean? And not OK if there are any subgroups to a main group? I can handle that with some cmp juggling I think.

I’ll try v3 on my multi-part cmp’s and report back in a couple of days.

Thanks pal.

Oops!! First problem -

Error message on double-clicking the builder for th first time:-
“The paging file is too small for this operation to complete”.

This happened in the previous version too, but I have allocated 1.5GB page file!

I had to delete my paging file to get v2 to work. I’ll try the same now but it’s a problem…

How much does it need?

Help please Bullwinkle!

Error message on startup,

“This application has failed to start because d3dx9_42.dll was not found. Re-installing the application may fix this problem”

StarTrader wrote:
Does this mean you are “da man” for this project now?

Should I expect it to do OK if there are no subgroups you mean?

Well, I am no Lancer Solurus. That guy has a depth of knowledge about Freelancer data formats that is well beyond my own.

But I am the current maintainer of the project, yes.

So I may ask as many questions as you do but, with the help of the rest of the community, I hope to be able to get the code to do what it is supposed to do!

For example… what’s a subgroup?

Is there any reference material that will help me to understand what a SUR is supposed to look like on the inside?

I understand what a SUR does, and I can see whether HardCMP 1.0.0.23 will display it, but I still don’t really understand what I am looking at when I see the data itself.

StarTrader wrote:

How much does it need?

1.7 GB… in addition to the 1GB or so that you probably need to run Windows XP effectively. I cannot imagine running this with less than 3-4 GB of RAM… sorry!

Yes, it is huge. I don’t really know whether any of that can be trimmed, but I will watch for opportunities to do so.

Gibbon wrote:
“This application has failed to start because d3dx9_42.dll was not found. Re-installing the application may fix this problem”

Hmmm… well, I am pretty sure that you have DirectX installed, Gibbon, so it’s not that.

Try this update to the DirectX redistributable files.

If that works, then I will include the redistributable files with the next update.

Thank you for the report!

What !!!

We’re talking about pagefile size, not RAM.

What makes it take so much RAM anyway? Nothing else I run causes this problem, not 3DSMAX, not PhotoShop, not Access with a huge database, and not when I run them all together!

I have 1GB on this laptop and its fine for everything except this proggie - so no way, Jose. I’m not running a mainframe for a utility, come on guys, do me a favour.

Careful frugal progging is needed, not loading in huge libraries that may not be used.

Gibbon: You need to install LS’s runtime Library. I already did that.

StarTrader wrote:
We’re talking about pagefile size, not RAM.

The program reserves 1.7GB of RAM. Windows will page out memory that is reserved but not currently in use, which is why you get an error about the page file.

As I said, I know that it is huge and I will try to make it smaller if I can. However, one of the goals of this program is to build SURs for large and complex CMPs, such as stations.

Try a 3-4GB swap file and let me know whether it will run. It will probably take a while to load in 1GB of RAM, no matter what you do with your page file.

As for “why?”, I cannot answer questions about design decisions. All I can do is to try to improve the code that I have in front of me. It is complex and the programmer’s documentation is minimal… which may be why nobody else volunteered.

Thanks for taking on the task, Bullwinkle. It’s much appreciated by us all.

Right.

I should point out that Lancer has helped me quite a bit to get this far. I would not have a chance without him. Thanks, LS!

@Sushi: You are welcome!

@All: I have a model that does not seem to produce a working SUR, and I need some help in figuring out what is wrong with the SUR and/or the model. This is the first model that I have found that does not produce a working single-part SUR in the builder, so it has me curious – what is special about this model? And what is incorrect about the SURs created by the builder?

From the .3dbs and hitboxes thread:

Model:
http://www.mediafire.com/?czmzdmd5jmn

SURs – Single- and Multi-Part, with surdump output text files:
http://the-starport.net/freelancer/forum/dl_attachment.php?attachid=1274135985&post_id=29006

.

I put in the model back into milkshape and reexported it. It works now. Attached are the .3db, .cmp, .mat and .sur

Sushi wrote:
I put in the model back into milkshape and reexported it. It works now. Attached are the .3db, .cmp, .mat and .sur

Nice!

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 .surs

Aha.

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>