Questions about SUR format

Skotty. wrote:
I can just redirect you to Schmackbolzen. I have experiemted in the game only, yet never worked with the internal data structures.
Perhaps he can remember a few bits from back then.

Yeah that would be nice. Feels like I’m doing redundant steps to figure out what’s what there. To be specific I’m interested in what to fill the bits section and what to put into “offset” in triangle vertices (where vertex indices listed per triangle). The rest seem pretty straight-forward if a little awkward in places (like those 12 bit ints and such), in comparison to vmesh buffers which are simple enough heh.

adoxa wrote:
It’s been eight years, don’t expect much. I really only analysed what the file contained, rather than how it was used.

Any help to get a full picture is appreciated. The toolkit for 3ds max will be open source as well, too many tools languish in unfinished state and everything is so stand-alone.

1. What is “offset” (15 bits?) in triangle vertices (SurDump.h: Side.offset)? Is it two ints as split in SurDump or something else?

I couldn’t tell you what it is (index to other triangles?), but I’m pretty confident that’s how it’s interpreted.

SurDump splits and does a few things there but I just can’t figure what’t the purpose nor does the source indicate where they’d be used at. The numbers themselves aren’t obvious to me to give a hint what they might be.

2. What is “opposite triangle index” in triangle header (SurDump.h: Triangle.m_tri_op)?

I always thought it was the opposing face.

In that case firing ray opposite to face normal on every face probably would do the trick to pick opposing faces then. Is it actually used or is it just a byproduct of quickhull algorithm that is simply written into file?

3. From what I’ve gathered THeader.type 4 is like a regular mesh while type 5 is a shrinkwrap mesh for the entire part encompassing volumes of sub-parts. Any other types used?

Apparently not.

6. Root is always non-fixed.

Apparently.

Ok, good to know, fewer things to worry about.

7. Bits section is a kd-tree by the looks of it, but offset pointers are unclear to me. Would really need help pointing out what’s in its structure.

8. Scale parameters I guess are single byte per axis representing equal or less multiplier as 1.0 to 0.0. Correct?

FindTriangleGroup might help with those.

I guess that’s a reconstructed code, the piece you linked seem like a filtering/collecting faces phase before SAT test or whatever they used there.

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.