.obj -> .sur converter

I love that sur tool you made LS, for me it’s awesome seeing as I don’t have a community to worry about. I’ve been playing my single player mod for months now and never had a crash related to any sur your tool made, and every ship is using an sur made by your tool. I think I’m getting away with it because I don’t have any cm or mine launchers outside of the sur and they’re all single mesh models. Thanks man!

One day when I’m not feeling too lazy I might give this one a try lol.

Actually just was just posting an idea that could have solved one of the problems the sur builder had which was not building reduced meshes for parts of the model. Mesh reduction is entirely possible for any model using the inside/outside polygon check. I just meant that I should have made the vertices spacing check auto-adjust according to the bounding box or bounding radius of the model instead of using a single user specified value.

No offense to your tool, you actually got it working were as I did not. I may work on it again to finally complete the tool as it should have been in the first place to output files for my game. I doubt I will finish it for FL since I don’t understand the bits section (the BSP tree stuff) and I don’t see any reason to compete with your tool nor would I want too.

Lazy people like me really wish you would LS!

I can’t get to grips with this tool of yours Schmack.
Converting the cmp for my average fighter to an .obj then using directx tools to reduce the model as far as it can go without falling apart still leaves me with an sur of over 200kb, which i guess is bad news. Looking at vanilla sur’s that’s way more than a fighter should have.

How many kb is too big for FL to handle? Can I get away with these 200kb files or is it a case of having to make new models to make the sur file from, cos I can’t be arsed to do that, way too lazy and too little time lol.

If only there was some tool that would give me a simple outline of the fighter mesh!

Schmackbolzen wrote:
If you check “Only use the outer convex hull as collision mesh” my tool does the same as the tool from LS (but a lot faster).

200kb should be ok for today’s machines. Also the ones generated with the new version should be smaller. If you don’t have big ships you don’t need that much detail so I only would recommend not to use the outer convex hull for bigger ships.

Well it’s all good then, nice one man!

Since there is no tool out there for other games which automatically builds a collision mesh I doubt you will get around building them yourself or accept the bigger file size. Or just use the outer convex hull.

Well there is somthing you can use out there. There is the Havok Content tooll for 3ds max that can specifically make collision meshes by wraping the meshes in your scene.

For 3ds again there is also the PhysX plugin, this does the same thing.

One is better than the other at making working meshes. And one is better because it will wrap the groups in your scene automatically. But the other one would wrap a 1 mesh round the whole model and the only way to get round this is by selecting each group individually and do it over and over.

Both tools work great though, it’s what i use for making any hitbox for FL.

all you have to do is export the final product as a obj and run it through the converter.

Or maybe i am just misunderstanding the question?

Schmack, yes would you please explain what this setting does “Only use the outer convex hull as collision mesh”?

I’m not clear on it yet either. Thanks

I think it does the following (based on the comment that it’s good for small objects):
If you have a small asteroid and you use automatic hull generation of it (just by not creating a convex hull by hand), only the outer, convex hull that every sur file has (normally used for detection of the sur) is used for the collision.
Means: Autosplice creates a lot of single sur meshes. The convex hull around it just “overwrites” these single sur meshes. Means you just have 1 convex mesh, wrapping the whole model.

Thanks Skotty,

OK so this is the “shrink-wrap” single-part surs the old exporter made then?

Thats a good comparison. You just have 1 convex mesh around the model.

Got it, thanks.

If this has already been discussed, My apologies.

I have been using the msConvexTool.dll for convex surface creation recently, the only version I could find(The ver w/the popup window) and I have a question for your program. I always check the box for static for each group that was made by the convex tool, and use automatic on all. Does Automatic mean XYZ of the center of the model, (root) or does it refer to the XYZ=0 of each group made?

Fus

It is always the center of each single group.

Skotty. wrote:It is always the center of each single group.

TY Skotty. If that is the case, if I want the XYZ=0 being the center of the sur model and not each group, what settings should I use? I use the setting of groups=1 in the CMP exporter, and want to make sure that XYZ=0 of the sur file’s model is the same.

Side thought:
If I export cmp group=1 and use multiple groups to make the convex shapes for my .sur that gets exported to obj, even tho I label each group name the same as it’s source with the _lod1 extension instead of the _convex that gets defaulted to, Do I have to regroup all my sub-components into one group before the export to obj? Or can I leave them as is?

