.obj -> .sur converter

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_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?

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.

Timmy51m wrote:
Gibbon, perhaps, if possible, you could use an sur you’ve made for the ship with LS’s sur builder.

or use the Sushi’s tutorial for LODs
LOD are “simplier models” so it could be a very good start to make a sur, i think;)

StarTrader wrote:

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.

Well let me diplomatic about this. no. It’s your thing to have models in many groups with breakable parts and if that’s your bag, i’m fine with that. But you can’t tell me or anyone else to break all our models up because you think it’s the best way to make sur files. It’s balls.

I’m not arguing the fact that that approach is probably the right way to do bases or some larger models but the fact remains it’s down to personal choice and not because it’s the correct way to make a sur file. The one i uploaded earlier was for the Galactica from BSG, a single group model with a superb sur that Bejaymac put together for me a few years back.

Not everyone wants parts that break off and for those that don’t want that, Lancers utility works 100% on smaller models that are based on the single group principle. With this new utility, i’m looking to make surs for odd shaped ships like Cloud 9 from BSG for example, where Lancers utility is no good. I’m just looking for simple & clear instructions as to how to do that, but you can’t come along and say to break up the models when there is no need if i don’t want destructible parts.

The Elite ship pack i did is a good example of that, form fitting surs onto simpler shapes and i got perfect surs for every ship, and they are single group models with no destructibles. I doubt there’s a sur amongst the whole pack that isn’t under 25k and no need to break them up.

Breaking up a model is a matter of choice, not a must have for creating a working sur.

Well you misunderstand, and you’re absolutely wrong, Gibbon.

I did not tell you to do anything. You must have had a bad day. Slug a Vodka or two and read me again.

I said it is the best way. Prove me wrong.

Bejaymac sweated blood to tell everyone that ships must be in more than one groups, as did other people.

Your Galactica must be made in more than one group, and definitely so is its sur, or the docks would not be fly-through, and nor would the gaps between body parts. The sur parts are all attached to Root, but they are many groups - by the way where is it? I deleted it and can’t find your post with the upload.

It is up to you how you do it of course, and I am not telling you or anyone that you MUST do anything my way. I show (teach) people the right way, or sometimes an easier way, a better way, or a more reliable way. But I do things my way and each of you needs to have the ability to do it your way too.

If your ship is in more than one group, when it is destroyed you can enable it to fly apart like most vanilla fighters do, instead of disappear.

I have decided I am no longer a cute bunny, this is the last guy’s hand in my mouth. The rest of him tasted cruddy so I spat it out, he’s lucky! Ugh!

Beware all, don’t lure The Old Croc!

I make my SURs multi-part as a matter of course, as I like parts of ships blowing off. BJ was rather adamant that ships had to be multi-part in order for SURs to work properly, though, so I tend to side with StarTrader unless I see evidence otherwise.

As a side note, remember that only the root must be convex; other parts can be concave at will.

its good to see progress here, thumbs up.

MkNote: concave sur parts: I think that’s for single-part surs, no?
But I’ve never made any with concave parts deliberately to test this (accidentally maybe, but then those surs have failed immediately).

In any case none of these sur tools will make a concave sur part, they all make convex parts unless you deliberately make concave parts and use Sur Splicer.

You can use the Convex Tool in MS3D, applied on the different parts of your ship, and you have a simpler model (don’t forget to delete the original parts when the convex ones are done^^) than the original one.

one more reason for multi-part vmeshes and surs, is the animations - how would you make a station open and close its airlocks or make a ship fly into it and stay there, if the doors are closed, if you have only one sur mesh around it? lets not even mention what is going to happen once FW:ToW’s animation triggering is being released and you’ll like your galactica to retract its pods before it goes on cruise or others, who’d like their voyager to highten its warp nacelles on cruise charge? that’s what multipart cmp’s are good for and it’d suck to have a single-part sur for them if you are aiming some sort of quality to your mod and maybe if you want to show a level of possibility similar to what the dev’s had.

Animations are done by the very few as we all know it’s a pain to do. Animation triggering is still a way off, i can count the modders on one hand that can do that successfully. I take your point that it would be required for those that need it and should be built in to the converter. Having all the above features while nice, are not always needed for a popular mod.

Please don’t confuse single part surs with a lack of quality, i take offense to that statement, plenty of excellent mods out there that use those and not been an issue up until now. I’ve released plenty of mods myself over the years with single part surs, not had any moans.

What’s your problem then, Gibbon?

If it’s about priorities: I rather had a clunky tool that spits out perfect .surs with all features (multi-part, proper tree, just like vanilla) than some sort of one-click .sur generator for “newbies”.

Of course documentation is important.

That’s part of the problem on here. Nobody is saying it shouldn’t have the features that people are crying out for. You guys need to look at the bigger picture and realise the more clunky you make it, the less people will use it.

Start to think about people taking up this hobby for the first time, and the useability factor and not about what you know w0dk4, but what a person coming into this will know. They’ll see this and swiftly move on.

As mentioned this tool needs a serious tutorial to go with it, and judging from the comments, a few extra features to keep the experts happy. That’s all i’m saying. To criticise other tools that do almost as good a job smacks of stupidity.

Not so long ago, nearly everyone on here was drooling over Lancers utility (was going to say tool but that sounds wrong), funny how the goalposts have moved and that’s being disregarded and is now a tool for for “noobs”.

We were all enthusiastic about the Sur Builder, me most of all, have you forgotten? :roll:

Each of us has his own expectations, but let’s stay cool guys, and let Schmackbolzen work.

This one might be tremendous, when it is completed.

The documentation won’t take long to make once it is fully-featured, so don’t worry, it will be done, and if it doesn’t make sense to me I will help to clarify and get it sorted.

And I’m also sure Schmackbolzen will do his best to make it as easy and quick to use as possible.

So let’s wait a few more days and see what his next release does.

Schmackbolzen:
I asked for clarifications in an earlier post about the sur parts with offsets instead of CRC’s, I gave an example. Can you try to explain to me what you know about those please, and if they can / will be generated in the final release?

Sorry Gibbon but I have to disagree here. Somebody looking to do a mod for any game will be faced by some pretty strong challenges. You don’t get to do a mod by pushing some buttons and letting stuff happen, you need to work for it. I know for a fact that you do work for it, and so do we all. Newbies will have to learn and yes, many will give up in frustration or laziness, but that doesn’t necessarily mean the tools are bad! The same proportion will drop off HL2 modding, which has a full development suite and dozens of long tutorials.

StarTrader wrote:
MkNote: concave sur parts: I think that’s for single-part surs, no?
But I’ve never made any with concave parts deliberately to test this (accidentally maybe, but then those surs have failed immediately).

In any case none of these sur tools will make a concave sur part, they all make convex parts unless you deliberately make concave parts and use Sur Splicer.

StarTrader… it’s present in Vanilla SURs. Look at the Sabre; notice how the SUR has a concavity at that T-intersection between the vertical and horizontal parts of the bottom wing, yet is only a single group. I can confirm it on my Hellhound SUR, too; it allows for more form-fitting parts. (As for no SUR tool making concave SURs, SUR Exporter v1.1 for MilkShape does…) Obviously, this will only work on multi-part SURs, as in single-part SURs, everything is part of the Root, and the Root must be convex.

Anyway, it appears that it isn’t common knowledge, so just to let you guys know, it does work. Somebody might want to use that knowledge in other SUR building tools (like this one) in order to get a more form-fitting SUR.

Also, animations aren’t that hard to do, at least, bay doors opening and closing aren’t. I’ve done that to all of the ships in my mod.