CMP to SUR Conversion Tests
-
well if you want but the .dat have no data at all
i explainwhen a 3d object have only one sur, there is a problem
i export it with the 1.1 plugin, and have a first sur
this one doesn’t work in game
it’s a problem i encounter for a long time and i fix it like thatmake a sursplicer ini with only one part assigned to the root
splice it and obtain another sur file who works as you can see on the screenbut the .dat is blank, if i can say that, and we don’t need to import any data to the cmp
well, if it’s a problem i can do a 2 part sur with the sphere and a hide component into the borg sphere
which would be a more usual way because we meet rarely a 3d object that needs only one part
also do you want some others complex models for comparison ?
tell me.
-
**A bit of heads up on what I have found so far concerning the sur format, don’t know if it will be useful for anyway but I like to document when I can for future reference…
I am currently using only convex surs so far, so I shouldn’t have any problems with dents yet. Won’t run into that until I start shrinking the sur vertices onto the surface of the cmp meshes.
Surs can be made of multiple parts, everything does not have to be stuck into one group of vertices, faces, bits sections etc, look at the or_osiris.sur for an example. This is the method I am currently using.
A sidenote to this method, anything attached to that subpart must be added to that subpart. This includes hardpoints, I have not started on the submeshes yet but looking at the osiris sur it looks like those don’t matter.
The triangle offset in the bits section is simply a subtraction from the current position of the bits start position in the file to the face section it references.
The color value in bits can be pretty much any 24 bit color as long as it’s unique. I use the crc/4 to generate it.
Every face list must have a bits section.
The sibling offset is just that, subtract the current bits position in the file to point to the next ones start position, its just like a utf sibling.
Triangle offset is always 0 if sibling offset is anything other than 0.
The CRCs used are usually either the object name in a fix, pris, rev or sphere part of the Cmpnd section (the _lod1 stuff) or the exact name of a hardpoint.
Surs can handle up to 16,384 faces per entry, this is not desired though since each extra face will slow FL down. The collision routines in FL are pretty friggin slow, I get a much better performance in my game engine doing bounding box and ray cast methods…
All offsets are relative, commonly from a preset start such as the section or face header.
A quick question if anyone knows the answer, the sur type, do you know the ? ones…
1 - ?
2 - scenery
3 - equipment/ammo/damage
4 - main/root
5 - ?** -
**Appreciate it anyways but I figured out where I was going wrong after I posted that. I wasn’t putting the hardpoint in the right section of the sur file. The cmp model Im using has them all attached to the root sur, I was putting them in a totally different sur, hence they were not showing up.
Making good progress though, love the fact that I load a cmp and simply click export.
I will work on it some more tommorrow, I will have to write a routine to coalease all of the hardpoints into the proper sur but that will be one of the easier problems to fix. It’s after 4 am here, been working on it for about 10 hours straight building the data compilers for all of the parts, tired of messing with it for now.
BTW, just about every sur I have decompiled seems to use that 18 face sur for the hardpoints, the same one Im using for them.**
-
- Rubs hands together in excitement *
Have i told you lately… that we love you 8-)
… sry… I’ve been watching this closely, sleep well LS & dream of a world without empty space collision detection.
-
** Section header 4 ULONG Surface Type 0-, 1-, 2-, 3-Equip/Ammo/Damage, 4-Ship/Station ```This is actually a count of the tags in each section.** Surface tag
1 byte Flag?** Face list header
4 ULONG Cmpnd/HP CRC, also something else, see last entry in manufacturing_platform_lod.sur for an example (0x00002540)
1 byte DirectX vertex type** Bits section (as in 24 bit bitmap)
4 ULONG Color (RR GG BB xx) - xx is always 00I've rewritten [SurFileDump](http://adoxa.110mb.com/freelancer/surdump.zip) as a console application, with all this additional information included. Hope it proves helpful, 'cos that's probably as far as I can go… -
**I have taken a break from messing with it tonight but will look into what you have found listed above. District 9 was a very good movie!
Also, I have my own routines for decompiling surs and will play with comparison routines for the different parts. The face offset stuff appears to be offsets to opposite but matching edges in the faces, as in an index of 128,129 points to the first instance of 129,128 excluding the current index, with a limit of -128 to 128 range.
The bits color number is a bit intriguing, I will see what I can come up with a relevance to a normalized scaler for the xyz radius since you mentioned its used by the radius value. I used to use such a thing back when integer arithmetic was alot faster than floating point arithmetic functions. (I’m showing my age now)
The tags sections count I’m a bit leary of, a single tag does not give a type 1 sur, it is usually a type 4, I will double check though since you pulled it out of the source code (assuming here) unless it is counted as header+face+vertex+bits sections…**
-
By tags, I mean the surf, exts, !fxd and hpid codes. The “surface type” is the count of those. That’s how PhyArch::LoadSurfaces interprets it. The bits radius stuff is in a routine at common.0634a9b0 - [esi+0x14] is the radius and +0x18/19/1a the “rgb”.
-
Heheheh….
I feel like a small boy sitting in my toy digger watching you guys in those bloody great 50-ton-per-scoop earth movers!
Your work is very much appreciated guys.
-
**Ahh, now that makes sense. I have also seen 2 exts in a row instead of !fxd then exts…
My assembly is a bit rusty, looks like I need to study up on it.**
-
**Making progress, screenshot from HardCMP…
Getting a good collision on the root mesh but not on the hardpoint meshes yet in-game. Small spheres are the hardpoints, the oblong sphere in the center is the root sur.
Additional info found - the sur radius after the inertial damping setting detemines the size of the visible mesh. This will stop ‘popping’ if it encloses the entire mesh.**
-
Forgot to mention this, the vanilla sur files store LOD (Level Of Detail) info in the Bits sections as a tree structure. Just like with material and mesh LOD stuff, it stores decreasing levels of hitbox face counts with each LOD level. The root bit node contains the pointer to the actual sur data. It’s a bit hard to explain without understanding the sur format, I would assume this was another method of speeding up collision detection on far away objects.
-
Lancer, some questions…
1. as the hull sur is much smaller than the hull and inside it, are the hits registering on the entire hull surface or only on the sur sphere itself?
2. doesn’t there need to be a hull part sur touching them for the Hardpoint surs to work?
3. will the ultimate sur have full-sized sur parts covering the entire hull and booms etc, or will it be similar to your screenshot?
4. will you have an option in the exporter to make a shield bubble for the small ships?
Thanks.
PS - Since this is not an Off-topic thread, can it be moved to the proper place honouring its true status? 8-)
-
**Well, interestingly every sur piece you see is part of the root sur. From studying the vanilla surs it appears that there is a total of 3 surs per sur file. I believe Bejaymac has mentioned this back when I was working on the original cmp to sur converter in 2008 (sorry, never completed that one).
I shrank the Root sur mesh (oblong sphere in center) because it was causing all of the collisions and gun hits. If the hardpoint is inside of it I would be unable to test if it was taking hits on the hardpoint surs.
I will be getting back to work on this tonight and see if it was just a simple typo or something I missed. The way it’s designed now I built all of the info into the root sur according to if it is part of it such as the hardpoints.**
-
**1 - only on the sur sphere
2 - possibly, may be why Im not getting hits on the hardpoint surs
3 - all parts will be covered when Im done, this is just for the root sur only
4 - shield bubble, yes, btw, why would you exclude the larger ships from having a shield bubble?
@ Adoxa - verified, the ‘Sur Type’ is a count
exts + exts = 1
!fxd + exts = 2So a type 3 can be exts,exts,surf & hpid
also it can be !fxd,exts & surf
Type 2 is normally exts,exts & surf
Type 4 is !fxd,exts,surf & hpid** -
Thanks Lancer, clearer now.
Why no shield bubble on large ships? Because it would be bulbous, and would also enclose empty space between booms and other hull extensions which would register hits when they should not.
We want hits to register only on the hull I think.
And the standard FL ships don’t have them.
In some testing I did some time ago, I vaguely recall that the shield bubble registers hits despite the shield_link shield being far smaller.
If you like the idea of having one on large ships, and the programming is not extensive, perhaps you could make it an option and generate a closer-hugging shield bubble for large ships if the modder wants one?
-
I’ve updated SurDump. Now all but three mesh CRCs have been identified and it converts the triangle and bits offset values into indices.
@LS: It is not “exts, exts” - it is one exts for each of two meshes. Have you not looked at the output of the new SurDump?
-
**You are correct, it was a bug in my sur decompiler. I didn’t skip over the tag string output when the type was exts. Now it’s showing the correct number of headers, oops…
No offense, but no I haven’t tried it. I did download it but I avoid command line programs since my version uses a file dialog box to pick the sur I want to decompile. Your utility will be useful for others since I can’t release mine, it’s part of a testbed program that has stuff in it I won’t release since it can royally screw a mod up if you aren’t careful with it…
Additional info found tonight…
The D3D primitive type appears to be a flag, bit 1 denotes last face list
The flag in the face list has bit 8 turned on in the last face list, this is in all of the flags
This one you found, type 5 face list is a relative pointer to the bits entry, that bits entry points back to that face list
Still verifying…
Looks like the bits sections are in reverse order of the face lists
If sibling and face pointers are non-zero then it is the end of a bits treeCurrently I have implemented all of the crc values for every vanilla model in FL, this includes the lod1 stuff which was ripped from the Part node entries
Here is the output from the or_osiris.sur file after the exts fix added…
http://www.digitalbrilliance.org/Files/SUR_or_osiris.log** -
A note on the file, the tabs are 4 spaces, not 8 like notepad and wordpad uses. The tables will be out of alignment unless you adjust your tabbing size. Visual Studio Express is a free download from MS, that is what the file is formatted to be viewed in…
-
Here’s my dump of or_osiris.sur. No tabs are used.
Your face offset is wrong - it’s a 15-bit signed value, with the flag being a single bit. I’ve used “size” for a type 5 face, but it probably should be “bits offset”.I’m missing two CRCs from bw_freighter.sur (0x0E4ADA66 and 0xE5A5F5DD) and one from bw_fighter_rtc.sur (0xE5036F2F). Happen to know what those are?