Fus

The best way to use Schmackis sur conveter is in combination with P1p3rs CMP exporter, because both use the same center point calculation. If you use the old CMP exporter, the standard center will be 0. Schmackis sur converter won’t move any part, so just leave it where it is.

For the sur, leave EVERY convex group single. Just give all sur groups that belong to the same CMP group the same name.
You have to name the sur group exactly like its cmp group, so everytime add the _lod1 to the end (like you can read them out of your FIX file).
If you use multiple sur groups for a non root group, it may happen that the group gets another center point for its “secundary” group (= the group of the destroyed, cutted off part). In this case set the manual center point of the FIRST sur mesh entry of this group with the negated value of the FIX value of the CMP group. The manual center override will always be added to the automatic center, no override.

It may be that I didnt answer your question on a way you wanted. I really have some problems understanding your questions.

Skotty. wrote:
The best way to use Schmackis sur conveter is in combination with P1p3rs CMP exporter, because both use the same center point calculation. If you use the old CMP exporter, the standard center will be 0. Schmackis sur converter won’t move any part, so just leave it where it is.

Sorry I can’t do that. Pip3r’s .dll files don’t show up in my File/Import or File/Export of my MS3D 1.8.4, So I have to use CMP export 0.2 and Import 2.7.

For the sur, leave EVERY convex group single. Just give all sur groups that belong to the same CMP group the same name.
You have to name the sur group exactly like its cmp group, so everytime add the _lod1 to the end (like you can read them out of your FIX file).

I do.

If you use multiple sur groups for a non root group, it may happen that the group gets another center point for its “secundary” group (= the group of the destroyed, cutted off part). In this case set the manual center point of the FIRST sur mesh entry of this group with the negated value of the FIX value of the CMP group. The manual center override will always be added to the automatic center, no override.

Now you lost me. Huh? My CMP’s don’t have a Cons/Fix node cuz I use the groups=1 default in the CMP exporter. (See SS)

Fus

This just get’s more confusing all the time.

Hardpoints that are included in vanilla sur files should be included in the sur file if they are fitted to your model. If not then you will risk having intermittent crashes during combat if one of them is hit.

These are:

HpCloak01 (-xx)
HpCM01 (-xx)
HpMine01 (-xx)
HpMount
HpShield01 (-xx)
HpThruster01 (-xx)
HpTorpedo01 (-xx)
HpTurret01 (-xx)
HpWeapon01 (-xx)

Hardpoints represented by the usual triangle only and not having a hardpoint sur mesh will generate the following message during the conversion:
“Warning, no matching vector pair found! Adding new Triangle Group.”

Here below is an .ms3d file of vanilla hardpoint meshes, to normal vanilla FL scale.

Here is how to use them:

After exporting your model .cmp file, merge this hardpoint sur meshes file with your model in MilkShape, and save it as a new .ms3d filename so you don’t overwrite your model file, in case you need to make another .cmp file. I usually add “Surs” to the end of the filename, e.g. “myNewShip.ms3d” and “myNewShipSurs.ms3d”.

Make your model groups convex by selecting the ones you want and using the ConvexTool, then move each new convex mesh above the original group to maintain your group and hardpoints order. Ensure that the convex mesh name now has the same name as the original group and with “_lod1” suffix, and delete the original group. Do this with all the new convex meshes.

Then move each hardpoint Sur mesh you need to the place of the triangle representing your hardpoint, rename it to the same name as your hardpoint, and delete the original hardpoint triangle. The hardpoint meshes must be named “HpThruster01” etc, and must NOT have any “_lod1” suffix.

You can resize the sur mesh to suit the weapon or equipment that it is covering.

You can also make your own hardpoint sur mesh if you prefer, just be sure it is entirely convex and very simple.

Copy the same hardpoint mesh shape for more hardpoints of the same type.

Delete hardpoints in your model that aren’t in this mesh file, because they don’t need sur meshes, e.g. HpEnginexx (the engines use the sur shapes for the engine groups).

Finally, delete any hardpoint meshes for hardpoints that you don’t have in your model,e.g. HpCloak01, HpMine01, HpTurret01 etc.

Save again and export your .obj file, then use the obj-sur converter.

He he, way ahead of you there, StarTrader.