.obj -> .sur converter

It would be logical for the shrinkwrap to be used as a “second-level collision hitbox”. That is to say, the game would check for hit detection in three increasingly costly steps:

1. Bounding boxes/spheres; very quick and efficient.
2. Shrinkwrap, simplified and convex polygonal model.
3. Full SUR, concave and complex.

It’d only reach (3) if both (1) and (2) register a hit. Without a shrinkwrap, it has to go straight from (1) to (3), which can be costly if the SUR has lots of small bumps and details or openings. I’m guessing it might even use different algorithms (read: faster for the former) for shrinkwrap and full SUR, since the former can be assumed to be convex.

Thus, shrinkwrap is not essential, but helps with performance. I think Sushi’s current tests have been conclusive on that matter.

Skotty. wrote:
The sur converter won’t create shield bubbles. And one point for you: shield bubbles are using extra surfiles (they are defined in select_equip). These bubbles are represented by a 3db file without visible geometrie and just a HpConnect Point.

if you delete this file, freelancer takes the cmp’s hitbox to “replace” the shield’s hitbox

The .3db shield model has a sur, this is the shield bubble visual collision/hit box, and it can be resized. I’ve done that to make a very large dreadnought shield. But as there is no shield bubble around my large ships, collision detection is not triggered until the munition hits the ship, so hits only appear at the hull surface.

HardCMP does not crash for me, I am using v1.8 (v1.23 does not work with my graphics card). My surs open fine including the large Avioki.

The reason for bounding boxes is to avoid the game engine having to continually check for hits. It only needs to check for hits when any bounding box has been penetrated by another object, so it conserves processing power until it is needed.

The shield bubble actually uses the shield shape defined in the shield_link = line in shiparch.ini to show the visual hit.

There is no overall shrink-wrap (bounding box) around the ship if the ship has a shield bubble, because the shield bubble has a bounding box. When there is no shield bubble, each group has a convex sur shape as normal, and there is a bounding box (shrink wrap) around each group too. These are the “type 5” parts in the vanilla sur files. Open one in MilkShape with the Sur Importer and take a look by peeling off the layers and then you can see clearly the additional bounding boxes. These are the ones we could not reproduce.

If you remember (and as you can see when you import a sur) there are two identical shapes in the sur for the shield bubble - one is bound to HpMount (0xF00FB9DE) and the other is an identical “bounding box” which surrounds it, and has a 3 or 4-digit hex number (an offset, but from what I don’t know) as its id.

I understand that the collision engine checks for penetration of the bounding box to start checking for hits, and as the shield bubble (HpMount) is identical in shape and size, it registers a collision or hit immediately.

So if we want to see the visual shield around the ship being hit, we need to have the shield bubble, or else the visual hit will be close to the ship surface.

This is fine.

For the shrink-wrap around an entire ship, this is the bounding box, and checking for hits begins when another object penetrates this bounding box. The engine checks for a collision between whatever object has penetrated this bounding box and any collision boxes inside this bounding box. The collision boxes are the sur shapes around our ship parts or object parts. If there is no collision with any collision box then the penetrating object is allowed to continue on its path.

So if there is a hit then it appears close to the ship’s surface, where the collision box surface is found.

This is also fine.

So overall and for compatibility with vanilla FL surs, I think we do need a shield bubble option for small ships.

Now how about when there is no bounding box at all, only sur shapes, as we have when we generate a sur with Sur Splicer?

Is this last version used in vanilla FL, or is it only a fluke that we made with Sur Splicer accidentally, and it just happens to work as long as we can put in the hpids?

Since the shrink-wrap is only visible in HardCMP and when we import a sur into MilkShape, and does not cause collisions, but only triggers collision detection, do we need to remove it at all?

Lastly - the bounding boxes (type 5) that are in all vanilla surs around the model groups - what exactly are they there to do, since collision detection is already triggered by the shrink wrap or HpMount bounding box around the entire ship?

Yes there’s been a flurry of posts, I’ll read them and check and fix my posts.

Schmackbolzen wrote:
@FF: Also don’t forget the bsp tree, which usually does a major speedup in collision detection. None of the custom generated .sur files had one so far…

