.obj -> .sur converter
-
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, 1You 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 thisI 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?
-
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
HpWeapon08Going 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:
@mknoteI 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?
-
FriendlyFire wrote:
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.
Acctually I call BS on that one…. Compared to what everyone had to go through before to get a sur that worked halfway decent.
It is quite magical. :lol:
Looking at the original ones I believe they were made like that.
If you want to go through and make 20 to 100+ simple models for all your fighters, capital ships, bases, etc, and waste your time, you can.
You don’t have to…
I have 9 tested surs, using the method I posted above, that I can upload to prove it.
-
I have appended some sort of roadmap to my first post. This should help to clear some things up.
Don’t forget that this is still a beta and I have to admit I am somewhat surprised that the generated .sur files work that good. I expected some more problems, since I have no clue how the tree of the bit section is created exactly in the vanilla files. This strongly supports that my theory was correct and it is a bsp tree, also the performance improvements FriendlyFire reported speak for it.
Which brings me to my next question ^^ FriendlyFire, how exactly did you measure it? And is it clientside only or serverside aswell?
As for the rest: I will try to use your feedback to generate a somewhat understandable documentation and maybe a more intuitive gui. But I am afraid the hard work of making collision meshes can’t be much more simplified. You can search the web for meshlab and polygon reducing, it has a nice algorithm for that. Sadly I discovered a number of bugs while testing it (mostly crashes), but at least the polygon reducing seemed to work (you have to play with the options). I will try to also include a short explanation how to use this program in the documentation later (or maybe one of you guys finds a better way ^^).
If anyone is not able to generate a working .sur file please hand me the model! Only this way I can see whether there are still errors.
I will have a look at the ones Mirkha postet.
-
Ben_Kai wrote:
FriendlyFire wrote:
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.
Acctually I call BS on that one…. Compared to what everyone had to go through before to get a sur that worked halfway decent.
It is quite magical. :lol:
Looking at the original ones I believe they were made like that.
If you want to go through and make 20 to 100+ simple models for all your fighters, capital ships, bases, etc, and waste your time, you can.
You don’t have to…
I have 9 tested surs, using the method I posted above, that I can upload to prove it.
Well this is also an issue which someone should test. In theory a collision mesh build only out of convex elements should be less a performance hit than a polygon reduced one. The important question is, how much difference does it make?
-
For example i made some stations with about 2k-5k poly , export obj from ms3d , import to lightwave 3D , reduce polys , import to lithium unwrap , optimize model, import to ms3d , weld vertices , export obj from ms3d and make sur.
I saw the best obj for sur files are created from milkshape or lithium unwrapper.
You can also use ms3d`s DirectX mesh tool reduction to reduce polys to about 3-4k max .
Now the only thing that can be done with this tool is to made surs like groups in cmp file. -
Schmackbolzen wrote:
Well this is also an issue which someone should test. In theory a collision mesh build only out of convex elements should be less a performance hit than a polygon reduced one. The important question is, how much difference does it make?
There is a difference, but it does not seem to be that much for your average setup. Im testing on an AMD64 @ 2.2 ghz with only 1 gig of ram. Im running FLServer and 1 instance of the client on the server box. When switching from resized vanilla surs to the ones I generated with your tool the server load only increases about 5 to 7 ms. This is with 25 -30 npcs and three player ships, all using the new surs.
Im sure if you use my method, and had 100 + players in the same system in a knot, you would notice a much larger performance difference. But I know of only 3 servers that get anywhere near that many players together and they have mod teams big enough to make new simple meshes for their ships….
My point was you don’t have to make all new meshes. If I ran Discovery or HC, then yea, new meshes would be the only way to go.
Performance was the 1st thing I thought of when I saw how large the 1st couple of surs I generated were. The Vanilla ones seem to average between 20-30 KB. Mine are between 90-110KB.
Edit I didn’t reduce the polys on any of the fighter surs I made. I think I will try that and see just how small I can get the surs, and then re-test…
-
Gibbon wrote:
@ Ben_KaiFinally 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?
You don’t need to understand the format? All you need to do is create a simple mesh for your collision detection. If you prefer for me to say it that way, make a REALLY low-detail mesh (something you’d use for a LOD so far away it’d be a blimp), and use that. I don’t see what’s so complicated about that. I’m not assuming people understand the format, I barely do. Sushi’s been working just fine using simple models (either poly-reduced versions of the CMPs or old SUR meshes that had been made for the old MS3D exporter).
It’s as simple as it gets, but it isn’t all automated.
EDIT: Ben_Kai, comparing vanilla meshes with these might not really say much. In the very best scenario (we understood the format perfectly and had experts in making the models), we’d have approximately the same performance.
What does matter is that custom SURs built using Schmack’s new exporter versus either LS’s tool or the old MS3D exporter are between 25% and 75% more efficient. That is a huge difference. Our Battle of Bilbringi went from 10-15 fps to 30-40 fps with server load going down from >50 ms to <10 ms.
-
FriendlyFire wrote:
EDIT: Ben_Kai, comparing vanilla meshes with these might not really say much. In the very best scenario (we understood the format perfectly and had experts in making the models), we’d have approximately the same performance.
What does matter is that custom SURs built using Schmack’s new exporter versus either LS’s tool or the old MS3D exporter are between 25% and 75% more efficient. That is a huge difference. Our Battle of Bilbringi went from 10-15 fps to 30-40 fps with server load going down from >50 ms to <10 ms.
Yes that is a huge improvement. Thats excellent. I’ve been waiting for FW2.0 to come out since it was announced. I was comparing mine to the Vanilla mainly as a reference, because I noticed the size difference. That and the fact that I have never seen any custom surs that could compare to them hit detection/stability wise, until now. I’m pretty sure I have played every mod that has been released since early 05 and there was always random unexplained crashes which modders usually blamed on the surs… I do have a few custom surs made with sur builder and the exporter. I will throw those in and see what kind of performance difference I get between the 3. After I reduce the polys on the fighters and regenerate the surs.
-
Hello Schmackbolzen. (Just to be clear who I am addressing this time so I don’t get slagged unnecessarily) ! :roll:
Schmackbolzen wrote:
@ST: Please don’t mix up things:- The type 5 part is the convex hull around everything (which you call shrink wrapped)
- It even is there if a shield bubble is included, but it is the same as the shield bubble, since it is the largest part around the ship (convex hull…)
This is what I said, there is no difference except in words: “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.”
There is not a shrink-wrap around the ship parts as well as around the shield bubble, only the duplicate of the shield bubble.
We call it shrink-wrap because this is what the original sur exporter calls it.
So in all cases, we have one overall bounding box surrounding the entire model. Agreed.
Type 5 surs:
I don’t remember when or why we started calling them “Type 5” surs. These are the ones that somebody said have an offset, and not the CRC of their name, as their id.But this does not make sense…
For example in the Stiletto (my favourite standard model), there are several of these (import the sur into MilkShape with the original Sur Importer):
M23 - 000018d0 - shield bubble bounding box
M28 - 00000270 - upper port wing + weapon bounding box - why are these the same?
M31 - 00000270 - lower port wing + weapon bounding box - why are these the same?
M34 - 00000290 - upper starboard wing + weapon bounding box - why is this different?
M37 - 00000270 - lower starboard wing + weapon bounding box - why are these the same?If it was an offset to a mesh, there would have to be 4 different offset values, because none of these are identical.
So, can you tell me if this is really an offset, and if so why we have 3 values the same and 1 different?
Also note that the engines and wings and weapons all have bounding boxes as well as sur parts in the sur, but all of those are translated correctly to the name, because their CRC is the same as their parent group.
I would have expected to see “offset” values for these like the ones above, and not CRCs. Any explanation to help clarify?
And what I am leading up to is, what function do they perform, and can we replicate them in a sur?
-
Gibbon, perhaps, if possible, you could use an sur you’ve made for the ship with LS’s sur builder. Import it into milkshape, save it as .obj and use that as your low poly model. It should already be a simple shape representing the correct size of the ship.
I’m waiting until this all pans out before I have a go at it, if ST can’t break it then I know it’s okay.
-
FriendlyFire wrote:
I’d argue that you shouldn’t be using a 10k+ polygon model for a SUR file. It should be like a fifth to a tenth of whatever normal model you’re using.I’m in total agreement with FF.
Closeness to the standard should be the rule. It isn’t sensible to have huge sur files, and we’ve usually made very low-poly simple sur shapes by hand or used Convex Hull or Havok tools before exporting these to make the sur.
Gibbon: it is a pain but it is the best way, splitting the model into several groups then using Convex Tool works well. And we need to have the model in several groups for break-apart effects and break-off parts, and so we need the sur tool to make multiple-part surs. In turn this will probably also speed up collision calculations.
