CMP to SUR Conversion Tests

@ ST: Yes, I have problems with the Terrain. And the Terrain Hill, and a gunboat-sized ship, and a fighter, and an extra large ship. But the TERRAFORMING GENERATOR works (I guess you accidentally mis-read terraforming for terrain)

nice would be just a milkshape program library to export proper surs based on adoxas knowledge hint, hint
isn’t it that, what we actually wait for?

BBalazs - yes I did, but sorry I don’t follow, which terraforming generator works? Is it the MilkShape plugin, did you use that to generate the terrain?

Gisteron - well LS decided to make the sur builder and generate surs from cmps directly. It’s almost done!

We do have a sur export plugin for MilkShape already, but it is not 100% reliable. It is better when we use the Convex Tool plugin first and then generate surs with it. (Actually there are 2 plugins, but 1.2 is far worse).

But so far this sur builder has been very good according to people who have tested ship surs in-game. I haven’t done that extensively yet, I test for at least 30 minutes because bad surs have taken 10-20 minutes to crash in the past. I proved this by using standard FL surs for all ships, gave them to hostile NPCs and let them fight - and it ran overnight! Then substituting 1 of my suspect surs it ran for about 20 minutes then crashed, so I use this longer test time as standard now.

It surely is great to have a cmp to sur converter, but from a modders point of view, seeing we are still in stone age as regards sur exporters is kinda annoying, especially when you want custom surs because of high model complexity and similar issues.

Yes, sadly the authors have tended to depart before completing the plugins, so we are starting from scratch each time some kind Knight takes it on.

@Schmackbolzen: SurDump reads sur files no problem; source is text, so just look at that. I had thought of adding sur to the XML Project, but I feel the format doesn’t lend itself to easy manual editing.

I shall be updating the sur exporter, soonish. The “Problem - IDS?” topic inspired me to work on a better infocard maker. For example, you give it “Battleship \i{Osiris}.\n” and it will give you (compiled into a DLL) “<rdl><push><text>Battleship</text> <tra italic=“true”><text>Osiris</text><tra italic=“false”><text>.</text><para></para></tra></tra></push></rdl>”.

That ConvexHull tool is pretty much what I was going to make from the shrink-wrap option of the current sur exporter. No source, though (for the plugin; the actual generator has source), so I still will, so I can choose my own names and create a single convex mesh for a group of meshes.

@ST: If you have a look at the california minor planetscape (landing sequence), you can see brown pyramid-like structures. I referred to them as terraforming generators. The sur builder has built a very good sur for them, and they are completely scenery objects. Conclusion is that the sur builder can create good surs for scenery objects as well.
The other files that I have attached in my previous posts (a simple hill and a terrain) all have this problem mentioned earlier: some meshes don’t get built.

@adoxa: Well the one thing missing is, how to calculate the opposite offset of each vertex in the triangle list. Any hints?

Edit: Never mind, got it from the ms sur exporter

I did a bit more testing last night and found one of my small fighters got a bad sur made by sur-builder with missing sur parts over the left wing.

I looked at the cmp and found it had both the wings made as tops and bottoms, not complete. Can’t think why I had done that. But the right wing surs were gen’d fine.

Anyway, going to regroup it and try again and will report back.

Good report, thank you.

FWIW, the SUR Builder cannot seem to make a correct SUR for a vanilla Titan, either. The builder’s SUR is assymetrical, with what looks almost like an “extra” fin. There is no need to make a SUR for the Titan because the vanilla SUR is fine, but it was one of my test models.

Some models confuse the SUR Builder. So far, it seems to be mostly due to some small problem with the CMP.

Has anyone figured out yet, how the tree structure in the Bits Sections works? That seems to only thing missing, even the ms sur exporter seems to have errors concerning this part and I could not figure out yet how it constructs such a tree.

If you go back to this post, you’ll see the function that uses it. I believe it’s some sort of Bounding Volume Hierarchy, which is how I’ll be renaming it, should I ever get around to it.

Well the problem is, that I don’t get the purpose of the siblings (except of the root bound, that is perfectly clear). When I look at original vanilla surs, the siblings all have different centers and radiuses, which don’t seem to have anything to do with the other siblings or triangle groups. So I am asking, is this some sort of serialized tree? If so, is it pre-order, in-order, etc.?

The center of each sibling with a Tri (using SurDump’s output) is the center of that group. For example, looking at bw_fighter.sur.txt, you’ll see that Num 5 points to Tri 5, which is HpTorpedo01. Look at the vertices that have HpTorpedo01 and you’ll see that they match the center and scaled radii. Try looking at the log of the latest sur importer, it actually calculates each radius (I’ll add it to SurDump sometime).

Well I have developed my own theory and it seems I was correct. I was able to create basic vanilla like sur files. Importing vanilla surs (without hardpoints, just the meshes) and converting them again worked.

I now have extended my .obj->.sur converter to work without convex hull meshes.
I appended a demonstration for the industrial_dock.cmp of the aldebaran modular station pack II. You will see that it is 1:1 geometry and it does work in the game. The big box around it is just the shrink wrapped hull, which I don’t automatically generate yet and so I chose a simple box.

If any one wants to have some .cmps tested you can give me a link or attach a file and I can try to convert them. All groups will be converted to the main root group, though.

There still is much work to be done. Sorting of the tree in the bits section is not ideal yet for example. Multiple groups are still not implemented. The list goes on

Well, the two cmp files I had problems with and attached here just a few posts ago are good candidates. They are solars, so it’s no problem if the sur is converted down to the root; the terrain file is huge in size and the hill has overlapping groups, both interesting in the case of a sur.

I have attached both surs. They seem to work pretty good, although the data structure is not yet optimal. For example, milkshape tends to clone every vertex used by a different group when exporting to .obj and I don’t filter that yet.

I now have extended my .obj->.sur converter to work without convex hull meshes.
I appended a demonstration for the industrial_dock.cmp of the aldebaran modular station pack II. You will see that it is 1:1 geometry and it does work in the game. The big box around it is just the shrink wrapped hull, which I don’t automatically generate yet and so I chose a simple box.

Does that mean you figured out how to do vanilla-like surs?
All the geometry in one group without having to make XXX convex-hull parts and then splice them together?

Yes, that is correct. I can convert any geometry you like to a .sur file

Thats awesome! The real breakthrough regarding .surs IMHO

Keep it up