CMP to SUR Conversion Tests

**Thanks alot Mirhka, that will help quite a bit. The one I’m using now has so few faces I cant get it to even halfway fit any meshes.

BTW, while I’m making this exporter, I’m documenting everything I can figure out about the sur file format. I had it 99% done once before but lost the text file in a HD crash last year…**

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

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 ;)**

**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.**