.obj -> .sur converter

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.

It is this type of misinformation that drives me bananas.

Mknote - get some glasses on your face and look again.

The bottom wing is made in 3 parts, the vertical pylon and the port and starboard wings.

There are absolutely NO concave Sur parts in any vanilla ship Sur!

Check for yourselves:-

Startrader, you may be right, but please keep it civil!

Thanks.

Schmackbolzen wrote:
@Startrader: I am not sure what offsets you are talking about. Each triangle group has a type offset, for which we know that number 4 means it is geometry you can collide with and that number 5 means that it is the convex hull around everything. Also there is one offset for the hash of name of the group in the .cmp file, which I set to the hash of “root” for now. That’s all I know and I did not look into multipart .sur files yet! So I can’t tell you much more for now.

I mean this:

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

w0dk4 wrote:
Startrader, you may be right, but please keep it civil!

Thanks.

Edited.

Okay, perhaps it isn’t present in Vanilla SURs, but that doesn’t change the fact that it does work. Here’s a wing from my Hellhound SUR:

You can see the obvious concavity, but the SUR detects hits just fine nevertheless.

OK, got that. Sure there are no problems in hit detection and collisions detection on it?

As I said I’ve not made any concave sur parts deliberately and I’ve not tested any.

@mknote

what you show in that screen shot is not a true concave mesh. It is several convex meshes grouped together which does produce a valid collision mesh.

here is a couple examples of what i mean.

this mesh is a simple example of what you are showing. it is convex. Because, notice that it has several convex meshes grouped together. Yes they intersect, but each mesh is self contained and closed.

this next one is concave. because the two ‘pylons’ and the wing are a single mesh. the pylons are part of the wing now, which creates an invalid collision mesh.

In newer engines this is not a big deal, because newer engines are opting for using the actual model itself for collision detection and not a seperate collision mesh. But FL does not do that.

Interesting. I hadn’t considered that possibility. I assume that you’ve tested this and are not just assuming, correct?

Nevertheless, the SUR I have works fine for what I’ve tested; I haven’t put it through the ringer StarTrader does, as I don’t test in multiplayer, but it appears to detect hits as well as vanilla SUR files, and is nicely form-fitting.