Questions about SUR format

Interesting. Had a hunch that not all data might be of use. Some redundant others being a byproduct. Having PartID hash tailed at every vertex in vertex buffer was baffling too.

Some progress. Mostly at importing functionality.

Hi. Thanks for explanation. Can you send me tree-related code as well?

Yes, I’ve noticed outer hull is available per part only when it contains more than one collision hull. And nodes forming tree when I visualized their bounding spheres in scene as well.

I’ve covered most of the stuff so far (importing-wise, exporting is another story), even made a tool to “paint” convex meshes, which is a modified selection brush for vertices and edges that updates convex mesh generated by Nvidia PhysX tool. Generating offsets will be most annoying I’d assume.

Another benefit working in 3ds max directly is that outer ‘shrinkwrap’ mesh can be built with the knowledge of compound hierarchy and part transformations, particularly when a part contains fixed children which it seem to need to envelop as well.

While I hadn’t much experience with free pascal I don’t think it’ll be a problem to figure it out and re-implement in 3ds max.

Minor improvement for importing:

Reworked .sur importing, so that only parts and hardpoints present in model have their hitboxes meshes constructed and attached.

HUD wireframes (VMeshWire/VWireData) are loaded and are going to be exported as well.

On a side note about vertex normals and smoothing groups. Normals can be can be imported and assigned explicitly, but that has several drawbacks, so I’ve made it optional feature. Smoothing groups cannot be restored back from explicit normals and they remain unaffected by smoothing group you’d set their faces to (kinda obvious). I think what I can do is to export smoothing groups into custom UTF entry (let’s say VMeshSmoothingGroups alongside VMeshData, which the game will ignore) but importer will recognize and restore those.

Animations are going to be major headache. They have no direct equivalent in 3ds max animation system, being far simpler and restrictive. Approximating it to max motion controllers might do for importing, but exporting that into FL’s animation isn’t going to be simple.

Coincidentally if anyone have a good idea what all those flags in compound animation scripts do it would help greatly. There’s only so much I can pull from junk pile that is C:FW source code, and even that might have changed for FL.

Thanks for the code.

The benefit of having it in MAX is fairly simple - coherent development pipeline. I’ve initially started the toolkit to import and export models, not just meshes but proper hierarchy, constraint types, hardpoints, HUD wireframes and more which existing tools do not cover or only partially and never to extent the formats permit. I have custom objects and properties (which are persistent, so they’re saved into scene files) to facilitate entities special to Freelancer. Naturally I’d like to add support for SUR, not just importing but exporting as well. There are many obvious benefits to this as everything remains within single software, and everything can be manipulated by wide array of native instruments available to 3Ds MAX user, not to mention countless popular third-party plugins to satisfy all modelling needs for Freelancer formats. Of course the price of any tight integration is portability. Initially I had worked on Collada converter but quickly realized its support varies greatly between modeling software to such extent that common denominator dataset is barely able to cover minimal support I seek.

So far I’m making slow but steady progress, adding early support for DFM while rummaging through landfill of C:FW source code to pick up anything applicable to FL.