CMP to SUR Conversion Tests
-
Commonly I save all of my models as multi-part meshes based on the textures. Send me one of the single mesh models and I will let ya know if it will work properly…
-
Well my models are all multi-part, the smallest are at least 3 groups (hull, left wing, right wing) and many are 4+ groups.
We just need surs that register hits and collisions and don’t crash FL, especially when the factions are all using only custom ships and only custom surs, which is when sur crashes are most likely to happen as is happening in my mod at present.
Lancer as you know the way to test your utility is to make it produce a sur for a plain FL ship that is as near to identical to the original sur as possible.
That gets complex, with the duplicate sur parts we have seen and yet more duplicates to cover wing+weapon for each side.
And that will delay your project too long for me, my virtual sur beard is already 3 feet long, white and VERY wispy!
I want your sur generator as soon as possible!
I want it, I want it, I WANT IT! TRUST ME, I WANT IT!
-
**Hehe, gonna take a bit more time. I have already started to project up today and I’m making it a separate utility. It is going to take a bit of work to yank the relevant code out of my test program and the cmp editor to put into it. So don’t get your beard stuck in your keyboard, hopefully it should be soon
Thanks for the test model Gibbon.
By the way, I got a pair of scissors if you need 'em hehe**
-
My beard is a bit cold-and-flu-ridden at the moment, 3rd week of sniffles and dribbles.
Duhhhh… going for more headache remedy…
-
Sniffles and nasal drips in the background…
-
**[wmp=640,480]http://www.digitalbrilliance.org/Videos/SUR_Export02.wmv[/wmp]
Zipped up below so you can see it in another player…
http://www.digitalbrilliance.org/Videos/SUR_Export02.zipI am working on the sur file builder part atm. For the first test I will only be using the final hull (the rotating one) then I will start on the sub-parts that were drawn first.**
-
If you pull this off you’ll be the lancer of the year man
-
Oh, this would be an amazing achievement. I cannot wait
GO LS!
-
Quick question from a SUR newb:
Would the creation of a utility for triangle-by-triangle conversion create too memory intensive a SUR for practical use?
I only ask because of how vanilla SURs possess just as many polygons as the actual ship model, creating a 100% seamless fit for hit and collision detection.
-
**@ Arvis - that actually is not a good idea. For one is the concavity issue, another is the poly count. When I was working on the original version in 2008 i did exactly that. It killed my frame rate and if I shot the ship the server and client CTD…
As it is being built now, it generates a convex mesh for each sub-mesh in the model. Each mesh is actually based on the texture. Multiple textures, multiple meshes. As far as others have discovered, only the root sur has to be convex. This means that once I get the initial test version of the program going I will start working on Delaney triangulation. As it stands now a convex hull can’t be used for a tradelane since it has holes in it. That is what Delaney triangulation would solve since it would help build a form fitting sur hull.**
-
When I said “triangle-by-triangle” I was speaking of Delaney triangulation.
Essentially I was asking if having the converter split each triangle into it’s own surface (meaning NONE of the verticies are acutally shared between triangles, essentially tripling the number of verticies in the model but the polycount remains the same) would cause haneous lag when hits and collisions are detected.
-
I only ask because of how vanilla SURs possess just as many polygons as the actual ship model, creating a 100% seamless fit for hit and collision detection.
As far as I’m aware, this isn’t true for vanilla SURs; vanilla SURs are much, much simpler than the ship models.
On a more practical note, will this utility directly create working SURs that, in theory, should work indentically to vanilla SURs, or will it simply be a model that we export from Milkshape?
MK
-
**@ Arvis - that is possible but undesirable, too many sur polys for most ships
@ mknote - it creates a sur**
-
Then I guess my second question/assumption/issue would be:
If we follow identical naming conventions, would it be possible to build a sur from a “dumbed-down” model of our ship (built from simple geometry with no concavities) and have the SUR function given that all model objects have identical names?
OR
Following the same idea, would all the objects be compressed down to the “ROOT” with only that single object in both the SUR and the CMP?
(If that confuses anyone, I apologize in advance. I’m a veteran FL modder but VERY new to the SUR arena.)
-
**@ Arvis - if you want to do that simply use the sur exporter in Milkshape, it will do exactly what you are asking about…
I am posting here that I have successfully built a fully working single hull sur file based off of a cmp model. I have also successfully built a routine to calculate the scaling value in the bits section (aka the color value).
SUR File Format Compiled By Lancer Solurus with Adoxa's help All values in HEX unless otherwise noted (Size in decimal) ***************************************** Size(d) Type Comment ** Header 4 string 'vers' - Version 4 float 2.0 ** Section header 4 ULONG CRC 4 ULONG Surface Type Count (!fxd, exts, surf & hpid) 4 string '!fxd' - Part header 4 string 'exts' - Tag 12 XYZ Box minimum 12 XYZ Box maximum ** Surface tag 4 string 'surf' - Surface ** Surface header 0x00000034 4 ULONG Surface offset, bytes to next HPID or section (this addr + offset) ** Surface base pointer 0x00000038 12 XYZ Center 12 XYZ Inertial damping 4 float Radius for visibility (set this large enough to surround entire object to keep it from 'popping', 1.5*radius is good) 1 byte Flag or Scaler? 3 byte Duplicate of surface offset above 4 ULONG Bits section offset (surface header start addr + offset) 4 ULONG 0 unused 4 ULONG 0 unused 4 ULONG 0 unused ** Face list header (size = 16*face lists) 4 ULONG Vertex list offset (this addr + offset) 4 ULONG Cmpnd/HP CRC or bits offset if 'last face group flag' is set 1 byte Type 4-normal face, 5-face linkage (final face list entry) 3 byte Referenced vertex count, unused by FL, simply set to 0 4 ULONG Face count ** Face list (size = 16*Face count) 12 bits Face number nn xn xx xx (4 bytes) max 16,384 faces 12 bits Opposite face xx nx nn xx 1 byte Flag xx xx xx nn 2 WORD Vertex index 1 nn nn xx xx 15 bits Opposite offset xx xx nn nn (bits 0-14) 1 bit Last Face Group Flag xx xx xx nx (bit 15) (only set if more than 1 face group) 2 WORD Vertex index 2 15 bits Opposite offset 1 bit Last Face Group Flag 2 WORD Vertex index 3 15 bits Opposite offset 1 bit Last Face Group Flag ** Vertex list (size = 16*Vertex count) 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 (this bits base addr - face base offset (0-fbo)) (if sibling offset is not 0, this is 0) 12 XYZ Center 4 float Radius 4 ULONG Scale (XX YY ZZ xx) - xx is always 00 since it's unused ** HpID section - hardpoint IDs 4 ULONG Count 4 ULONG Hardpoint CRC list (size = 4*Count) ```**