Huh, I’d missed that. Guess it further explains the incredible performance boost we’re getting with those new SURs then.

Mad props to you, Schmack

ok i done some tests tonight
i don’t know if it can be usefull for you but …

test on the a9, multipart cmp —> it works like a charm

test on the colony3station (who is pretty big and complex … colony3 station) –-> no way, with several cmp, no differences, no hit registred and no hull detection

test on the avatar station, it seems to work
i noticed one strange thing, maybe it can be important for you to know

at avatar1.jpg, i can pass through
then at avatar2.jpg, i shoot on the base
and at avatar3.jpg, i can’t pass anymore
it’s the same place, exactly
i don’t know what the laser has done but can he “activate” the detection ?

http://img593.imageshack.us/g/avatar3y.jpg/

Nice tool Schmack, the recent updates make it work like a charm. still crashing on higher poly objects but that does not bother me at all considering sur meshes should not be 9K in poly count.

Nice thing is now that i can use lightwave to create the models, hardpoints, and sur mesh. only using Milkshape to convert the mesh to cmp.

next thing to have would be a tool to convert obj files to cmp, with a scaling factor. now that would be totally juicy to match this tool.

Cheers Mate, two thumbs up.

Schmackbolzen wrote:
@FF: Thanks ^^

@Mirkha: Don’t forget that it is attached to root only. I would say that’s why it did not work at all.

Concerning the flying through: I would have to test it myself with the model to be able to draw any conclusions.

Just so you know, Schmack, I redid all of FW:ToW surs using your converter, all 124 ships work flawlessly. Not only that, we saw some significant performance improvements

The only thing the exporter doesn’t do are the multiple component .surs but that’s such a small issue.

I’ll do the stations next and tell you how it goes.

Schmackbolzen wrote:
@Mirkha: Don’t forget that it is attached to root only. I would say that’s why it did not work at all.

Concerning the flying through: I would have to test it myself with the model to be able to draw any conclusions.

here the models if you want to test
http://svn.freeworlds.fr/FWMod/avatar.rar
and http://svn.freeworlds.fr/FWMod/colony3.rar

I have made a station sur with your soft, and i encounter CDT when trying to fly through, collision are OK but few second after some collision, CDT, don’t know if its the sur or the CMP of my station, will make another test without the sur and if CTD again, then the sur is GOOD and my cmp is crapy lol^^

ANyway, it’s a good job, and you soft let me make good surs for some ships which have previously bad surs

Thanks for your soft

Well i’ve tried this and managed to create a sur that fails every time on every model i’ve tried so far. Clearly i’m doing something wrong.

Process of what i’m doing is as follows,

1. Import model into MS as a cmp. ( Do i need to import the hardpoints as well?)
2. Export model as OBJ file (end up with an OBJ file and a MTL file)
3. Open new converter, import newly made OBJ file
4. Left the number as 5 (no real idea what it does anyway)
5. I tick the second box (because it seems to make sense)
6. Hardpoint section left blank (prob the cause of my errors tbh)
7. Can someone show exactly what needs to go in this section please. All very well saying stick the hardpoints in but how? What’s the format for inclusion? Is it,

addon = ge_kf_engine_01, internal, 1
equip = ge_kf_engine_01, internal, 1
ge_kf_engine_01, internal, 1

You see my point here? With no documentation how are those who didn’t go to sur school expected to work this out?

Any help appreciated

PS. No complicated replies please, pretend i don’t know anything about surs or this utilty

I was just about to post much the same ^
Interested in this tool… as i have some slightly unconventional ships and a few base models still in the hold due to my severe lack of understanding on anything sur related apart from click here do this

I only just finally wrapped my noggin around LS’s sur builder and its great for most ships as i don’t have many multipart ships… but as i said for a few, stock sur’s and close enough just won’t cut it.

So yeah… I too would love a rundown on the exact steps taken to get a .cmp into MS… to be ready for this tool. do we strip it 1st or just tell it to not import hardpoints… etc, what do the funky values do?.. and all that jazz

