.obj -> .sur converter

cata123 wrote:
Why not blender .blend. 100% free, open source and you can do everything that you can do with 3ds.

Don’t forget that except Blender most other software can’t handle .blender files. Obj, FBX and Collada are very common and every good modeling software can handle it.

Im too old for becoming student again… all the alcohol… all the parties

Actually, you dont need to be a student, or have a student email. You can gain access to a educational licensed version by specifying your a ‘mentor’…any email address will do.
However milkshape has some definite benefits over 3ds max, most importantly its size (25mb vs 6-8gb) 3ds is fine if your planning on doing tons of model creation, but if you just need to convert model formats then its serious overkill

Personally I’d not recommend to do any sort of conversion with milkshape due to how limited feature support is there, namely vertex color and transparency, multiple uv maps. Even basic stuff like vertex normals aren’t well supported across formats and has a tendency of screwing up your stuff. If someone wants to make a good importing/exporting tool they’re better off converting between collada and FL formats. Collada has all the necessary features for FL models and is fairly extensible even within its validation schema.

I write a complete solution, without any clicks, with automatic binding of all vertex, parts, hardpoints offsets in .cmp and .sur files.
I need the ability to quickly correct any problems, and make new features without waiting for the another developer.
The only complexity moments for me were - bits-section and convex hull.
I would be grateful for the help by source code, primarily msSURExporter V1.3.

Attached is the source for the exporter.

Thanks Adoxa!

Schmackbolzen
First of all, you need to create the correct information about the parts in .cmp, before parsing by .obj -> .sur converter. There are problems with other exporters, if part is ‘Rev’, ‘Rris’, or chained over other (not ‘Root’) part.
Also, I have implement the automatic connect hardpoint meshes from separate .ms3d file.
I try to exclude such routine work.

Is there anything known about the lag issue of surs when colliding with them?
I seem to have the issue on new station models no matter if I use the obj2sur converter (latest version) or the 3ds max tools.
It also does not seem to matter if I let the tools run their job on the model (cmp version), a detail reduced version (rough shape) or even a version which only consist of purely convex shapes.

The lag starts when forcefully colliding with the station after some time. NPCs also seem to cause these kind of issues in rare occasions.
I’ve read that the lag issue is know… and fixed but… it still happens… dunno.

I’d reckon performance issue you’re having is caused by obj2sur breaking down concave hulls into triangle hulls, which you should avoid at all costs. If you have hitbox comprised of hundreds of hulls then it’s obviously a very bad situation. Individual hulls in a hitbox are expected to be convex and that’s just how it should be. Lastly obj2sur often generates incorrect BVH tree.

Just use surface builder in maxlancer for 3ds max to create hitboxes.

The thing is I went the path of creating perfectly convex shapes prior using obj2sur and maxlancer
Since the days of the milkshape sur exporter I avoided concave shapes.
Obj2sur in the latest version even has the “yes I am sure that everythign is 100% convex”-option which I of course tried (without different results, sure the sur is smaller because there is no splicing but the lag remains)

The station models are relative complex, with negative space for docking bays etc.
To ensure everything is convex I created a simplified version of the stations which I broke down into groups of convex shapes to mimic the overall shape. That was the adviced method ever since we were able to create own surs.

Since I observed these issues with obj2sur I tried to use maxlancer and its sur builder. But even there I can observe these lag issues.
I tested multiple export methods.
In one method I imported the simplified sur model with convex geometry groups from a different program and then exported it with maxlancer
In a different try I allowed the sur builder to generate the convex hull shapes, then exported the model with the sur.
There seem to be multiple export options in maxlancer… I tested them all.
In every case I am able to reproduce the lag issue by bumping my ship into the station often enough. Depending on the method used it takes a bit longer to break the game.
I am not sure what I am overlooking right now.

The use of maxlancer was adviced to me by somebody helping me with some refresh of older 3d models but even there I noticed that his models which purely were done with the surface builder can trigger the lag issue.
So I am not entirely alone with this problem.

