Questions about SUR format
-
It’s been eight years, don’t expect much. I really only analysed what the file contained, rather than how it was used.
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.
2. What is “opposite triangle index” in triangle header (SurDump.h: Triangle.m_tri_op)?
I always thought it was the opposing face.
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.
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.
-
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.
-
Treewyrm wrote:
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?I set all the opposing indices to 0 in the root of [c]docking_ringx2_lod.sur[/c] and still collided. So I can’t say with any certainty but it does not appear to be used. Further experimentation will be up to you…
-
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.
-
What a time for me to have a nostalgia trip lol
Okay digging this out of the depths of my brain as it’s been about 9 years since I last looked at a SUR, hell it’s been nearly 9 years since I last looked at Freelancer.
4. Is shrinkwrap mesh (type 5) necessary? - if this is what I think it is then it depends on how you built the item your slapping a SUR on. They are designed to spread the damage to everything they cover, for example a wing on a ship that can be blown off, if it has a couple of hardpoints then anything on those hardpoints takes some damage when the wing is damaged directly.
-
Some progress. Mostly at importing functionality.
-
Sorry I wanted to answer, but forgot due to my (hopefully) last two exams. The bits section is a tree which you traverse (I can look details up if you still need it) its something like in-order traversal, but don’t know from memory.
The outer convex hull is used to determine whether the tree has to be used for collision. Thus, if you only have one node in the tree you don’t need it. You never can collide with it so that’s why it has the special flag.
Since most physics engines use a BSP tree, I suppose it is one. I only implemented a KD tree and it seems to work, but not always.
I am considering to make my sur tool open source. I already sent FF my tree creation (it is written in Free Pascal), but he never had time to use it. -
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.
-
I have sent you a pm with the code.
What I don’t understand is, what is the benefit of having it in Max? Is there something wrong with my tool? Maybe I can make some changes there. At least then you are not forced to use Max (which I don’t have). -
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.
-
While i admire your efforts in this Treewyrm, i have no understanding of it and don’t wish to, I’m with Schmackbolzen on this regarding the question why?
There are plenty of us, me included who do not have MAX, and have no intention of getting it. The advantage at the moment with those of us who mess with sur files is that the sur tool that Schmackbolzen wrote works for a large percentage of models, both static and those with parts. While I agree a MAX plugin and exporter will be nice for those that have it, plenty of us don’t.
If any upgrades need doing, the two of you should discuss what needs fixing (if anything) and update accordingly, so everyone can use the sur utility, instead of limiting any major upgrades to MAX users only.