Gibbon, are you importing the SUR model, or the ship model itself? If it’s the SUR model, I’ve got nothing, but if it’s the ship model… As the internet meme goes, you’re doing it wrong. If you’re importing the ship model, the SUR it creates is far, far too complex, and will most likely hang the game. Use a simpler model in this case. Leaving the hardpoint section blank isn’t an issue, at least, it wasn’t with me.

Sushi wrote:

The only thing the exporter doesn’t do are the multiple component .surs but that’s such a small issue.

In what messed up universe is this a small issue? Is this a case of not detecting internet sarcasm, or do you really think this isn’t important?

depending on the ship’s mesh it should for fighters usually not be an issue to convert the whole geometry. for the hardpoints, you don’t need them from the cmp, just write down a list of hardpoint names as you called/want to call them in the cmp itself and you should be fine.

one more question i’d like though to ask myself as well: how exactly to change certain sur part’s attachment to other groups than “Root”? there is an offset, but where is it and do you have to encode the value of the nickname’s hash (or UTF ID) or can you, like in the cons nodes, input a string directly up to 32 bytes?

@mknote

I can’t import the sur model as i don’t have a sur to start with, that’s what the utilty is for lol. Which brings me to the next point you raised, how would i make the model simpler?

@ Gisteron

That’s kind of my point though with the hardpoints, how should it look if i want to put them in, what’s the format? Example please.

I have made about 20 fighter surs so far, have only tested 7 thoroughly. Those 7 have passed 6-8 hour stress tests .

Dev server is setup so that 2 factions fly the same ship with the new sur and shoot each other. Loadouts include guns, missles and torps. Zone set to spawn 30 npcs. Also have a base in the center shooting at both factions. I periodically jump in the middle and shoot at them, bump them with my shield down, and let them shoot me. No errors or crashes.

This is the method I use for fighters…

.cmp --> MS3D :

Import hard points and auto load, are the only boxes I check.

Then export to .OBJ

.OBJ to .SUR converter:

I leave the 1st box at default 5,0

Then I check 2nd and 3rd boxes.

Then enter the hardpoints in the order they are listed in HardCMP.

example:

HpCM01
HpEngine01
HpEngine02
HpMine01
HpMount
HpShield01
HpThruster01
HpTractor_Source
HpCloak01
HpTorpedo01
HpTorpedo02
HpWeapon01
HpWeapon02
HpWeapon03
HpWeapon04
HpWeapon05
HpWeapon06
HpWeapon07
HpWeapon08

Going on what StarTrader said about needing the hardpoints in the sur files,
I would think you must enter them or you will run into the random crashes everyone was getting with the previous methods.

For larger ships and stations with Vertices over 8-10k I use MS3D’s DirectX Mesh tools or LithUnwrap’s Optimize tool, to lower poly count. The DirectX mesh tools seem to work ok on some models, but not others. For the ones that dont, I Ctrl Z to undo any changes made by directx mesh and save as a MS3D file. Then open the mesh with LithUnwrap, Optimize and save then back to MS3D, weld vertices, export as .OBJ.

I also made 15 or more surs for battleships and large stations last night and will be testing those today. Will report back with results.

Gibbon wrote:
@mknote

I can’t import the sur model as i don’t have a sur to start with, that’s what the utilty is for lol. Which brings me to the next point you raised, how would i make the model simpler?

I’ll say it once more: this isn’t a magical big button “make perfect SUR”. It requires you to make the simple model from scratch (like you would have done before with the old MS3D SUR exporter) and then use that. Just like I said in the past, this is very likely to be how the original devs did, too.

@ Ben_Kai

Finally someone who understands where i’m coming from. Thanks very much for that, appreciate the heads up.

@FF

To paraphrase you FF, just like i said before, I’ve never messed with surs, used to use resized vanilla ones and it’s only recently i started using Lancers utilty because it does what i want and very easily. You’re assuming way too much that everyone understands this poxy format, and to a new modder what you say still doesn’t mean dick.

The whole point of a utility is that everyone can use it and not just the chosen few who understand the format. So enough with the as i said before nonsense and let’s have a full tutorial of this program so we can ALL use it. Get it?