CMP to SUR Conversion Tests
-
Agreed, this tool is for general purpose FL surs, the best SUR will always be the one you build yourself. But for lazy butts like me it will be a very useful tool
-
lol Sushi, i think Gibbon talked about Lancer
well, a little in late but done
here the file : borg sphere
http://www.filefront.com/15224793/Borg.rara sur with 288 faces, not tested more but if you need donāt hesitate to ask
done in 3dsmax
export to .3DS
import in milkshape
export as a .sur
spliced
no modifications of the cmp done with mikshape -
OPR8R wrote:
regardless of the good work done here i still would use custom build surs for the simple fact that a complex sur being result of a complex cmp will cause way too much lagSure, I was under the impression though that we still dont know everything about the sur file format, otherwise we would be able to make surs that are working just like the vanilla ones. If LS can figure out the sur format completely, that would really be a leap forward.
-
OPR8R wrote:
regardless of the good work done here i still would use custom build surs for the simple fact that a complex sur being result of a complex cmp will cause way too much lagI keep hearing thatā¦ Iāve used some extensive surs in the past but have never really noticed a lag effect. Can someone provide me with a SUR that does cause lag?
-
Here is a start for the formatā¦.
SUR File Format Compiled By Lancer Solurus All values in HEX unless otherwise noted (Size in decimal) ***************************************** Size(d) Type Comment ** Header 4 byte 'vers' - Version 4 float 2.0 ** Section header 4 ULONG CRC 4 ULONG Surface Type 0-, 1-, 2-, 3-Equip/Ammo/Damage, 4-Ship/Station 4 byte '!fxd' - Part header 4 byte 'exts' - Tag 12 XYZ Box minimum 12 XYZ Box maximum ** Surface tag 4 byte 'surf' - Surface ** Surface header 0x00000038 4 ULONG Surface offset, bytes to next HPID or section (this addr + offset) 12 XYZ Center 12 XYZ Inertial damping 4 float Radius 1 byte Flag? 3 byte Duplicate of surface offset above 4 ULONG Bits section offset (surface header start addr + offset) 4 ULONG ? 4 ULONG ? 4 ULONG ? ** Face list header 4 ULONG Vertex list offset (this addr + offset) 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 3 byte Referenced vertex count 4 ULONG ? 4 ULONG Face count ** Face list 12 bits Face number nn xn xx xx (4 bytes) max 16,384 faces 12 bits Index or options? xx nx nn xx 1 byte Flag xx xx xx nn 2 WORD Vertex index 1 nn nn xx xx 1 byte Offset? xx xx nn xx 1 byte Flag? xx xx xx nn 2 WORD Vertex index 2 1 byte Offset? 1 byte Flag? 2 WORD Vertex index 3 1 byte Offset? 1 byte Flag? ** Vertex list 12 XYZ Vertex position 4 ULONG Cmpnd/HP CRC ** Bits section (as in 24 bit bitmap) 4 ULONG Sibling offset {Bits base addr + offset) 4 ULONG Triangle offset (triangle base addr - offset)? 12 XYZ Center 4 float Radius 4 ULONG Color (RR GG BB xx) - xx is always 00 -
BTW, thanks Mirhka, I will play with that, good thing I wrote a sur scipter so it writes the C++ code for me, I just copy and paste it into the program
-
**Mirhka, is it possible I could get the cons_fix.dat file for that borg sphere? I am nearly done with the second phase of the exporter but only my root sur is showing up. I did get one of the hardpoint surs to show up by screwing up the root sur (setting it to type 3 instead of 4).
At least FL isnāt flagging any errors on it and I can still shoot the ship. Due to one of the errors I did have I found the sur code in Common.dll ;)**
-
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.**