The BVH tree you mentioned (correct me if I am wrong) is the color coded stuff you get when enabling the hierarchy option on the sur import in maxlancer, right?
I discussed this possibility as error source with 2 other modders a few weeks ago.
If so, is there a way to fix this?
Even the surs generated by the surface builder of maxlancer have these yellow and red boxes sometimes. I am not sure how to avoid that. The one post I was able to find about that was not so clear to us.

The thing is I went the path of creating perfectly convex shapes prior using obj2sur and maxlancer
Since the days of the milkshape sur exporter I avoided concave shapes.
Obj2sur in the latest version even has the “yes I am sure that everythign is 100% convex”-option which I of course tried (without different results, sure the sur is smaller because there is no splicing but the lag remains)

I no longer use obj2sur so not much I can say there.

The station models are relative complex, with negative space for docking bays etc.
To ensure everything is convex I created a simplified version of the stations which I broke down into groups of convex shapes to mimic the overall shape. That was the adviced method ever since we were able to create own surs.

When you make a hitbox the result is always going to be an approximation and the objective is to make a rough shape of the object using fewest possible and least geometrically complex convex hulls. Generally speaking the less triangles and individual hulls the better it is for performance. Unlike rendering the game physics can’t process complex geometry, it’s all done in CPU and in case of Freelancer it happens in main thread as well. Cut the corners where you can, if you can cut the third of hulls and/or triangles - it’s worth doing in a long run. From my observation the game has some kind of internal time limits and if exceeded the game will discard some hulls in the model from further calculations.

Since I observed these issues with obj2sur I tried to use maxlancer and its sur builder. But even there I can observe these lag issues.
I tested multiple export methods.
In one method I imported the simplified sur model with convex geometry groups from a different program and then exported it with maxlancer
In a different try I allowed the sur builder to generate the convex hull shapes, then exported the model with the sur.
There seem to be multiple export options in maxlancer… I tested them all.
In every case I am able to reproduce the lag issue by bumping my ship into the station often enough. Depending on the method used it takes a bit longer to break the game.
I am not sure what I am overlooking right now.

The use of maxlancer was adviced to me by somebody helping me with some refresh of older 3d models but even there I noticed that his models which purely were done with the surface builder can trigger the lag issue.

Without looking at problematic models you refer to I can’t say for sure what might be the cause.

The BVH tree you mentioned (correct me if I am wrong) is the color coded stuff you get when enabling the hierarchy option on the sur import in maxlancer, right?

BVH (Boundary Volume Hierarchy) is a pre-calculated BSP-like tree for collection of hulls in a single part and is an element of optimization to perform faster lookups in collision detection code. In maxlancer there’s a debug option in import dialog to display and color code BVH nodes. White/grey is normal, yellow means hull geometry is outside node and red means node hull is completely outside node boundary. Yellow isn’t always a sign of problem, if geometry barely sticks out that’s fine. Red however means its hull is most likely not going to work. Most problems with .sur generated by obj2sur working partially were related to it having errors in BVH calculation (nodes would often have erroneous offset by X axis making boundary either partially covering hull or entirely missing it). My post here explains it further.

I discussed this possibility as error source with 2 other modders a few weeks ago.
If so, is there a way to fix this?

Hard to say because since in disco we pretty much remade and re-exported all hitboxes. I have not heard of lags specific to collisions since then.

Even the surs generated by the surface builder of maxlancer have these yellow and red boxes sometimes. I am not sure how to avoid that. The one post I was able to find about that was not so clear to us.

Sure, yellow boxes can sometimes occur because boundary parameters are stored in .sur with reduced bit depth, so there’s loss of accuracy, but the game accounts for that and it should not be a problem if hull generally fits within its node box. In theory maxlancer should not produce those “red nodes” at all. If somehow it does that then fill a bug report and provide assets where it happens - I’ll look into it. Meshes produced by surface builder are not intended to be manipulated afterwards (other than deleting if you didn’t like the result and want to redo).

I can provide screenshots and files when I am back home at the weekend.
Most likely it is not a bug. We are most certainly just doing something wrong in the process. Would be great to figure out what.

Thanks for the input so far.

Edit:
Ive been testing this issue for some weeks meanwhile with different models and different methods, remodeling the surs in different ways for these tests.
And yes, I would say red parts are where the collision lag started in most of my observations. I believe I even have a video showing how it is triggered.