Anyone else still need a SUR generator?
-
I’m all for a new way of getting surs to work. As we already have Lancers sur utility, i’ve found with regular use that for me at least it works as i want it to with certain types of models.
With the ELITE ship pack i’ve just done (still waiting for approval btw), it was great due to the shapes of the ships involved and produced some really form fitting surs.
On more odd shaped modles like the Starlancer ships, it’s a different story, specially on the larger ones. This ship is called a Mammoth freighter and looks like this with LS’s sur builder on a single group model
Works but it’s ugly. Yes, i know i should break it up but with over a 100 models to do sur files for, i’m looking for an easier solution than carving all the models up and in some cases, by the time i’ve done that it will be the year 3278.
Now using the same ship and the sur exporter 1.1, i’ve got this,
Exactly what i’m looking for although i could lose the shield bubble as i don’t really want that, but the rest of the sur is as it should be.
One small problem, it doesn’t bloody work, which is a shame as this would be an ideal solution. Now i hate surs with a passion, don’t understand them at all and never will, but i’d like to know why the sur exporter version is faulty. Looks fine, i can generate surs for all the models that look like that, form fitting and so on, but all are faulty. Has someone not looked at maybe fixing this exporter?
If not then maybe they should. If this new idea i see being discussed works, then i’m all for it, anything to achieve a working version of the sur above would be nice
-
When Bejaymac was active he found that some surs crashed because they had “internal spikes” and concavities. Surs can be imported into MilkShape with the plugin.
Since we have no way to edit sur files graphically, it is not possible to modify the .sur itself.
So he had to remove and remake bits of his models until the exporter generated truly convex sur parts in the entire sur.
If you use the Convex Tool on the model parts first, this problem should not happen.
As I have found, my surs (generated manually, with Sur Splicer, with Sur Builder, with sur exporter v1.1) all work for many minutes, leading most modellers to think they are completely good.
But all cause crashes eventually, it seems it is due to weapon hit calculations or on destroying a sur part on hits, but it is not constant, many NPC ships with the same sur can be destroyed until one fails. I haven’t had time to isolate which weapons cause the crashes most reliably.
This is supported by Bejaymac’s statements that there MUST be both collision and hit detection sur parts in the sur, and also weapon surs in the sur for it to work correctly. Look at a plain FL ship sur and you will see there are duplicate components in it for the wings, weapons, and also wing+weapon surs. These are the Type 5 sur parts.
My background is in finding intermittent problems on mainframe computers, so I am used to setting up and aggravating environments to bring out these intermittent faults as often as possible so they can be traced.
So I have also used only spheres to cover a model, and also only boxes - all fail eventually. Only original ship surs are completely sound, I have proven this by running test games overnight using only vanilla surs. When NPCs are equipped with custom surs then they fail eventually, some have taken over 30 minutes in my test environment. Solars on the other hand do not seem to have the same problem, as I am using a huge battleship with a manually-spliced sur on it as a base station during my testing. The base ship continually destroys hostile NPCs equipped with the test ships and surs.
Sur Exporter v1.1 can also generate weapon (HpWeapon and HpTurret and HpTorpedo) surs automatically, but does not make the additional hit detection boxes that are in the original surs.
But we (I) don’t know how to create them correctly. I can make the shapes correctly and place them at the origin, but the naming defeats me.
Adoxa and others say it is an offset. So how do we calculate it and put it in?
-
Great explanation ST, just wish i knew what you said and i mean that in the nicest possible way.
This subject just eludes me for whatever reason, Why i like LS’s utility which is great up to a point. When it comes to more complicated models like the one i posted above, the sur exporter should work but it doesn’t. I mean a sur generated at the push of a button as is already the case with the exporter is without doubt the way to go. Not only that the exporter recognises holes, like docking bays and so on.
We just need a working version of ANY sur creating utility that does similar to what we’re all after, a working SUR file, and i don’t just mean a working shrinkwrap utility
-
i believe, Schmackbolzen is bringing us just what we are crying for - a tool that converts a geometry we do ourselves to a sur file. that would mean no more problems with concavity or hit or collision detection or anything else but just a surface mesh we did saved in the freelancer sur format. guess all our problems so far are that we in fact did just not yet understand the sur file format entirely. once this happens there will instantly be a converter - a translation program.
-
It would be very helpful if one of you could test whether the generated DevilRay.sur I attached still crashes the server. The same will have to be done with convex geometry and later with multipart meshes. So far the .sur format I write seems to be correct.
@Gisteron: Exactly. The .sur will be what your geometry is, with some additional checks to make sure the format will not be wrong. I.e. Geometry will be changed if it is not convex. If everything goes well you can test the converter yourself this week (no multipart and everything attached to root).
-
That’s a restriction of the physics engine. The geometry you input will be converted accordingly with some options, you will see. The best .sur files you probably will get if you reconstruct the original geometry with convex groups. Skotty and I tested this and we were able to get .sur files like in vanilla and they work perfectly till now (even one with over 2000 polygons and over 100 convex parts). If you don’t the geometry will be processed so that it still works, but it wont be as optimal.
-
My plan is to separate the generator from the exporter. The generator will be a separate tool, basically the wrap options of the existing exporter (like a sur-specific convex tool). The exporter will take those groups and create the sur file. I was going to start on the exporter soon (using the importer to test it out), but I might delay yet again to see if I can compile FLMM and sort out its troubles. Maybe by the time I’ve done that, Schmack’s tool will be perfected and I won’t have to bother…
-
Schmackbolzen: Terrific news.
I will test the DevilRay and get back to you. Others can also test it by downloading the DevilRay ship model earlier in this thread.
I am encouraged by your testing and hope this success will continue in mutli-group models too.
Thanks for your great work.
-
Schmackbolzen:
I tested your sur, it is as good as mine, runs fine initially but fails after up to 5-12 minutes of continuous destruction of NPCs using it. I tested it 3 times.The symptoms are the same as my surs, so don’t worry, it is as good as we can get with any of our current sur generation tools and methods, so it’s looking very good already.
As you create your sur exporter/generator please remember that the vanilla surs have hardpoint sur parts, and the exporter v1.1 can also generate at least some of them (HpWeapon, HpTurret and HpTorpedo), I’ve not tested to see if it generates a sur part for every hardpoint type that has a sur part in the vanilla surs.
adoxa:
I uploaded my test results here:- http://downloads.rrjds.com/STLatestCrashes.zipThe first 3 crash logs are with Schmackbolzen’s sur for the DevilRay and the last 3 are with my own last sur.
The symptoms are that the last weapon hit just before the crash is sometimes to the NPC’s thruster (ku_thruster.3db) and the other times to the NPC’s CM dropper (li_cm_dropper01.cmp).
These have their own surs but do not have one for their hardpoint in either of these ship sur files, whereas the vanilla surs do, and those do not fail in my test environment.
Almost all other hits before the crash (with a couple of exceptions, see the GetCollisions files carefully) are to the shield specified in shield_link in the shiparch.ini file (li_elite_shield.3db), as I had expected.
But there are no hull hits mentioned in GetCollisions at all once the shield is down, which I expected to see. Anyway I’m not qualified to determine if this is correct or not! lol
Hopefully now we will learn why the crashes are happening.
Many thanks guys.
-
That crash report confirms my results, so it does look like it’s the hardpoints. The packet log shows a particular type of damage object at the same time (both u_dword and u_byte are 2; normally if u_byte is 2, u_dword is 5; if u_dword is 2, u_byte is 0). I’ve attached the Builder sur, updated to include the proper hpid sections (untested, other than running through SurDump). If that still doesn’t work, adding in the hardpoint surfaces themselves will have to wait till one of us writes the code (unless you’re able to splice them in?).
-
Startrader: Thanks for testing! I concurr with adoxa that it’s most probably the hardpoints.
@adoxa: I could just set them in the middle for the start (would be just a box), wouldn’t be a trouble. You would have to enter the names manually, though…
Btw. I have finished implementing the convex hull algorithm, so I think I can indeed release a first beta version this week.
-
That’s great, and explains why it takes so long to fail, it’s just whenever there is a hit on those hardpoints. And since they are behind they are protected by the hull.
It’s funny that NPC weapon hardpoint hits aren’t causing any crashes though, the NPC weapons must be getting hit much more often than the CM dropper and thruster I would think. Any idea why hits on these may not be causing crashes?
For generating Hp surs - it’s very easy for the modeller to put in the hardpoints in MilkShape before exporting, in fact they are already in the model usually and the modeller just needs to leave them in before exporting, whereas “normally” we would take them out. They are just triangles centred on the hardpoint connection point (HpConnect).
Why would we have to enter the names manually? The vanilla surs have their hashcodes.
And for the exporter / sur builder, just detecting the hardpoint name, as the sur hardpoint shapes are only 2 standard shapes I think, so just selecting one of two fixed-size shapes depending on the hardpoint name and placing them on the hardpoint face centre and orienting them to its plane should do? I don’t know the coding problems of course.
I will check and get back to you with the precise shapes, but if I remember correctly the HpWeaponxx and HpTurretxx and HpTorpedoxx are all the same stretched 8-vertex tapered rectanguloid, the HpEnginexx and HpCMxx and HpMinexx are a 10-vertex tapered pentagonal shape.
I’ll confirm that asap.
Thanks chaps.
-
adoxa, Schmackbolzen:
Here attached is a .zip with all of the Hardpoint sur shapes that I could find in vanilla Freelancer, in .ms3d (Milkshape) format.There are quite a few. Some are the same shape as others, but I took them all so that you can decide the “what” & “how”.
I have included the Hp triangle with each of them so that you can see where the sur sits in relation to its Hardpoint. Some of them have their bottoms on the same plane as the hardpoint, others are above, e.g. HpTurret.
I have separated them into individual files and also one file with all of them in for comparison.
Many thanks for taking the time.
-
I have some very interesting news, thanks to my dogmatic approach to troubleshooting…
First the bad news:
Guys: All the custom SUR files you made are bad, you just haven’t triggered what will cause them to crash yet.
And if you are getting rare crashes in your mod that you can’t find, this may well be the same cause.
Now the good news:
From my crashes we found that the countermeasure dropper or thruster were always the last objects hit at the time of the crashes.I added the Hp’s and exported the sur with sur parts for HpCM01, HpThruster01 and HpThruster02. These are already built into SUR Exporter v1.1 and there are others too, I haven’t checked to see if it knows about all the hardpoints in the zip file I made in my previous post.
Guess what?
Both surs made with SUR Exporter v1.1 worked right away.
And… No more crashes, my test environment ran overnight for 6+ hours!
Yay! Progress at last.
adoxa - I looked in the GetCollisions.txt file and found there are now no entries at all for the shield_link (I exported with a shield bubble):
23:53:35.351: idx = -5, end = 0xA31638
object 1 = 2001 SHIPS\liberty\li_elite\li_elite_shield.3db
object 2 = 0067
CRC 1 = 0x00000000
CRC 2 = 0x00000000And now, the only entries in GetCollisions.txt are the still-unprotected items in my model and loadout:
1. The gun hardpoints (HpTurretxx) on my battleship base which have no sur parts:
12:51:41.665: idx = -3, end = 0x2E8D29C
object 1 = 2001 equipment\models\turret\li_turret04b.cmp
object 2 = 0067
CRC 1 = 0x12688F2D
CRC 2 = 0x000000002. The 2 types of special equipment that I have in my mod, mounted on new nonstandard-named hardpoints and these have no sur parts:
12:48:03.562: idx = -2, end = 0x2E8D268
object 1 = 2001 equipment\models\st\br_conversion_shield.3db
object 2 = 0067
CRC 1 = 0x00000000
CRC 2 = 0x00000000and
14:15:18.068: idx = -2, end = 0x2E8D268
object 1 = 2001 equipment\models\st\rh_radiation_shield.3db
object 2 = 0067
CRC 1 = 0x00000000
CRC 2 = 0x00000000These are not causing crashes, but the fact that they are unprotected and are listed in GetCollisions tells me they should not be (unprotected and listed).
So I think we now have confirmation that these missing sur parts are the cause of the crashes.
I will check (sometime) which ones of all the standard weapon and equipment hardpoints the SUR Exporter v1.1 can insert into a sur file.
These will need to be inserted properly by any sur generator / sur builder / sur exporter plugin, otherwise we will still be generating bad surs.
adoxa - What is GetCollisions listing exactly, I thought it was all collisions, good and bad, but evidently it is not listing good ones?
Is anyone progressing a new exporter/generator/builder?
-
It lists all 2001 collisions that occur twice in succession. I thought they were all good, but I guess it makes sense that they’re actually bad.
Since you added the actual surfaces, does that mean the simple hpid version I made didn’t work?
I’m working on FLMM v2, then I will do the exporter.
-
I hadn’t tested it, I forgot all about it - sorry, good you reminded me.
I’m testing it at the moment and will let you know, it’s looking positive, over an hour already.
You said: “I’ve attached the Builder sur, updated to include the proper hpid sections”.
What do you mean exactly, this is not clear? Does hpid mean Hardpoint, as in Hpxxx? And do you mean you put in only the hardpoint names? With no meshes how will FL detect a hit?
If this works, how can we put in the hardpoint names into a sur made with Sur Builder? (I’m reluctant to use this method because it’s another get-round).
-
adoxa: It ran clean overnight, so it works.
GetCollisions.txt now contains only the turret entries (turrets are used on the base ship). There are no entries for my special hardpoints, and this is unexpected.
This poses more questions:
What did you add to the sur exactly?
And how?
-
He just added them to the HpID list at the end of every sur file. Simple but effective solution. There is no actual geometry involved for them but FL can find the hardpoint in the collision data and use it (even though it will never collide). I guess its because they never anticipated that there wouldn’t be any hardpoint data it the .sur files.
Btw.: I have encountered a stupid showstopper bug in the convex hull algorithms (I actually am porting the 3. variant right now, since every solution I found on the net has some flaw in special cases). The rest is working perfectly. As soon as I was able to implement a perfectly working one I think I can release my generator.
